I Actually Like Slack

As a software engineer, you really need your focus time. Unfortunately, distractions are everywhere! It might be snowing outside, or you might be wondering if now is the perfect time to get a coffee. Then it happens—someone has used Slack’s @channel tag to completely interrupt everybody else, including you.

This scenario may sound familiar. The reason is that Slack has given the nuclear codes to everyone in the company, allowing them to destroy productivity with one single command. Stories like these have led to a certain aversion to the otherwise successful communication tool. In a (pre-Covid) 2020 Wired article, Slack was even accused of having “ruined work”.

There is no doubt that Slack encourages various negative patterns. These patterns are clear enough to indicate that Slack’s design is partly flawed. Still, there are some aspects that you and your team can leverage. I believe that they can outweigh Slack’s shortcomings given the right circumstances.

Semi-Synchronous Communication

It is not easy to think and talk at the same time. It is even harder to think before you talk. If you are in the midst of discussing a possible architecture of Component X, you will need to think hard. You might want to take more time to think about it alone—but what if the discussion is already ongoing and cannot be halted?

That’s when Slack can help you. It gives you time to think for a minute about what exactly you are going to say. It gives you the opportunity to not press enter after you have written something. This has saved me from uttering nonsense countless times. Slack gives you the opportunity to think more, while keeping the conversation natural.

Informal, Yet Reconstructible

When attempting to tackle a complex or potentially even ill-defined software engineering issue, you may need to work towards a solution interactively. Slack can be the right tool for this! It even has a strong advantage over purely verbal communication: You can easily reconstruct what was said at a later point in time. Most importantly, you can reconstruct your own thoughts. This ability allows you to review and challenge your own decision-making.

Of course, technical decisions and the reasoning behind them should be documented outside of Slack—but sometimes it’s very hard to accurately translate intuitive processes into technical documents. Intuition vanishes quickly, but your message history may help to restore it.

The Problems With Slack

Despite its success, Slack really does have problems. A few of them are quite obvious:

• Mentions. It is way too easy to annoy a lot of people at once. I hope that someone in your company makes sure that @channel is reserved for emergencies (e.g. printer on fire). Still, this is clearly a design problem.
• Constant availability. Slack’s design is very similar to consumer-oriented instant messengers. This allows messages to creep into people’s free time. Managers need to actively encourage their employees to go offline—but they would not need to if Slack itself did that! I’m definitely worried about the resulting impact on work-life balance and overall employee well-being.
• Integration hell. Some third-party Slack integrations are useful. Sadly, many integrations create an unnecessary sense of immediacy for otherwise asynchronous tools. It might be better to do without them.

The above issues can be mitigated, but the mitigations need to be set in place by people with enough organizational power. Slack tries very hard to be your organization’s only communication tool. The potential of semi-synchronous communication is hindered by presumed attempts to strengthen product lock-in. This is a negative pattern in a lot of modern software. In a perfect world, everybody would probably just set up their own IRC and be free of such misaligned goals.

Given their success, I sincerely hope Slack will recognize their responsibility for improving work culture. Surely, no one wants to ruin work for good?