The (different) Frustrations of Slack and Email
Recently, there has been a spate of articles on the frustrations of Slack. In Slack, I’m Breaking up with You, Samuel Hulick writes about the frustrations of using Slack. Specifically, he cites the “exponentially more messages” he receives and his need to be “always on”. In Slack Isn’t the Problem, We Are, Preslav Rachev essentially throws up his hands, saying that these problems don’t necessarily have a solution and that we need to use tools like Slack differently, for example, by liberal use of features like “Do Not Disturb”.
In my opinion both of these posts get it partly right. Both of these articles also have as a subtext an implicit or explicit comparison with email. Both, Slack and email tend towards “communication overload”. However, the generic description of “communication overload” obscures the very different type of overload created by these two technologies. Understanding this distinction also leads us to a possible solution.
Slack et al are fundamentally synchronous communication tools. i.e. they work best when “everyone” is present simultaneously. In essence, you need to be “present” in order to make the most of a chat tool. Unfortunately, being present all the time means that you are constantly interrupted and can lose productivity as a result. One solution is to go into a “Do Not Disturb” mode. But then no one can reach you at this time. With everyone going into “Do Not Disturb” modes at different times, you need to engage in opportunistic communication. i.e. you communicate with who happens to be around rather than who you necessarily need to communicate with. So, “Do Not Disturb” by itself is no panacea. Other authors have suggested “office hours” or “chat meetings” to overcome this problem. The tweet below, takes the “office hours” and “chat meetings” concept to its Dilbertesque conclusion.
EMail on the other hand is an asynchronous communication tool. There is no expectation that the recipient is simultaneously available when an email is sent. This avoids the aforementioned pitfalls of Slack but introduces another one, i.e. the dreaded overflowing inbox. In Slack (and chat tools generically), the presence (or lack thereof) of another party acts as a natural brake on the sender. In email this natural brake is missing and hence there is no limit to what a sender can put into your inbox.
The important thing to notice is that the frustrations these two tools engender are very different (i.e., the need to be always present vs. dealing with an overflowing inbox) and oddly distinct. This leads to the “obvious” solution that we need to combine these two tools in such a way that plays to their strengths.
Unfortunately, email was invented over 40 years ago and was not really designed to inter-operate with Chat. Further, even as an asynchronous communication tool, email leaves a lot to be desired. In the article referenced below, I describe the characteristics of what a next-generation asynchronous communications tool that integrates with chat might look like.
So, in summary, the solution to our communication woes may be to use Slack for opportunistic, synchronous communication integrated with a modern asynchronous communication tool for asynchronous communication.
