The Problem with Slack
Slack is a tool designed after the Facebook / Instagram / TikTok model: the goal is to maximise the number of hours that users spend inside the app. While it is reasonably good at maintaining the social structure of a group, it is a very poor tool for getting work done. The following sections explain why.
A meeting without an agenda
Every meeting room in Red Gate had a sign that said "A meeting without an agenda is a chat." This was re-enforced by our CEO who would politely decline any meeting invite without an attached agenda.
Slack channels are effectively endless meetings without a goal or agenda, and they are about as productive.
Hides other problems
Knowing whose job something is a critical part of any organization bigger than about 5 people. This allows efficiency: I don't need to worry about there being coffee in the machine, and sales don't need to worry about the software working.
Ping! Ping! Ping!
Meetings are distracting, but at least you can only fit about 8 in a day. Slack supports an unlimited number of interruptions. Deep work
Encourages sloppy thinking
Hi Bob! How are you?
Subject: Team Apex Plan to discontinue FooWidget support
Communication should be measured in terms of effectiveness, not the number of times per hour it is used. Slack defaults to a mode of writing one line of text and sending it to a large number of people. Effective communication is:
- Clear on what the goal is. Is this an announcement? A proposal? A request for service?
- Concrete and actionable.
Alice: I think we should upgrade Foo to v1.2 Bob: Why to you want to do that? Alice: To fix XYZ Bob: Does that problem exist? Charlie: Are you thinking about landing that this sprint? It is risky. Alice: Yes, we can see it in Grafana
That's a mess. What is better? A concrete proposal, written as a document and shared around.
Upgrading Foo to v.1.2 Status: Pending. I (Alive) propose we upgrade Foo from v1.0 t v1.2. Impact: This will reduce the XYZ Risks: .... Alternative #1: Use the v1.0.a hotfix. This has the problem that we Alternative #2: Migrate straight to Foo v2.0. We want this long term, but it was only released a week ago. We consider v1.2 to be more reliable
Then an explicit request, shared via email or Slack: "I've written a proposal to upgrade Foo to v1.2", please review it. Any comments are welcome.
The process of writing a document forces the person writing it to think through the problem in detail.
An email inbox is a useful record of the things that are not done yet. Slack has no such concept, and so (after receiving an interruption) I have to deal with the task immediately or move it to my own task manager, or perhaps 'save' it in Slacks backwards-inbox.
An information black hole
Consider the following abridged chat history:
- Alice: The FooWidget will ship on Wednesday
- Bob: The FooWidget will be delayed by 4 days unless Bax is completed on time!
- Charlie: Bax is ready!
A consumer of this information might want to know when FooWidget will ship. They can't tell this for a bunch of reasons:
- Is Bob's comment a statement of fact (i.e. the Plan of Record), or is it an opinion?
- Does Alice's comment take Bob's into account? If Alice is the PM, then she may already be aware of the 4 (business?) days slip and included that in her schedule
- Charlie's statement doesn't help us know if Baz completed on time. It is also unclear if 'ready' and 'completed' are the same thing. Maybe it is 'ready' for QA?
A much better solution is to switch from a 'time ordered list of changes' (i.e. list of deltas) to a set of definitive documents that contain the current state of the world. For example:
FooWidget Project Plan Owner: FooWidget PM (currently Alice) Last updated: 2022-01-01 Key Dates: Ship to beta customers: 2022-02-01 Ship all pre-orders: 2022-02-15 Definitions: 'ship' means courier booked (as per ..) Beta customers are those tagged 'beta' in Salesforce Pre-orders are as per (link to spreadsheet)'
The history of that plan is readily available in version control, and when making substantive changes Alice will naturally email the people who have asked to be Informed of changes with a short update and a link to the document. If anyone has questions or wants clarification, these can easily be added to the document as comments, and Alice can update the document to be clearer for everyone.
This may be more work than posting "FooWidget is delayed 4 days", but that work only has to be done once, and only has to be done by the sender. For any non-trivial organization the number of receivers outnumber the number of senders anyway, so it is much better to put the effort there.
Alice benefits too, because now instead of fielding requests for information such as 'Hi Alice, When will FooWidget doing to be done?', she can simply point people to the relevant document and they can self-serve the information.
Slack is a tool designed to maximise investor value, not enable effective business communication. It is an acceptable replacement for chatting around the water cooler. Grown up businesses don't use 'chatting around the watercooler' as a replacement for meetings, presentations or written plans and proposals, and Slack isn't a replacement for those things either.