Sync vs Async Decision Matrix

Thesis

The dominant conversation about distributed-team communication has a false binary: either your company is “async-first” (like 37signals or Doist) or it is “not really async” (like most hybrid teams). This binary obscures the actual question every distributed team needs to answer:

Which situations require real-time coordination, and which are better served by writing?

Answering this question explicitly — and then communicating the answer to your team — is more valuable than a stance on “async vs. sync” in the abstract.

Every strong remote company has answered it. Their answers differ in degree (Doist is more async-default than Buffer) but not in structure: they all have a mental model of when each mode is appropriate, and they have communicated that model to their team.

Most distributed companies have not answered it at all. The result: everyone makes independent judgment calls, which produces inconsistent norms, communication friction, and low-grade coordination anxiety that nobody can diagnose correctly.

Symptoms

Your team needs this framework if you recognize these patterns:

1. People apologize for “slow responses” when they have done nothing wrong. The implied norm is real-time; the actual norm is ambiguous. People are anxious about something that has never been defined.

2. The same conversation happens twice — first in a meeting, then written up later. Every meeting requires a written summary, every written summary requires questions that spawn another meeting. The coordination load is double.

3. Someone is always “in meetings all day” but nothing is getting decided. Real-time coordination is doing the work of decision-making that writing could handle more efficiently.

4. Employees in inconvenient time zones are perpetually catching up. The default is synchronous; async is the accommodation. The minority time zones bear the cost.

5. Important decisions are made in video calls with no written record. The decision was made; nobody knows why; the decision gets relitigated when the people in the call are no longer available.

6. The team uses “async” to mean “slower” rather than “different mode.” Async is treated as degraded synchronous, not as a different coordination model with its own strengths.

Root Causes

Undefined communication defaults produce anxiety. When the norm is not explicit, people default to the highest-pressure assumption: that messages require immediate responses, that important things should be raised in real-time, that silence means nobody is working. These assumptions produce meetings that should have been documents and urgency that should not exist.

Real-time communication has lower upfront cost, higher total cost. Scheduling a meeting is faster than writing a proposal. But the meeting requires everyone’s simultaneous presence, does not produce a searchable artifact, and does not scale across time zones. Writing has higher upfront cost and lower total cost. Companies that optimize for upfront convenience accumulate real-time communication debt. [Inference — practitioner argument; the cost asymmetry is consistent with what 37signals, GitLab, and Doist treat as worth investing in (structured async) but not measured cross-company.]

“Async” is not a single mode — it spans several distinct communication types. A daily check-in is not the same as a project proposal, which is not the same as a decision document, which is not the same as a Slack message. Treating all “async” as equivalent produces confused norms.

The right answer varies by situation, not by company ethos. A company that is “async-first” still has situations that need real-time coordination — crises, emotionally sensitive discussions, highly ambiguous creative problems. A company that is “not async-first” still has situations that should be handled in writing — detailed technical proposals, cross-timezone status updates, documentation of decisions. The matrix is about matching the mode to the situation.

What Companies Get Wrong

Declaring “we are async” without specifying what that means. Every company that announces an async-first transition without publishing specific norms generates ambiguity. The declaration is not the practice.

Using real-time for decisions and async for status. The highest-value use of async is decision-making — writing forces clarity, creates a record, allows considered responses. Using async for status updates (which most companies do) and real-time for decisions (which most companies also do) inverts the value equation. [Inference — load-bearing argument for the framework; supported by 37signals’s “important decisions start and end with an exchange of complete thoughts” framing but stated more sharply on this page than on any single primary source.]

Not building an escalation path from async. Buffer’s principle: complex + urgent → Zoom call. GitLab’s principle: three async exchanges on the same topic → video call. Every company with an async default needs an explicit path to real-time when async is not resolving the problem. Without this, situations that need real-time coordination fester in async channels, producing frustration and delayed resolution. (Sources, GitLab)

Treating all async tools as equivalent. Slack is not the same as a written proposal, which is not the same as a Basecamp message board post. Each tool has different persistence, different searchability, and different ambient notification pressure. Slack defaults to urgency; email defaults to response obligation; long-form writing platforms default to deliberation. Using Slack for decision-making gets the wrong defaults. [Inference — practitioner observation; consistent with Buffer’s three-way routing rule treating Slack and Threads as different defaults, but not a measured pattern.]

What Works Instead

The Decision Matrix

The following matrix reflects the consolidated practices of 37signals, GitLab, Doist, Buffer, and Zapier:

The Three-Way Communication Routing Framework (Buffer)

Buffer’s published framework is the most actionable single-team norm for mixed sync/async teams:

• 4 sentences or fewer, and/or urgent → Slack
• 5+ sentences, and/or not timely → Threads (or equivalent long-form async)
• Complex and urgent → Zoom or phone call

(Source)

The 37signals Default

• Async for everything that does not require simultaneity
• Synchronous (pings, video, screen-sharing) only when async is genuinely inefficient
• “Meetings are the last resort, not the first option”
• Required written mechanisms: daily check-in, weekly check-in, heartbeat, kickoff — these replace all routine status meetings

(Source)

The GitLab Threshold Rule

• Async by default
• When back-and-forth reaches three exchanges on the same topic → move to video call
• All video calls require a pre-written agenda (minimum 24 hours, ideally 72)
• All video call outcomes are documented and posted for the async record

(Source)

Company Evidence

37signals / Basecamp uses four mandatory async mechanisms plus an explicit no-Slack-internally rule. Real-time is for genuine exceptions: “there will be times when you do need to tightly collaborate with someone in real time, but those cases should be infrequent.” (Source)

GitLab builds the three-exchange threshold into their communication handbook. The threshold is a forcing function that prevents async debates from spiraling without producing a clear path to resolution. (Source)

Doist is the furthest async-default: meetings are replaced with async alternatives by default, and synchronous calls are used “only when async would genuinely be less efficient.” They have operated this way for 15+ years at ~90–100 people. (Source)

Buffer explicitly publishes why they are NOT async-first. Their documentation of the situations where synchronous is genuinely better is the most honest available account of the limits of async-default. Video calls help with relationship building, move faster for complex problems, and surface topics that written communication misses. (Source)

Automattic defines the expected behavior: “There’s no need to reply immediately, but make sure you check them at least a couple of times a day. Never miss a ping.” This defines an async response norm (not immediate) while setting a floor on responsiveness (twice daily). (Source)

Founder Actions

Step 1: Audit how your team currently communicates. For one week, note every communication event: meeting, Slack message, email, document. Categorize by type (status, decision, question, discussion). Note whether it was sync or async. This gives you the empirical baseline.

Step 2: Identify the mismatch. Which situations are currently synchronous that could be better handled async? (Usually: status updates, routine questions, documentation of known information.) Which situations are async that would benefit from real-time? (Usually: complex cross-functional decisions, conflict resolution, emotionally significant conversations.)

Step 3: Write your team’s communication routing guide. One page. Defines: what goes in which tool, what response time is expected in each tool, and what situations warrant escalation to real-time. Buffer’s three-way framework or GitLab’s three-exchange threshold are good starting points.

Step 4: Publish and enforce it. Post it in onboarding materials. Review it in the next team meeting. Revisit it at the six-month mark.

Step 5: Replace your most expensive recurring sync meeting with an async mechanism. Pick the meeting your team values least and replace it with a structured written check-in for one cycle. Evaluate after 6 weeks. This builds confidence and demonstrates the model.

Where This Framework Breaks

The matrix is a synthesis from the operating practices of five remote-first product-led software companies. Their evidence is well-documented; the framework’s transferability beyond that scope is not equally well-supported.

• In high-touch client services or sales-led organizations. Customer-facing roles (sales, customer success, account management) frequently require synchronous availability windows that the framework treats as exceptions. For an organization where >50% of the work is synchronous client coordination, the matrix is upside-down — the right framework is the inverse: when can we move things to async safely?
• For tightly coupled creative work in early discovery. The framework treats most decision-making as better-served-by-writing. For ambiguous creative work in the earliest phase (problem framing, design exploration, ideation under uncertainty) several of the cited companies make exceptions: 37signals shapes ideas in mixed-mode pairs, GitLab’s product discovery includes deliberate sync touchpoints, Buffer explicitly notes that “in live conversations, sometimes topics come up naturally that wouldn’t have otherwise.” Apply the matrix to resolved questions; not to questions still being formulated.
• In organizations with deep cultural async-aversion. The matrix assumes the team can adopt async norms once they are written down. Some teams have years of accumulated sync-default culture (status meetings as cultural ritual, decision-by-DM, casual presence as proxy for engagement) where simply publishing a routing guide will not change behavior. In those organizations, the framework is necessary but not sufficient — the cultural change is the bigger lift.
• When the founder runs the company synchronously. All five cited companies have founders who model async behavior. A founder who DMs decisions at 11pm and expects responses, schedules ad-hoc Zooms, and uses status meetings to feel control — that founder will undo the matrix faster than any team can implement it. Founder-behavior consistency is a precondition, not a side effect.
• As a static document. The matrix needs to be revisited as the company changes — new headcount, new time zones, new product surface, new tools. Companies that publish the routing guide once and never update it find that the rules go stale within 12–18 months as the work changes.

Do not apply this framework if: the company’s core work is synchronous client coordination; the founder operates synchronously and is not willing to model the new norms; or the team is in early discovery on a question that has not yet been formulated.

Sources

1. The 37signals Guide to Internal Communication: https://basecamp.com/guides/how-we-communicate
2. GitLab: How to Embrace Async Communication: https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous
3. Buffer is Remote but not Async-First: https://buffer.com/resources/remote-not-async-first/
4. How Doist Works Remote: https://doist.com/how-we-work/how-doist-works-remote
5. Expectations — Automattic: https://automattic.com/expectations/

Inferences

• The single most common communication problem in distributed teams is not too much async or too much sync — it is undefined defaults. When people do not know what is expected, they default to the behavior that feels safest: responding immediately (to avoid looking slow), using meetings (to avoid missing something), or using DMs (to avoid bothering the whole team). All of these defaults individually rational, collectively destructive. Defined norms replace individual anxiety with shared clarity.
• Buffer’s published explanation of why they are NOT async-first is more valuable than most async-first manifestos, because it defines the genuine failure modes of async. Companies that copy async frameworks without accounting for Buffer’s listed exceptions (complex + urgent, emotional situations, relationship building) will find the framework breaks at exactly those moments and conclude “async doesn’t work for us” — when what they actually discovered is that async has specific failure modes that need synchronous complements.
• The companies that have held their async-first stance the longest (37signals at 25+ years, Doist at 15+ years) have also built the most structured communication rituals. Their async-first stance is not low-overhead — it is high-overhead in a specific way: mandatory written check-ins, required heartbeats, required kickoffs. The discipline of structured async requires more explicit ritual than informal sync. This is counterintuitive but consistent across all evidence.

Work with Alex

If your team is defaulting to meetings because nobody has defined when writing is better, Alex helps leadership teams design the communication operating system that matches the work — not the path of least resistance.