Take it to a Channel

Hearing the sound of your morning alarm when out in public can elicit a visceral response - be it a song, chime, or the classic “beep beep” noise, many of us are conditioned to react to that noise and have rather negative associations with it. I’ve seen (and admittedly, had myself) some less-than-pleasant jumps when my alarm sound is encountered out-of-context. When I was watching football this past season I unexpectedly had a similar experience - hearing the “click-clack” that I have come to associate with a potential interruption to my work day, the default sound of a Slack alert. In that instance I quickly realized that the sound was a commercial for the popular chat application, but I found my response notable.

Hearing that noise got me thinking: quick pivots in my day often begin with that famous “click-clack”. Anyone who uses slack as heavily as my team does will understand that it can become something of a monster - it is a good communication tool if organized properly, but if you let it get out of hand it can take over your day and rule your schedule; preventing the all-important blocks of focused work that engineers like myself rely on to ship software. For this reason I have spent time organizing my messages, channels, and alerts. I need to be immediately aware of conversations that are likely to be both important and urgent, so these are allowed to push notifications at me, producing the aforementioned alert sound. I have a category set up for channels that are important but not always urgent: these are commonly team chats, project channels, and announcements that affect me but usually don’t require my immediate attention. I review these frequently, and if someone needs me to be involved in something in one of these channels they can always “@” me to alert me. I have other channels that I think of as “background chatter”: I’ll review them when I get time, but they don’t matter enough to my day-to-day that I feel the need to track every message; these channels have their own category. The least important channels are ones that I am a member of, but have “on mute” - I ONLY see messages from these that @ me and never visit them unless I am mentioned; these channels tend to either be those that frequently have automated messages (deploy bots, for example) or are teams that I rarely work with (but have interacted with in the past).

When I do get an interrupt, my response is to jump over to slack and discover if I actually need to respond RIGHT NOW, or if I can set a reminder and come back later. The filtering system I put in place helps me to not need to context switch too often, but it doesn’t perfectly shield me from superfluous disruptions. Regardless of when I respond I want to have as much context as possible informing my reply. Sometimes that takes little to no time - if I’m just being asked a question I can often answer and move on with my day; other times the information-gathering phase behind an answer can require a lot more time. My overall response delay is usually dictated by how long the research takes.

One Slack feature that has been both a blessing and a curse for me is threads: being tagged in a long thread requires me to go back and read through potentially hundreds of messages before I’m able to understand the situation that produced a question, this provides important context that will frame my response. Reading all of these messages can sometimes be a waste of time, or can be critical to being able to give the right reply at the point where I’ve been included in the conversation; the only real way to know if the messages that created the thread are important is to read them, increasing the time that it takes for me to reply. Threads are only single-level in slack, meaning that a channel can have any number of threads, but a thread cannot have sub-threads.

When a slack thread becomes longer than ~10 messages, I believe that it should be capped and turned into a channel. Channels can be short-lived and archived after they eclipse their usefulness, but during that period of time it can be invaluable to organize work into individual threads within that larger channel. I recently put this idea into action at work: I was tagged in a long thread about a potential item of work that my team needed to urgently address. After reading the ~30 message-long thread I knew that we would need to make changes to three frontend apps (iOS, Android, and Web), at least two backend services, and likely coordinate more that I was yet-unaware of. I could have engaged in the thread, responding and starting to sort responsibilities amongst my team, but I sensed that it would make the thread swell in size rapidly and become unwieldy. I knew right then that everyone involved would be better off if I started a new channel. I made the channel and before inviting anyone else sent a handful of messages: one containing a link to the thread that I was originally tagged in, and one for each of the code areas that I knew we’d need to work on. These codebase-specific messages became threads that I tagged the relevant experts in, asking them to engage and use the thread that I had just tagged them in to report on their progress with the effort. As each workstream progressed the people involved were able to focus on their thread, but be aware of the work that was going on in parallel in other platform’s threads. When we discovered along the way that we’d need legal approvals, we were able to make a new thread for that workstream. Adding new people to help pursue those approvals meant a few “@” messages in the new thread, those people didn’t need to scroll through hundreds of messages between engineers discussing implementation: they were able to look to the top of the channel to find all the context they needed to start the approval process. The folks involved in getting the stamp of approval were able to work in that thread, then send a normal message to the channel (using the “also send to channel” feature of Slack threads) to alert everyone that we were in the green to get to work on the project. It worked smoothly and once we’d shipped the change we archived the channel like we would have forgotten about the thread in the sea of messages that my team sends to our team channel. If we need to go back to the channel it will be visible from the link that I posted to the original thread, so no information is lost for curious individuals in the future.

The next time that you are thinking about giving someone that “click-clack”, think about what you could do to help them expedite their response by minimizing the information gathering process that they need to go through as a result of the interrupt - make short threads, summarize, and be directed in the questions that you ask. You’ll get the information you need faster, and your responding teammates will be able to return to their heads-down work with as minimal disruption as possible. If we all remember the cost of long-running threads we might be able to make each of our reactions to the clack less like our reactions to a morning alarm (and maybe more like the reaction we have to our favorite song?).