Async-first doesn't mean never meeting. Teams that interpret it that way usually end up with poor coordination and a growing list of decisions that nobody feels accountable for because nobody was ever in the same conversation. Async-first means: written, durable communication is the default, and synchronous communication is reserved for cases where it genuinely adds value that async cannot.
That's a harder bar than it sounds. Most teams are sync-first by default — not because anyone decided it, but because synchronous communication is lower friction for individuals even when it's higher cost for the team. An async-first culture requires deliberate infrastructure, deliberate practices, and deliberate resistance to the pull toward "let's just jump on a quick call."
The problem with "async" as a mode versus async as an infrastructure
Many distributed teams claim to be async-first and mean: we use Slack instead of email, and we don't require people to be online at the same time. That's timezone flexibility. It's not async-first.
Async-first is an infrastructure property, not a scheduling property. It requires that the output of async communication is durable and retrievable — that decisions made in a Slack thread, a Loom recording, or a Notion comment don't require someone to have been present to understand what was decided and why. The fundamental test: can an engineer who joins the team six months from now reconstruct the reasoning behind major architectural decisions without asking anyone? If the answer is no, the team is distributed — it just happens to use async tools.
The distinction matters because the failure modes are different. Timezone flexibility without durability creates the same knowledge debt as synchronous teams — just slower. Decisions get made asynchronously, the reasoning lives in threads and recordings that are hard to retrieve, and institutional context still concentrates in the heads of people who were present. The team has traded synchronous coordination cost for asynchronous context loss.
What async communication is actually good at
Async communication has genuine, non-trivial advantages over synchronous for specific decision types. Understanding which decision types benefit clarifies when to default to async and when to escalate to sync.
Complex proposals and technical designs. Async is better than synchronous for decisions involving complex technical material. A written RFC (Request for Comments) or design document allows reviewers to read carefully, check their own knowledge, look things up, and respond when they have enough context to respond well. A synchronous "design review" meeting produces responses that are bounded by what participants can hold in working memory while listening.
Decisions requiring diverse input. Synchronous discussions are dominated by whoever is most comfortable speaking in meetings. Async threads produce more equal contribution because the social dynamics of speaking are replaced by the lower-friction act of replying. Teams that have moved high-stakes decisions to async threading often report input from engineers who rarely spoke in meetings.
Cross-timezone decisions. The obvious case. A team with engineers in Lyon, Warsaw, and Singapore can't make most decisions synchronously without someone taking a call at 11pm. Async-first doesn't just accommodate this — it makes the timezone spread an asset rather than a constraint, because the extended decision window allows more thorough consideration.
Scenario: the RFC process that changed a team's architecture velocity
A distributed engineering team of twenty-two engineers — with members across Western Europe and Southeast Asia — moved from synchronous architecture reviews to an asynchronous RFC process over six months. The initial motivation was simply time zone coverage: half the team couldn't attend the weekly architecture sync at a workable hour. The process: significant architecture proposals are written as structured documents, circulated to the team with a five-day comment window, and resolved by the tech lead with a written decision rationale posted to the team's decision log.
After twelve months, the team observed several changes. Decision throughput increased — more architecture decisions were being made per quarter, not fewer, despite removing synchronous review meetings. The written rationale requirement produced decision records that reduced re-investigation significantly: when a new engineer questioned an infrastructure choice, the decision document answered the question without escalation. Senior engineer time previously spent in weekly architecture review meetings was freed for higher-value technical work. The one genuine loss: early-stage brainstorming quality declined, because the free-form discussion of a whiteboard session is genuinely hard to replicate async. The team addressed this by adding a distinct "exploration" phase — a 45-minute synchronous session reserved specifically for early-stage thinking before any proposal was written.
Building the muscle: what async-first actually requires teams to change
Shifting to async-first is a behavioral change more than a tooling change. The tooling is necessary infrastructure, but it doesn't produce the behavior on its own. The specific habits that distinguish teams with functional async-first cultures:
Writing for readers who weren't there. Async communication assumes an absent audience. Writing a Slack thread update or a Notion decision note for "the people on this channel right now" produces messages that lose all context in three months. Writing for "an engineer who joins in six months and needs to understand this decision" produces messages that function as institutional memory. The mental shift is small but its effects compound significantly.
Explicit decision artifacts. Async discussions produce decisions but don't automatically produce decision records. Teams need an explicit closing convention — a final message, a Notion page update, a labeled thread reply — that states "we decided X, here's the reasoning, here are the alternatives we didn't choose." Without this, the thread is both the discussion and the record, and the record is buried in the discussion.
Response window norms. Async doesn't mean slow. Effective async-first teams set explicit response time expectations — typically 24 hours for routine questions, 48 hours for design review input, immediate for production incidents. Without these norms, "async" becomes "we reply whenever we get to it," which creates unpredictable decision latency and a natural gravitational pull back toward synchronous calls as the faster alternative.
The meeting you should never eliminate
We're not saying all synchronous communication is waste. Some of it is irreplaceable. Early-stage brainstorming, onboarding conversations, high-stakes interpersonal discussions, team cohesion — these have properties that async tools don't match. The goal of async-first is not to eliminate synchronous communication but to stop using it for things that don't need it: status updates, information sharing, decisions that could have been made in a thread.
The test for a meeting: would this achieve the same outcome if it were a written async thread? If yes, it should probably be a thread. If the discussion benefits from real-time back-and-forth, visual collaboration, or the social function of a shared experience — it's worth the synchronous overhead.
Async-first culture is built incrementally, not declared. Teams that try to flip a switch usually find that async-first without the documentation infrastructure produces slower decisions without better knowledge retention — the worst of both worlds. The infrastructure comes first: durable decision capture, structured communication norms, retrieval systems that work. The culture follows the infrastructure, once engineers see that writing decisions down actually saves them time later rather than costing it now.