Async communication is having a moment. Remote-work advocates treat it as the cure for calendar overload, and productivity consultants sell it as the path to deep work. The advice is usually the same: fewer meetings, more Slack, use a tool like Loom or Notion. Install the infrastructure and watch the focus time appear.
This is wrong, or at least badly incomplete. The teams that actually get async right aren’t distinguished by their tool stack. They’re distinguished by the quality of their written thinking. Async communication, done well, is a writing discipline. And most teams are nowhere near ready for it.
The real bottleneck is precision, not meetings
Here’s what happens when a team cuts meetings without fixing their writing: they trade one type of interruption for a worse one. Instead of a 30-minute standup, you get a 3-hour thread where nobody agrees on what the question even is, followed by a synchronous call to sort it out anyway.
Think about a pull request review as a proxy for async communication quality. A well-written PR description tells reviewers what changed, why it changed, what tradeoffs were made, and what the reviewer should focus on. A bad one says “fixed the bug.” The difference isn’t the tool (both use GitHub). The difference is whether the author understood that their future reader doesn’t have context and can’t ask follow-up questions in real time.
That same dynamic plays out in every async message. A Slack message that says “thoughts?” with a link to a doc is synchronous communication wearing async clothing. It’s pulling someone into your context without doing the work to transfer that context first. The recipient has to reconstruct what you were thinking, what you want from them, and what kind of response would be useful. That reconstruction is expensive, and it usually isn’t done well.
Writing for a reader who isn’t there yet
The specific skill async requires is writing for a reader who is separated from you by time, context, and attention. This is genuinely hard. It’s what good technical documentation requires, what a good architecture decision record (ADR) requires, what a good project brief requires.
Good async writers do a few things consistently. They front-load the ask. They separate facts from opinions. They pre-answer the obvious objections. They specify what kind of response they need (decision, feedback, FYI). They include enough context that someone coming in cold can follow the reasoning without asking three clarifying questions.
None of this is natural. Most people write as they think, which is exploratory and assumes shared context. Translating that into reader-ready writing takes deliberate effort, and most organizations don’t train for it or reward it.
The relationship between attention and interruption matters here too. Async only protects focus if the messages people receive are self-contained enough that they can be processed in a single read and a short reply. A message that spawns a thread is an interruption that reproduces.
Async creates a written record that requires you to be right
There’s a side effect of good async culture that people underestimate: accountability. When decisions happen in meetings, the record is whatever someone chose to write down afterward. When decisions happen in written threads, the reasoning is preserved and auditable.
This is uncomfortable for organizations that prefer ambiguity. It’s also why some teams resist async, though they won’t say that’s the reason. Writing forces you to commit. If you recommend an architecture in a document and it turns out badly, the document exists. If you said it in a meeting, the record is fuzzy.
High-performing async teams treat this as a feature. They build up a corpus of written decisions that new team members can actually read. Onboarding becomes faster because institutional knowledge lives in documents, not in people’s heads. The codebase has context. The bugs that never get filed often don’t get filed because nobody wrote down why a decision was made; good async culture closes that gap.
The counterargument
The pushback I hear most often is that async favors certain personality types, specifically people who write well and think clearly in text, and disadvantages people who communicate better verbally or who need rapid back-and-forth to think through problems.
This is a legitimate concern, but it proves too much. Meetings favor people who are verbally quick and politically confident. They disadvantage people who need time to think before responding or who get talked over. Neither mode is neutral. The question is what skills you want to reward and what outcomes you want to optimize for.
I’d also push back on the idea that requiring clear written thinking is a gatekeeping mechanism rather than a craft worth developing. Writing clearly is learnable. Organizations that treat it as a core competency and invest in developing it tend to end up with better async cultures than organizations that just buy Notion and cancel half their meetings.
There are also genuinely synchronous problems: rapid debugging sessions, high-stakes interpersonal conflicts, creative brainstorming that depends on loose association and fast iteration. The mistake isn’t using synchronous communication for those things. The mistake is using it as the default for everything and calling that normal.
Async communication is a bet on writing
The thesis stands: async done well is a writing problem. Teams that get it right have invested in writing as a skill, built norms around what good async communication looks like, and created accountability for the quality of what gets written. They haven’t just changed their tools or their meeting schedules.
If you want to move toward a genuinely async culture, the first question to ask isn’t “which tool should we use?” It’s “how good is our team at writing for a reader who isn’t there yet?” The honest answer to that question will tell you more about your readiness than any productivity survey.
