The 4 downsides of Slack communication vs meetings

I'm calling it Slack throughout the article, but this applies to most mediums of async communication used in tech startups, including competitors like MS Teams and e-mail.

Slack has 4 significant downsides compared to meetings:

1. Asymmetrical workload: A quick and easy request can create many slow and hard replies
2. Lack of backpressure: The workload of receivers has no way of affecting senders
3. Exclusive low friction: It's always effortless to send messages
4. Undefined flows: Anybody can send messages to any group of people

These principles of ease for adding work and lack of controls invariably create a ballooning, unprioritized, workload.

The core issue is not with asynchronous communication but with the need for more controls.

1. Asymmetrical workloads

It takes time to write and read messages on Slack. That's work.

When you send a message on Slack, you cannot control how much time your receivers will spend working on them. And that amount can vary significantly between interlocutors.

I call that asymmetrical workload.

Here's an example of asymmetrical workload:

• Alice: "Quick question: How long would it take to finish feature X if we decided to postpone Y and focused only on X?"
• Bob: "After checking with the team, probably about 4 weeks instead of 6, but there are some risks involved."

In this slightly exaggerated example, the workload is asymmetrical. While Alice had a "quick question," Bob absolutely didn't have a "quick answer" – a typical Slack affliction.

Let's say it took Alice about 5 minutes to write this Slack message. She had to consider the possibility of working only on X, anticipate some of Bob's replies, rephrase a few times so he didn't freak out when seeing the message, and then send it.

Let's say it took Bob about 1 hour to write his Slack message. He had to think about it for a bit and then figure out how to reach out to the team to discuss it. He checked the team's board and did some story point reports for a ballpark. He checked some PRs and then replied.

Assuming an 8-hour day, Bob can only do 7 more of these exchanges today if he did no other work, while Alice can ask 95 more of these quick questions.

This is the effect of asymmetrical workload.

Let's say instead that Alice and Bob get into a meeting to discuss the same matter. While Alice and Bob work together to answer the question, they spend the same amount of time on it — a symmetrical workload.

Another effect of asymmetrical workloads on Slack is that it spreads. If Bob "checked with the team" before his reply, then Alice's quick question not only created 1 hour of work for Bob but also created some work for Charlie, Dave, and Eve.

The work added to the organization by Slack communication is, on the whole, invisible. A message sent in a channel with 40 lurkers could have created many person-hours of work in reading it. A small reply to a quick question could have cost many hours of work from the team before it was made.

This intangibility of the work created from Slack is exacerbated by another characteristic of Slack work: a lack of backpressure.

2. Lack of backpressure

"There are too many channels" – You.

Here's a more interesting question: Why are there often too many channels?

The principal reason is that it's impossible to control how many messages you get on Slack based on your current workload. Slack has no backpressure.

If Alice sends Bob a message on Slack asking "Hey Bob, I'm having trouble understanding this report's main message. Can you update the intro with a more concise headline on our main message pivot and double-check the state of the union slides to match?"

Bob's answer could be "Yes, I can do that," or "No, I can't do that," but there's no way for Alice to know unless she asks and Bob answers it.

Because there's no built-in backpressure, the receiver is fully responsible for controlling their "inbox" of communication, which is, of course, an inbox of work.

When Alice is ready to send Bob a message, Slack won't say, "Hi Alice, Bob has 9 unread Direct Messages, 38 unread channels, and 11 messages marked to reply later."

More importantly, there's no control or limit on messages. Slack won't tell Alice, "Hi Alice, unfortunately, Bob has too many channels he's in, so he can't join this channel," or "Bob has too many unread messages right now. Please try again later."

Could you imagine?

Every efficient workflow method has controls for saturation, the capacity for processed work. Kanban has "Backlogs" and "Work In Progress Limits," and Sprints have "Sprint Backlogs" differentiated from "Product Backlogs."

If Alice tries to schedule a meeting with Bob, but Bob has too many meetings, she'll fail to schedule it. She'll say, "Bob, we need to talk about feature X, but I can't find a time," and Bob can say, "Yeah, I can only do it next week," or "I'll cancel this less important meeting." That's backpressure.

In distributed systems, there are numerous controls for backpressure, such as rate-limiting, load-shedding, queuing, windowing, flow control, backpressure signals, buffering .. not unlike the ones we often try to manually implement on our own on Slack.

In short, Slack is a digital implementation of a distributed system of work across people with real saturation limits but no backpressure mechanisms.

Which is further exacerbated by the exclusive low friction of adding work to the system.

3. Exclusive low friction

Messages on Slack are very easy to send. So it's easy to add work for the system to process.

People have "saturation," a limited capacity of work one can do in a period of time. To ensure the best organizational results, your limited time must be spent on the most valuable work you can do.

When the cost of sending communication or adding work is very low, the system's natural tendency is to have a higher density of less important communication, or work, added to it.

Because Slack communication is work, it carries an opportunity cost — it competes with other work you and others in the organization would otherwise do.

A low-friction way of adding work to a backlog will tend to clutter the backlog. Under that circumstance, an increased effort of triaging and backlog grooming is necessary to ensure the most important work is done.

Unfortunately, on Slack, there are no such controls for triaging, backlog grooming, and so on for work added to the system. Every communication is processed, and the backlog is treated and managed ad hoc, varying by individual.

Another characteristic exacerbates this ease of adding work to the system: work can easily be added, without controls, to any group of people.

4. Undefined flows

In Slack, it's unclear who can send which messages to whom. That's an undefined flow of communication and work.

At least it's not a completely out-of-control system. Many communication flows on Slack are shaped by social norms, team dynamics, and existing channels. While technically, I can send a direct message to everybody in the organization, I won't. However, I can often post on a channel with everybody in the department or send a new direct message to several individuals in the organization.

Additionally, it's not always clear who will receive my communication. Email requires a "To:" or "Cc:" but Slack channels often have only the number of people and a few thumbnails in it.

The mindset is that Alice is not sending messages to other people — she's sending them "to a channel."

But of course, you and other people are on the receiving end of all those channels.

Channels don't read messages; people read messages.

And that's where the "there are too many channels" observation comes in. Every channel is a potential communication flow from N participants to you, adding to your work.

Because there are no rules or principles for channel creation or participation, there can always be more channels and more participants.

This lack of limits and clarity on the flow of information makes it so that work that enters Slack can spread unchecked and significantly hinders the ability to prioritize it carefully.

So work flows from one person to N people in undefined and uncontrolled ways, unchecked.

OK, but what can you do about it?

Well, yes, this is quite a list of shortcomings, on top of other drawbacks already discussed elsewhere.

But what are some potential ways to mitigate them?

1: Asymmetrical workload:

Mitigation: Call meetings to respond to hard-to-answer questions.

When you get into a meeting, you and every other participant must spend the same amount of time on the problem.

While this may cost more time to some participants, typically the initiator, it can lead to more collaboration, better communication, and collective efficiency.

The symmetric workload of the meeting will also ensure the amount of work necessary is visible, e.g., a 1-hour meeting, and that it gets allocated sometime, e.g., Thursday, 2pm.

2: Lack of backpressure: The workload of receivers has no way of affecting senders

Mitigation: Convert work into tasks and agenda topics and prioritize accordingly.

When every message you receive must be worked on as soon as possible, you cannot prioritize and cannot convey your capacity to the initiator.

If messages go to a backlog instead, the actual work of addressing the message can then go into your everyday workflow, where it will compete with your other work for prioritization.

If you have a recurring meeting with the initiator, add it to your meeting agenda and let the agenda prioritize its importance.

3: Exclusive low friction: It's always effortless to send messages

Mitigation: Use status indicators and prioritize and batch process your replies

Context switching on Slack makes processing messages one by one very expensive. For example, the amount of work you can do in a day, particularly deep work, can be significantly diminished if you check Slack every few minutes.

Because the low friction for sending messages can lead to more trivial messages for you to read, reading and replying to all messages over a 30-minute block can be much more effective than one-by-one as they arrive over those 3 hours.

Use status indicators to indicate you're in meetings or in focus time, and find the next time within the next 3 hours when you have a free 30 minutes to check and reply to all messages.

Note: On Slack for Mac, you can press Cmd+Shift+A to list all messages to process and press Esc to mark them as read.

4: Undefined flows: Anybody can send messages to any group of people

Mitigation: Mute and leave channels and encourage messages through channels.

You must curate the channels you participate in through time.

Channels are 'opt-in' taps you make into communication flows, and in Slack, you are responsible for actively managing your communication flow.

When you receive direct messages, especially Group DMs, see if there should be a channel for that communication. This will ensure the right stakeholders are involved and help you map and manage the communication flows to you.

Slack is here to stay

Almost every organization uses e-mail, and most tech startups use Slack or a competitor.

Asynchronous communication is here to stay.

While Slack has many drawbacks, it's a powerful tool. As with any powerful tool, the value you get depends on your skill to yield it.

So don't expect Slack to naturally work optimally for you from the get-go or without any management or skill building on your part.

Instead, consider its strengths and weaknesses and shape your use of it to do your best work.

And remember to use meetings and other forms of communication when they can offset some of these downsides, using the best tool for the job.