The Promise Was Real
Async communication had a genuine, defensible case behind it. Meetings fragment attention. Calendar coordination consumes time that could go toward actual work. Synchronous communication forces everyone to be in the same mental context at the same moment, which is expensive to arrange and even more expensive to recover from when it goes sideways. The research on this is solid: Gloria Mark’s work at UC Irvine found that recovering focus after an interruption takes around 23 minutes, and a meeting-heavy day produces almost none of the uninterrupted stretches that difficult technical work requires.
So the appeal of async was legitimate. Write it down, send it when you’re ready, let the recipient read it on their own schedule. The theory was that you’d replace a thirty-minute standup with a two-paragraph Slack update, free up everyone’s mornings, and still keep the team aligned.
The theory was correct. The implementation was catastrophic.
What Actually Happens at Scale
Here’s the failure mode, described precisely: async tools optimized for sending, not resolving. Slack, Microsoft Teams, email, Notion comments, GitHub PR threads, Jira tickets, Linear issues, Confluence pages with inline comments, Loom videos, voice messages in WhatsApp threads that somehow became part of your work life. Each of these is a place where a question can be asked and where that question can quietly wait for an answer indefinitely.
The problem is not volume, though volume is real. The problem is that every unresolved async message is a dependency with no timeout. In software terms, it’s a blocking call that never throws an exception. The thread just sits there, waiting. The person who asked the question moves on to something else, loses context, and has to reconstruct their entire mental model of the problem when the answer finally arrives three days later. The person who received the question adds it to a queue they process whenever they get around to it, which means it gets answered based on their schedule, not based on when it’s needed.
You have now reproduced the exact latency problem that synchronous meetings were supposed to solve, except now the latency is measured in days and the context loss is worse because nothing was captured in real time.
The Notification Paradox
The obvious response to latency in async systems is notification. If you ping someone and need an answer, you can @ them, mark it urgent, send a follow-up. This is where the wheels come off entirely.
When everyone is in multiple async channels and every message is potentially time-sensitive to someone, the only rational individual response is to treat all of it as potentially urgent. Which means checking constantly. Which means you are now in a system that is formally async but behaviorally synchronous, except worse: you’re synchronous without the benefits of being in the same context as the person you’re communicating with.
A meeting, for all its costs, at least gives everyone shared context. When you sit down together, you can read nonverbal cues, interrupt to clarify, and reach resolution in real time. A Slack thread where both parties are online simultaneously and typing responses at each other has none of that. You get the interruption cadence of synchronous communication with the ambiguity and latency of async. It’s strictly worse than either.
This is not a hypothetical. Watch any technical team during an incident. Within minutes, Slack becomes a real-time war room where multiple people are sending messages in parallel, messages are crossing in transit, and people are re-asking questions that were answered three messages ago because the thread is moving too fast to read. The medium was designed for async use and is being used synchronously, and it handles that use case poorly.
The Structural Problem Underneath
There’s a deeper issue here that tool criticism misses. Async communication fails not because the tools are bad but because organizations adopted async as a communication style without thinking about it as a system with defined interfaces.
When you write a function that communicates with another function, you have to specify: what are the inputs, what are the outputs, what happens if the other function doesn’t respond, and how long should the caller wait before giving up. Those are called contracts or interfaces. Async communication at work has almost none of this. Messages go out without a defined expected response time. There’s no established norm for what constitutes an urgent question versus one that can wait until tomorrow. There’s no agreed-upon escalation path when async fails. There’s no acknowledgment protocol to distinguish “I saw this and I’m thinking about it” from “I haven’t seen this yet.”
The result is a system where every participant is individually rational and the collective outcome is dysfunctional. You check Slack constantly because you don’t know when your question will be answered and you need the answer. Your colleague answers quickly because they know you’re waiting and they feel social pressure to respond. Neither of you wanted to be in a real-time messaging system. You ended up there anyway because the alternative, waiting with no feedback, is psychologically intolerable.
Why Written Async Is Hard Even When It Works
Even when async communication functions as intended, there’s a skill problem that organizations systematically underestimate.
Good async communication requires writing that anticipates confusion, provides context the reader won’t have, and reaches a conclusion rather than just describing a situation. That’s hard. Writing a Slack message that genuinely unblocks a decision requires understanding what the recipient knows, what they need to know, and what specific action you’re requesting. Most people, most of the time, don’t write messages that way. They write messages the way they’d start a conversation: incomplete, context-dependent, expecting a back-and-forth.
The result is chains of clarifying messages that take longer than a five-minute conversation would have. The async channel becomes a transcript of a conversation that never quite happened.
There’s a version of async communication that works, and it involves treating the medium like a protocol with defined norms. Write complete thoughts. State the decision or action you need. Include the relevant context. Make it easy to respond with a single yes or a specific answer rather than requiring the recipient to write three paragraphs. Most teams never establish these norms explicitly, so they never get the benefits.
The Meeting Replacement That Wasn’t
The deepest irony is what async culture actually replaced. It replaced bad meetings (too many, too long, poorly run) with a different system that has its own pathologies, without actually eliminating the meetings.
Talk to teams that went fully async-first and dig into how they actually operate. What you typically find is a two-tier system: there’s the official async layer of Notion docs and Loom updates, and there’s the informal synchronous layer of spontaneous Slack calls, hallway conversations (in offices) or random video calls (remote), and the periodic catch-up meeting that got added because people felt misaligned. The official async processes create artifacts. The actual decisions happen in the informal synchronous layer. Nobody writes up the informal synchronous conversations in the async channel because it feels redundant.
Now you have two parallel systems running simultaneously, and neither is fully canonical. Context lives in people’s heads and in scattered channels. Decisions made in a video call aren’t in the Linear ticket. The Notion doc reflects the state of thinking three weeks ago. New team members have no idea where to find information because the answer is “everywhere and nowhere.”
What This Means
Async communication is the right tool for a specific job: transmitting complete, considered thoughts to recipients who don’t need to respond immediately. That’s a narrower job than most teams use it for.
When a question is blocking work, that’s a synchronous problem. Use synchronous tools. When a decision has a hard deadline, write that deadline into the message explicitly. When async threads are generating more follow-up questions than they’re answering, convert them to a meeting, decide, and write up the outcome. The goal is resolution, not adherence to a communication philosophy.
The teams that use async well have done one thing most teams skip: they defined, explicitly and collectively, what kind of message belongs in what channel, what response time is expected, and when async should escalate to synchronous. Those agreements are boring to establish and painful to enforce. They are also the only way to get the actual benefits that async was supposed to deliver.
The problem was never meetings versus messages. The problem is that coordination has an irreducible cost, and every tool that promises to eliminate it is actually just redistributing it. Sometimes the new distribution is better. Sometimes it’s worse. Whether it’s better depends almost entirely on how deliberately the system was designed, not on which software you bought.
