Can Slack-mania be cured with systemized discipline?

Joining Stripe around 2015, I remember briefly trying to convince a few team members that we should practice moderation when it came to Slack – its siren song of instant gratification was undoubtedly alluring, and those tight feedback loops intensely satisfying, but many discussions were better suited for email or on GitHub pull request. As nice as synchronous communication is, async carries a number of benefits: lets people crystallize thoughts more cleanly/succinctly, keeps people more focused on the task at hand, allows participation from colleagues in other time zones, and creates a searchable/digestible paper trail.

But it wasn’t even a full two weeks before I gave up – it wasn’t just a losing battle, it was a battle that’d been lost a long time ago, and the defeat was decisive. Long form communication was gone, and it was never coming back. For the next five years I operated in “Slack culture”, the communication paradigm that I suspect is in use by many companies these days. Email inboxes were more or less reserved for broadcasts from exec and HR along with JIRA spam. Everything else happens on Slack.

To be fair, there are considerable upsides to this model. For one, it significantly reduces the likelihood of people blocking on other people. If you need help, you ping someone about it, and more often than not get a response right away, preventing wasted time on your end. Another is that difficult decisions are more likely to get resolved – contentious conversations are prone to getting quagmired in email threads, but doing them synchronously often forces some kind of conclusion.

But Slack-mania also has intense downsides. It was rare to open Slack in the morning and not already be immediately underwater by 3 to 5 mentions representing conversations that needed to be waded into. It was rare to be able to focus on anything for more than 10 to 15 minutes without getting a Slack ping to redirect you onto something else. Concentrating on harder things that took some time to sink into was immensely difficult. The bigger the company got, the more pronounced Slack-mania became, and it was ongoing all day every day – in practice the way a lot of engineers got work done was to focus on it after hours when Slack noise was reduced (not good).

Uncompromising threading

An unusual thing about starting at Crunchy is that some of my new colleagues were even more skeptical about Slack than I am. A practice that was already in place was one of diligent threading – not only was threading encouraged, but by strong convention, every topic goes into one. We thread like our lives depend on it.

This produces a clean conversation model which unlike normal Slack, is opt-in rather than opt-out. Even if you have channel notifications on, you’re not automatically involved in every subject that comes up unless you decide to participate. Threads can also be unfollowed at a later time to cut down on notifications for noisy ones.

Speaking subjectively, it seems to work quite well. We’re keeping all the advantages of Slack – low-friction communication, wide participation, fast synchronous conversations as needed, but without having to be attached to it at the hip every minute of the day.

It could be argued that this model isn’t sustainable, and I admit that even I had my doubts in the beginning, but here I am six months later and it’s still working as well as it did on day one. We occasionally need to onboard someone to the system, but everyone’s picked it up quickly so far.

I told an ex-colleague about this a few weeks back who’s also concerned about his own company’s internal Slack culture. He liked it, but had doubts on whether the model was scalable to a larger company. He might be right about that – so far we’ve purposely kept the team small and focused, but we might see it break down as we continue to grow.