# Async Communication Playbook for Distributed Teams (What Actually Ships) The shift to distributed work after 2020 was partly voluntary, partly enforced by circumstance, and in many organizations, partly reversed. The companies that stayed distributed and continued to perform well tended to share a specific characteristic: they had made the shift from sync-default to async-default communication an explicit strategic choice, with documented practices, tooling investments, and cultural norms that supported it. The companies that struggled tended to run distributed work on sync-first patterns ported from the office, which produces meeting creep, time-zone exploitation of the workers in the worst zones, and context loss at scale. The difference was not remote versus in-office. The difference was async-first versus sync-default. This piece is the working playbook for teams that want to build or improve their async communication practice. It draws on published material from GitLabs handbook (the most extensive open documentation of an async-first operating system), Automattics all-remote history, Doists writings on async as a cultural commitment, and the research on distributed work from academics like Erin Meyer, Amy Edmondson, and Nicholas Bloom. Expert-written and research-backed, it is aimed at team leaders, managers, and individual contributors who need operational detail rather than general philosophy. > "Asynchronous does not mean slow. When done well, async is faster than sync for most knowledge work because it removes the latency of scheduling, parallelizes decision-making across time zones, and produces documentation that reduces the need to repeat conversations. The speed comes from compression, not from urgency." -- Darren Murph, formerly Head of Remote at GitLab --- ## The Fundamental Question: What Requires Simultaneous Presence? The starting point for any async practice is categorizing communication by whether it genuinely requires simultaneous presence. Most communication does not. A surprisingly small fraction benefits from real-time exchange enough to justify the scheduling cost, time-zone friction, and loss of written record that sync introduces. The categories that benefit from sync: **High-bandwidth creative divergence.** Early-stage brainstorming where ideas trigger other ideas rapidly, and the visual and tonal cues of live conversation add meaningful bandwidth. This is a real use case, but it applies to a small fraction of meetings that claim to be for this purpose. **Conflict resolution and relationship work.** Reading silence, tone, facial expression, and the timing of responses is part of the content in these conversations. Written exchange often escalates rather than resolves. **Complex negotiation with multiple variables.** Dynamic negotiation with real-time offer-counteroffer benefits from sync bandwidth. Our coverage on salary negotiation scripts touches on the sync-async tradeoff in negotiation contexts. **Onboarding and apprenticeship of close collaborators.** The informal tacit knowledge transfer that happens in direct mentorship benefits from sync exposure. **Trust repair after damage.** Rebuilding trust after conflict or breakdown requires presence in a way written communication cannot replicate. The categories that do not require sync, despite often being defaulted to sync: **Status updates.** Async text or recorded video with threaded comments is better. **Information transfer.** Documentation plus async Q&A is better. **Most decisions.** Written decision records with comment periods produce better-documented and often better-quality decisions. **Code review and design review.** Async review cycles with written feedback are standard practice in distributed engineering organizations for good reason. **Performance check-ins outside formal review cycles.** Often better as async written reflection plus occasional sync deep-dives. **Routine one-on-ones.** Mixed async and sync patterns outperform pure-sync, with async updates freeing sync time for conversations that actually need it. | Communication Type | Default Mode | Reason | |---|---|---| | Daily standups | Async written | Saves 30-60 min/person/day; better record | | Status reporting | Async written | No new information in sync form | | Code review | Async | Review is naturally async work | | Design iteration | Mixed (async default, sync for breakthroughs) | Solo design work benefits from async review cycles | | Brainstorming | Mixed (async ideation first, sync for convergence) | Async allows more diverse input; sync closes | | Conflict resolution | Sync (with async follow-up documentation) | Requires real-time tonal reading | | Onboarding | Mixed | Initial ramp benefits from sync; ongoing works async | | Customer escalations | Sync if urgent, async if not | Urgency thresholds apply | | Strategic planning | Mixed (async docs, sync debate sessions) | Documents produce better input; sync produces decisions | | Hiring interviews | Sync (with async components for take-homes) | Signal loss too high in fully async interviews | --- ## The GitLab Model GitLab is the most extensively documented example of async-first at scale. With roughly 2000 team members across more than 65 countries and no central office, GitLab has published its handbook openly, which lets outside readers examine how an async-first company actually operates. The core principles in the GitLab handbook include: **Single source of truth.** The handbook is the authoritative reference for how things work. Conflicting information in Slack, email, or meetings is subordinate to the handbook. When a practice changes, the handbook changes, and the change is communicated. This eliminates the distributed-team problem of different people operating on different information. **Default to public.** Discussions happen in channels, issues, and documents that are visible to the whole company (with appropriate privacy carve-outs for HR and legal matters). Private DMs are discouraged for work content because they create information silos that cannot scale. **Written communication over verbal.** Even when sync conversations happen, key decisions and context are written up afterward. The written record is what future team members, team members in other time zones, and search operate on. **Asynchronous as default meeting pattern.** Meetings happen when sync is genuinely the better mode, with explicit justification. Agendas are distributed in advance with expected reading. Decisions are documented after the meeting, not during it. **Low-context operations.** Processes are documented enough that a new hire can understand what to do by reading, rather than relying on tribal knowledge transmitted verbally. High-context organizations (where you have to ask around to learn how things work) cannot scale asynchronously across time zones. The trade-offs GitLab accepts are real. Documentation cost is significant: creating and maintaining the handbook takes real time. Onboarding has a learning curve: new hires have to become fluent in finding information in the handbook rather than asking colleagues. Some spontaneity and relationship-building that happens in offices does not emerge naturally and has to be manufactured through deliberate practices. GitLab has made these trade-offs work, but the trade-offs themselves are visible. For readers building out documentation infrastructure, the writing craft matters substantially. Our coverage at [evolang.info](https://evolang.info/) on professional writing frameworks applies directly to the documentation practices async-first companies depend on. Business formation contexts that involve distributed teams from the start benefit from the structural considerations at [corpy.xyz](https://corpy.xyz/). --- ## The Daily Operating Rhythm A functional async-first team has daily, weekly, and monthly rhythms that keep work moving without requiring constant sync coordination. **Daily async standup**. Written post in a dedicated channel, typically in the morning for the individual (not a shared morning across zones). Three questions: what was shipped yesterday, what is being worked on today, what is blocked. Posts are brief (a few lines, not essays) and read asynchronously. Teammates respond to blockers. The ritual takes 3 to 5 minutes to write and substitutes for a sync meeting that would take 15 to 30 minutes of everyones time. **Documented work-in-progress.** The code, document, or design being worked on is visible in the shared system (GitHub, GitLab, design tools, docs tools). Work-in-progress visibility reduces the need for status requests because status can be checked by looking at the artifact. **End-of-day summary for complex work.** For work that spans multiple days or involves multiple people, an end-of-day summary post captures the state, decisions made, and open questions. The summary is not for the writers benefit; it is for the next person who picks up context (which is often the writer the next morning, in a time-zone-shifted way). **Weekly plans and retrospectives.** At the start of each week, a team post outlines priorities for the week. At the end of each week, a brief retrospective captures what shipped, what slipped, what was learned. These are async rituals that replace the sync versions common in colocated teams. **Monthly or quarterly planning.** For longer horizons, async planning documents with extended comment periods (a week or more) produce richer input than 90-minute planning meetings. Decisions converge through written debate; sync sessions, if any, focus on resolving specific disagreements that could not be resolved in writing. The rhythms matter because async requires rhythms. Without them, async drifts into chaotic individual schedules that do not coordinate. With them, async produces rhythmic predictability that often exceeds the felt predictability of sync-default teams. > "The thing no one tells you about async is how much structure it requires. You cannot just replace meetings with Slack messages and call it async. You need written rituals, documentation standards, explicit decision processes, and leadership modeling. The discipline is higher than sync requires. The payoff is proportional." -- Amir Salihefendic, founder of Doist, *Deep Work in a Distraction-Filled World* (2020) --- ## Decision Records: The Memory of the Organization The single most important artifact in an async-first operation is the decision record. Decisions that are made in real-time conversations and never written down produce a predictable failure pattern: six months later, someone asks why the decision was made, no one remembers the reasoning, the decision is relitigated, and often reversed for a reason that was already considered and rejected originally. The Architecture Decision Record (ADR) format, popularized in software engineering by Michael Nygard and others, provides a compact template that generalizes well beyond engineering: **Context**: What is the situation that requires a decision? What constraints apply? **Options considered**: What alternatives were evaluated? What were their trade-offs? **Decision**: What was chosen? **Consequences**: What changes as a result? What is now committed? **Status**: Accepted, superseded, under revision. A decision record is typically a single page. It takes 20 to 40 minutes to write after a decision is made. The return on that investment is substantial: the decision persists, the reasoning is accessible, and future discussions build on it rather than repeat it. The discipline is to write decision records for decisions that matter. Not every micro-choice needs one. Decisions with downstream implications, decisions that cost significant time or money, decisions that change commitments to other teams or customers, all warrant the artifact. A useful threshold: if you would reasonably expect someone to ask "why did we decide X?" within the next 12 months, write the decision record. For readers working on structured writing including technical decisions, business plans, and contractual terms, the writing rigor of decision records transfers to other domains. Our coverage at [pass4-sure.us](https://pass4-sure.us/) on structured analytical writing and [evolang.info](https://evolang.info/) on professional documentation both apply. --- ## Time Zones: The Hard Problem Distributed teams across time zones produce the hardest async coordination problems. A team split between San Francisco and Berlin has about 2 hours of overlap per day during normal working hours (San Francisco 9am-11am is Berlin 6pm-8pm). A team split between San Francisco and Singapore has essentially zero overlap during normal hours. Teams spanning 3 or more zones face still harder coordination. The patterns that work: **Time zone as constraint, not preference.** Hiring and team formation take time zones into account deliberately. A team whose work requires daily collaboration limits itself to a coverage window rather than pretending time zones do not matter. **Follow-the-sun handoffs.** Work that needs continuous attention (customer support, critical operations) is structured as handoffs between regions, with documented state transfers at each boundary. **Overlap windows for genuine sync needs.** Identify the 1 to 2 hour daily window where all relevant participants can be present, and reserve that window for meetings that genuinely need sync. Do not fill it with meetings that could be async. **Written-first protocols.** Every decision and discussion starts in writing. Sync meetings, when they happen, refine written proposals rather than generating ideas from scratch. This is particularly important for multi-zone teams where the zone with the fewest hours at the table would otherwise lose voice disproportionately. **Explicit response time norms.** In an async team, the expected response time for different kinds of communication needs to be explicit. 24 hours for standard messages, 48 to 72 for deeper work, immediate for genuinely urgent items through designated channels. Without norms, team members either feel always-on or never-sure-whats-urgent. | Channel | Expected Response Time | Content Type | |---|---|---| | Email | 24-48 hours | Formal or external communication | | Slack channels (async default) | 24 hours during working days | Team coordination, questions, updates | | Slack DMs | Same as channels (not faster) | Direct questions; prefer channels | | Issues/tickets | Per ticket SLA, typically 1-3 days | Work items, bugs, features | | Decision documents | 3-7 days for comments | Strategic or structural decisions | | Urgent channel | Immediate (with on-call rotation) | Production incidents, genuine emergencies | | Video/audio messages | Same as standard channels | Used for nuance not expressible in text | For readers managing scheduling across multiple time zones, the timestamp calculators at [file-converter-free.com](https://file-converter-free.com/timestamp-converter) are directly useful for finding overlap windows and coordinating handoffs. The third-place rituals and rhythms discussed at [downundercafe.com](https://downundercafe.com/) translate in modified form to distributed team contexts where physical third places do not exist. --- ## Tooling: Less Than You Think You Need Async-first work runs on a relatively small set of tools used well. The common failure is adding tools rather than using fewer tools deeply. The core toolset typically includes: **A handbook or wiki**. Single source of truth. GitLabs handbook uses Git; Notion, Confluence, or similar work. The tool matters less than the discipline of keeping it current. **A messaging platform with threaded channels**. Slack, Microsoft Teams, Zulip. Channels organized by topic, threads for discussions, permissive public-default, search that works. **A work tracking system**. GitHub issues, GitLab issues, Linear, Jira. Work items with status, assignees, comments, and linkage to implementation. **A document collaboration platform**. Google Docs, Notion, Confluence. Real-time collaborative editing for work-in-progress documents. **A video and audio recording tool**. Loom, Zoom recordings, simple screen capture. For async video messages that transfer nuance better than text. **A meeting and scheduling tool**. Calendar, scheduling assistants. Minimal use if async is actually working. The anti-pattern is tool sprawl: separate tools for messaging, project management, notes, documents, wiki, decisions, videos, each with partial adoption and conflicting information. The winning teams consolidate ruthlessly and use fewer tools more deeply. Equally important is the norms for each tool. Slack can be async (channels checked a few times a day) or sync (notifications constant, immediate response expected). Same tool, radically different impact on focus and work. Teams that decide explicitly how each tool is used, and enforce the norms, get async benefits from the tools. Teams that leave usage norms implicit tend to drift toward sync-default even in nominally async tools. > "The tools do not make you async. The discipline does. Giving a sync-default team Slack produces a sync-default team that uses Slack. The change is cultural, behavioral, and leader-modeled. Tools support it; they do not produce it." -- Matt Mullenweg, founder of Automattic, Distributed podcast (2019) --- ## Meetings: The Ones That Should Still Exist Async-first does not mean no meetings. It means meetings for the purposes that genuinely benefit from sync, run well. A meeting worth holding has several characteristics: **Clear purpose**. The meeting decides something, resolves something, explores something that genuinely requires real-time exchange. "Status update" is not a meeting purpose in an async-first team. **Pre-read distributed at least 24 hours in advance**. The context, proposal, or material to be discussed is written up and shared. Participants read before the meeting. The meeting itself starts with brief silent reading (often 5 to 10 minutes) if the pre-read has not been fully absorbed. **Decision-oriented agenda**. What specifically will be decided or produced by the end of this meeting? Amazon famously uses narrative memos and decision-focused meetings; Jeff Bezoss "two pizza" rule and memo-first meetings are adaptations of the same principle. **Minimum viable attendee list**. Only the people who need to be present for the decision. Broadcasting is done separately through written artifacts. **Documented output**. Meeting notes, including decisions, action items with owners and dates, and the reasoning for decisions. The document, not the conversation, is what persists. **Short duration**. 30 minutes is often enough for a well-prepared meeting with a clear purpose. 60 minutes should require explicit justification. 90+ minute meetings are usually either workshops (which have different structure) or sync-default patterns hiding in async clothing. The meta-rule is that if a meeting could have been an email, it should be. The async equivalent: if a meeting could have been a document with a comment period, it should be. Reserving sync for what sync is uniquely good at preserves the time and focus it costs. ## The Social Layer: Trust and Relationships at Distance The hardest thing about async-first distributed work is not the work. It is the social fabric. The casual coffee conversations, hallway interactions, and after-work beers that build trust in colocated teams do not happen automatically in distributed ones. Without deliberate intervention, distributed teams drift toward transactional relationships that function for immediate work but do not survive conflict, scale, or time. The patterns that work: **Deliberate virtual rituals.** Weekly team coffee (video call with no agenda), monthly games or social events, year-end retrospectives. These are manufactured social time that replaces the natural social time of office work. **In-person gatherings.** Once or twice a year, the distributed team meets in person for several days. The cost is high. The return, in trust, shared context, and relationship capital, is high enough that most successful distributed teams do it. GitLab, Automattic, and similar companies run significant annual offsites. **Personal context in work interactions.** Regular one-on-ones that include personal check-ins, not just work updates. Casual channels for non-work chat. Leaders who share personal context themselves to model that work relationships can have a personal dimension. **Acknowledging the isolation risk.** Remote work has documented mental health effects for some workers, particularly those who live alone or in challenging circumstances. Good distributed teams take this seriously, including benefits (mental health support, co-working stipends), norms (do not work 12-hour days alone), and cultural signals (rest is expected). For readers working on the broader context of distributed work and cognitive well-being, our coverage at [whats-your-iq.com](https://whats-your-iq.com/) on cognitive load and the burnout recovery piece in this same content family integrate directly. For cafe and third-place alternatives to office-centered life, [downundercafe.com](https://downundercafe.com/) provides useful context on working from varied environments. ## Where Async-First Fails The pattern does not work for every organization. Several conditions predict failure. **Organizations that refuse to invest in documentation.** Async-first requires written artifacts. Organizations that treat writing as overhead rather than as work cannot run async effectively. The documentation is the operating system of the distributed team. **Leaders who default to sync.** Culture flows from leadership behavior. Leaders who schedule sync meetings for everything, DM instead of posting in channels, and make decisions in hallway conversations signal that async is for individual contributors while real work happens in sync. The contradictory signal eats async practice alive. **Work that is genuinely tightly coupled in time.** Live trading, emergency medicine, live performance. Some work domains require sync coordination that cannot be substituted by async patterns. These domains accept the time-zone and scheduling constraints as part of the work. **Teams smaller than about 5 people.** At very small scales, the overhead of formal async infrastructure exceeds the benefit. Two or three people working closely can coordinate through informal sync without major cost. Async patterns become increasingly valuable as team size and distribution grow. **Cultural mismatches.** Some national cultures have strong norms around face-to-face communication as a signal of respect or seriousness. Async-first patterns in these contexts require deliberate adaptation and sometimes hybrid approaches. Erin Meyers research on cross-cultural communication in *The Culture Map* is directly relevant. The honest summary: async-first works well for knowledge work, creative work, and technical work in organizations willing to invest in the documentation and norms that support it. It works poorly in organizations that want the cost savings of distributed work without the structural changes required to make it function. The companies that do it well are not doing it because it is fashionable. They are doing it because they have concluded that the structural investment produces better outcomes than trying to replicate office sync patterns across distance. See also: [Burnout Recovery: A Step-by-Step Plan](/articles/work-skills/productivity-at-work/burnout-recovery-step-by-step-plan) | [Crucial Conversations Framework Explained](/articles/work-skills/communication-at-work/crucial-conversations-framework-explained) --- ## References 1. GitLab. (2024). *The GitLab Team Handbook: Remote Work Playbook*. https://about.gitlab.com/handbook/ 2. Mullenweg, M. (2020). "Five Levels of Autonomy in Distributed Work." Distributed Podcast transcripts. https://ma.tt/2020/04/five-levels-of-autonomy/ 3. Choudhury, P., Foroughi, C., & Larson, B. (2021). "Work-from-Anywhere: The Productivity Effects of Geographic Flexibility." *Strategic Management Journal*, 42(4), 655-683. https://doi.org/10.1002/smj.3251 4. Bloom, N., Liang, J., Roberts, J., & Ying, Z. J. (2015). "Does Working from Home Work? Evidence from a Chinese Experiment." *Quarterly Journal of Economics*, 130(1), 165-218. https://doi.org/10.1093/qje/qju032 5. Meyer, E. (2014). *The Culture Map: Breaking Through the Invisible Boundaries of Global Business*. PublicAffairs. 6. Newport, C. (2021). *A World Without Email: Reimagining Work in an Age of Communication Overload*. Portfolio. 7. Edmondson, A. C., & Harvey, J. F. (2018). "Cross-Boundary Teaming for Innovation: Integrating Research on Teams and Knowledge in Organizations." *Human Resource Management Review*, 28(4), 347-360. https://doi.org/10.1016/j.hrmr.2017.03.002 8. Salihefendic, A. (2020). *Doists Guide to Asynchronous Communication*. Doist Publications.

Frequently Asked Questions

What is asynchronous communication in simple terms?

Async communication is communication where participants do not need to be online at the same time. The sender writes or records when it suits them; the receiver reads or listens when it suits them. Email is the classic async channel. Written documentation, recorded video updates, and threaded discussions in tools like Slack or GitHub are modern async channels. Sync communication, by contrast, requires shared time: meetings, calls, real-time chat. Distributed teams across time zones depend heavily on async because sync options are limited by working-hour overlap.

Why does GitLab run almost entirely async?

GitLab operates with roughly 2000 team members across more than 65 countries with no central office. Their handbook explains async as a functional necessity rather than a preference: at that scale and distribution, requiring sync communication would either eliminate most possible working combinations or require people to work outside reasonable hours. GitLabs handbook and work patterns demonstrate that async-first can scale to large companies with complex product work, though it requires specific investments in documentation, decision-making processes, and cultural norms that most companies do not make.

When should a team use sync instead of async?

The general rule is sync for high-bandwidth creative exchange (brainstorming, relationship building, conflict resolution, onboarding of close collaborators) and async for status updates, decisions that can be documented, reviews, and information sharing. Cal Newport and others have argued that many meetings are sync by default when they could be async without loss; others (trust repair, nuanced debate, first-time creative work) genuinely benefit from real-time bandwidth. The question to ask is whether this conversation requires reading tone and silence in real time, or whether written exchange would serve equally well.

How do you run an effective async standup?

The async standup replaces the daily sync meeting with a written post in a shared channel. The standard format is three questions: what I shipped yesterday, what Im working on today, and what Im blocked on. The post is read by teammates during their working hours, who respond to blockers and comment where relevant. Research on meeting effectiveness suggests async standups save 30 to 60 minutes per person per day compared to sync daily standups while producing equal or better information flow. The failure mode is treating them as performance theater rather than coordination; the solution is brevity norms and leadership modeling.

What is a decision record and why do async teams need them?

A decision record is a written artifact that captures a decision, its context, the alternatives considered, and the reasoning for the chosen path. ADRs (Architecture Decision Records) in software engineering are the canonical form. For async teams, decision records solve the context transfer problem: new team members, team members in different time zones, and future-you in six months all need access to why decisions were made. The absence of decision records forces re-litigation of old decisions by people missing the original context, which is a major source of distributed team friction.

How do you handle urgent issues in an async-first culture?

Clear escalation channels and agreed urgency thresholds. GitLab and similar companies distinguish between async default channels (where response within 24 to 48 hours is expected) and explicit urgent channels (phone, designated on-call rotations, tagged urgent messages) for genuinely time-sensitive issues. The common failure mode is treating everything as urgent, which erodes the async discipline. The counter-failure is treating nothing as urgent, which delays real incidents. The right calibration is urgency thresholds that apply to less than 5 to 10 percent of communications.

Does async communication work for creative collaboration?

Partially. Writing, design iteration, code review, and strategic planning often work well async with written artifacts and threaded discussion. Early-stage brainstorming, rapid iteration under deadline, and complex negotiation often work better sync. The research on creative collaboration (Teresa Amabile and others) suggests creative work benefits from alternating modes: deep solo work, async review cycles, and occasional sync sessions for divergent exploration. Teams that do creative work exclusively sync often produce less rigorous output than teams that combine the modes deliberately.