Most teams that claim to do async communication are actually just doing delayed synchronous communication. There’s a difference, and it’s the reason why so many remote-first experiments end in frustration and a return to wall-to-wall video calls.
Real async communication is a coordination protocol, in the networking sense of that word. A protocol defines not just how messages are formatted, but when they’re sent, what response they obligate, and how state gets synchronized between parties. Teams that treat async as “just send a message and wait” are missing the protocol layer entirely. The message format is the easy part.
The Confusing Part: Async Isn’t About Tools
Slack, email, Notion, Linear, Basecamp’s Campfire, none of these are async communication systems. They’re message carriers. The protocol lives in the team’s agreed conventions about what each channel means, what response time is expected, and critically, what information must be written down versus what can exist only in someone’s head.
GitLab, which has been remote-first since its founding and publishes its internal handbook openly, makes this concrete. Their handbook doesn’t just say “communicate async”; it specifies that decisions must be recorded in the merge request or issue that prompted them, not in Slack threads that will scroll away. The tool is GitLab (obviously). The protocol is “the artifact contains the reasoning.”
That distinction matters because when a new team member joins six months later, the question “why did we choose postgres over mysql here” should have an answer that doesn’t require finding the person who remembers the meeting. Most teams answer that question with institutional memory. Protocol-based async teams answer it with a document.
Why Synchronous Defaults Are So Sticky
Understanding why async is hard requires understanding why sync feels easy. When you pull two people into a Slack huddle or a quick Zoom call, you’re exploiting the human capacity for rapid back-and-forth disambiguation. You can say an imprecise thing, notice the confusion on someone’s face (or the clarifying question in the chat), and correct course within seconds. The feedback loop is tight.
Writing for async forces you to front-load that disambiguation. You have to anticipate the questions, address the ambiguities, and provide the context that you’d normally deliver reactively. This is genuinely harder than talking, and anyone who tells you otherwise is either a very good writer or someone who doesn’t write very much.
The cognitive load of composing a clear async message is higher than the cognitive load of having a quick call. What async buys you is a different thing: it buys the recipient the ability to read it at a time when their brain is actually ready, rather than being pulled out of deep work to process your half-formed thought. The research on interruption recovery makes this concrete. The cost isn’t just the call itself, it’s the 20-plus minutes of context reconstruction afterward.
So async isn’t free. It shifts cost from the recipient’s attention to the sender’s composition effort. Companies that have figured this out have made that shift explicit and supported it.
What a Real Async Thread Looks Like
Here’s a structural comparison. An immature async thread about a product decision:
Alex: Hey, should we use server-side rendering or static generation for the docs site?
Jamie: Probably SSR? IDK
Alex: ok
That’s not async communication. That’s synchronous communication with delays. Nothing is captured, no reasoning is visible, and if Alex and Jamie are both hit by a bus (to use the classical engineering scenario), their successor has nothing.
A protocol-aware async message:
Context: We're building the docs site for v2. I've been looking at our options.
Proposal: Static generation (Next.js static export or similar)
Reasoning:
- Docs content changes at most twice a week on deploys, not on user request
- Static files serve from CDN with no compute cost
- Our current traffic patterns don't require per-request personalization
- SSR would require us to run and maintain a Node server; we don't have ops capacity for that
Downsides I've considered:
- Search will require a client-side index (Algolia or Pagefind), which adds build complexity
- If we ever need user-specific docs (role-based content), we'd revisit
Default plan: Proceed with static unless someone has a blocking concern by EOD Thursday.
This message does more work than a meeting. It captures the decision context, the alternatives considered, the tradeoffs acknowledged, and a clear timeline for input. Six months from now, anyone on the team can read that thread and understand why the site works the way it does.
The Deadline Is the Secret Weapon
Notice the last line of that example: “Default plan: Proceed unless someone has a blocking concern by EOD Thursday.” That’s the piece most teams skip, and it’s where async communication actually collapses.
Async without deadlines becomes async without decisions. Messages float in inboxes and channels indefinitely, people feel vaguely obligated to respond but never urgently so, and the whole thing defaults back to someone calling a meeting to “get everyone aligned.”
The deadline transforms the communication from a question into a proposal. Proposals default to yes if nobody objects by a defined time. Questions don’t resolve themselves. This is borrowed directly from how mature open-source projects handle RFC (Request for Comments) processes: you open the RFC, set a comment period, and after the period closes, the proposal is either accepted, modified based on feedback, or rejected. The decision is made regardless.
The psychological shift is real. When people know that silence equals consent, they pay closer attention to proposals in their domain. When they know they can object, they’re less anxious about not being in the room. Both of these are good outcomes.
How Timezones Reveal the Truth
The clearest test of whether a company has actually internalized async communication is how they handle timezone distribution. If every important decision still requires the New York and London offices to find overlapping meeting time, the company is doing sync with extra steps.
Companies that have figured this out build what might be called “decision queues”: structured processes where decisions enter a queue in a written state, sit for a defined review period, collect comments from whoever’s awake and relevant, and then close. The timezone of the participants is irrelevant, because no single moment of presence is required.
Automattic (the company behind WordPress.com and several other products) operates this way across a team distributed across many countries. Their primary coordination tool has historically been P2, a WordPress theme that turns a blog into an internal communication feed, specifically because it forces threaded, written communication with permanent URLs. The permanent URL is load-bearing: when a decision has a URL, you can link to it, reference it, and find it later. A Slack thread that scrolls away doesn’t have that property.
The Infrastructure Async Requires
You cannot do async communication well without documentation infrastructure, and most teams underinvest here dramatically. The documentation I mean isn’t polished wikis or marketing copy. It’s working documentation: the ADRs (Architecture Decision Records) that capture why code looks the way it does, the “how we work” documents that explain team conventions, the project briefs that front-load context before work begins.
This is more like good documentation practice than most people realize. The skills that make someone good at writing internal docs are the same skills that make async communication functional: anticipating the reader’s questions, providing context without burying the point, and being specific enough that the document remains useful as conditions change.
The tooling matters less than teams think. Notion, Confluence, even a well-organized Google Drive with naming conventions will work if the team has the discipline to use it. The discipline is the hard part. Building the habit of writing things down requires leadership that models the behavior and explicitly rewards it, which means not rewarding the opposite behavior (the brilliant colleague who knows everything and is therefore required on every call).
What This Means
Async communication that actually works isn’t a culture thing in the vague sense. It’s a set of concrete practices:
Messages are proposals, not questions. Frame communication as “here’s what I think we should do, object by this date” rather than “what should we do?” One resolves itself; the other requires a meeting.
Reasoning lives with the decision. The artifact (the PR, the issue, the doc) contains not just the outcome but the tradeoffs considered and rejected. Future-you and future-colleagues are the intended audience.
Channels have explicit contracts. Everyone on the team knows which channel requires a response within two hours, which one is read-only broadcast, and which one is informational and optional. Without this, people treat every message with the same vague anxiety and nobody can predict their own day.
Silence is a valid (defined) response. When a proposal closes with no objection, that’s a decision, not an oversight. Treating it otherwise destroys the trust that makes async work.
Writing is a first-class skill. Teams that are good at async hire for writing ability, develop it in existing team members, and create space (meaning: actual time, not just permission) for people to write carefully rather than quickly.
The companies that have worked this out aren’t using magic tools. They’ve accepted that coordination always has a cost, and made a deliberate choice about who bears it and when.
