The inner turmoils when Slack went down while working from home
According to Slack’s status page (https://status.slack.com/2021-01-04), Slack was down from 9:14 AM CST to 1:28 PM CST on Jan. 04, 2021.
This was definitely not the first time that Slack went down (https://status.slack.com/calendar), but it is the first time that I have encountered Slack going down while our entire team is connecting remotely.
The following is a playback of the whole incident and the valuable lessons our team learned during the downtime.
Wait? Is Slack or my Internet down?
I was in the middle of debugging when a Slack notification popped up on the bottom right of my computer.
Me: “The branch looks good, go ahead and merge it to the release branch.”
Colleague: “The branch looks good, go ahead and merge it to the release branch.”
“Oh, haha, very funny.” I thought my colleague was repeating my last sentence to get me to do the work instead. I was thinking of a good comeback as I clicked on the notification opening the chat channel. I then spotted the error icon right next to the message. After sending a couple more messages, and opening up Youtube on the side to ensure that my internet is still running, I concluded that Slack was down.
And then a realization hit me, Slack is down.
Let me post a GIF of that.
I suddenly realized how reliant our team is on Slack. Before the whole work-from-home policy took place, it might have been annoying if Slack goes down, but it wouldn’t have been as catastrophic and we could have still walk to each others’ working desk.
Not only do most of our critical conversations reside in Slack channels, but also the less serious socials like the doggo-spotting channel and the movies-to-binge-watch channel. (I firmly believe these serve as social destressers better than random coffee room conversations)
On a serious note, we have set up integrations with GitHub and error messaging. With Slack down, it means we have to manually monitor some of our systems.
I quietly laughed to myself about how reliant our team is on Slack and subconsciously opened up our Giphy-war channel, searched for a GIF, and hit send.
Oh right, Slack is down, no messages will get sent. (facepalm)
Slack is also a distraction
Don’t get me wrong, I am well aware of the distractions social media brings. I even touched upon this in a related article myself: What a Broken Phone Taught Me. Yet, somehow I never associated Slack with the word distraction. Mainly because I subconsciously classified Slack messages as work and believed that in a way, I am getting paid to respond to Slack messages.
There seems to be a time urgency that is tied to Slack messages that emails lack. It is totally reasonable to read the email in the morning and get back to them by the end of the day. Whereas for Slack messages, we feel the urge to add the 👌 icon to tasks that we have received,👀 for issues that we’re looking into, and aimlessly wait for people to respond to a thread. Tons of discussion threads open up with some of them dragging on forever and we naively think we can parallel process all these threads.
It has occurred to me that perhaps we should also start seeing Slack as a distraction and do something about it.
The importance of quiet time
Slack was down from 9:14 AM CST to about 1:28 PM CST.
Around 10:00 AM, it was safe to assume that Slack might not be up for the next 2 hours or so. I looked at my work notes and decided to push some conversations to later in the evening and only ask the burning questions with emails.
With communication blocked, I did the only thing I could do at the time: coding.
The end result turned out amazing. No one was there to interrupt me and I was able to get features implemented in half the time than what it usually took me.
Efforts to deepen your focus will struggle if you don’t simultaneously wean your mind from a dependence on distration. — Cal Newport, Deep Work: Rules for Focused Success in a Distracted World
I started to ponder the idea of a “F.O.C.U.S” time for developers. “Focus On Coding Useful Shit”. Normally, mornings are filled with daily standups and catchups. Afternoons are filled with business and decision meetings. As a developer, I’m forced to squeeze in the actual coding work in between these meetings.
Even during dedicated coding sessions, I am beset by distractions. Queries from QAs, dev ops, businesses, and designers would pelt me relentlessly while I futilely attempt to focus on coding.
I think this applies to every job out there. How many times did you lose your train of thought to interruptions and forced to restart from the beginning?
“F.O.C.U.S” block times off the calendar for dedicated work time. Unless there are critical production issues, everyone should respect this blocked time and reduce interruptions. This also includes moving meetings out of this time period. You will be surprised at how many meetings can be thus avoided. Managers should question if all engineers should join each meeting, or is it more efficient to just have one engineer attend and circulate notes afterward.
Set up a 3-week experimentation phase
This concept of “F.O.C.U.S” can either sail or sink. The best way is to try it out and test the outcomes.
After discussing with my team, we’ve decided to take it slow. We’re going to start with blocking off just 3 consecutive hours the first week and slowly increase our blocked times if things go well.
I’ll post an update after our experimentation phase is over!