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.

The companies cited here publish different norms for choosing a communication mode. Todoist combines async project work with recurring support meetings; Buffer has explained why some work benefits from live discussion. These are company examples, not a ranking of every remote organization. (Todoist accountability, Buffer)

[Inference — diagnostic hypothesis.] Unclear expectations can leave people guessing whether a message is urgent and whether a meeting is necessary. Inspect those expectations locally; the cases do not establish how common this problem is across all distributed companies.

Symptoms

[Inference — diagnostic examples.] Inspect communication norms 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

[Inference — practitioner hypotheses unless a source is given; these are not measured prevalence claims.]

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

[Inference — implementation cautions unless a specific company practice is cited.]

Declaring “we are async” without specifying what that means. An async-first declaration can leave expectations ambiguous unless it defines the norms people should follow.

Using writing only for status. [Inference — application guidance.] Written proposals can also support decisions by preserving context and allowing considered responses. Decide when live discussion adds value; the company examples do not establish which mode most companies use or a universally highest-value use of async.

Treating sync only as a last resort. Buffer’s 2023 account routes complex urgent discussion to Zoom or phone. GitLab describes both deliberate synchronous starts and escalation after three exchanges on a topic. [Inference.] Publish both kinds of guidance: when to begin live and when to switch. (Buffer, 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

[Inference — practical synthesis from the company examples, not a universal optimum or a verbatim policy shared by all five companies.]

Situation	Best Mode	Why
Status updates (daily, weekly)	Async — written	Does not require simultaneity; benefits from being readable later
Technical proposals	Async — written	Benefits from considered responses; needs permanence
Important decisions	Async — written first, then sync if needed	Writing forces clarity; record is essential
Crisis response	Sync — immediately	Speed and coordination require real-time
Complex, multi-party coordination	Written preparation + deliberate sync when useful	Start live for difficult context or strategy; also switch when written exchanges stall
Sensitive personnel matters	Sync	Emotional attunement requires real-time
Cross-timezone routine work	Async	Design for the minority timezone, not the majority
Brainstorming (ambiguous creative problems)	Sync or structured async	Depends on problem; real-time has advantages for ambiguous creativity
Onboarding new team members	Structured async + sync touchpoints	Self-driven with human checkpoints
Long-form project planning	Async — written	Benefits from being readable, commentable, and persistent
Short urgent questions	Sync or async with fast SLA	Slack works if norms are clear
Conflict resolution	Sync	Emotional intelligence and real-time feedback required

The Three-Way Communication Routing Framework (Buffer)

Buffer’s 2023 account provides a concrete historical routing example. The named Threads tool is not verified as part of its current stack:

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
“there will be times when you do need to tightly collaborate with someone in real time, but those cases should be infrequent”
Required written mechanisms: daily check-in, weekly check-in, heartbeat, kickoff — these replace all routine status meetings

(Source)

GitLab: Deliberate Sync and an Escalation Guideline

Async is the starting point for routine communication.
Strategy, disagreements, trust-building and difficult context can merit starting synchronously.
Three exchanges on the same topic are a guideline for recognizing when to switch to a call.
Preserve written context and outcomes so people outside the call can participate in the work.

(Current communication guidance)

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 documents both deliberate synchronous starts and the three-exchange escalation guideline. This is broader than a rule that calls are permitted only after async fails. (Source)

Todoist (formerly Doist) currently lists 108 people in 38 countries and publishes a public handbook. Its September 2022 accountability system includes regular manager 1:1s; current onboarding includes weekly mentor and team-head meetings. Async project work coexists with planned human support. (About, accountability, onboarding)

Buffer explained in 2023 why it did not use async for every situation. It describes relationship-building, complex discussion and topics that emerge in conversation as reasons to meet. The article is a dated operating account; its named tools should not automatically be treated as current. (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

[Inference — implementation guidance; suggested review periods are experiments, not measured optimal intervals.]

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

[Inference — transfer limits and implementation cautions, not measured failure rates or thresholds.]

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 and GitLab’s product discovery includes deliberate sync touchpoints [Inference — characterizations consistent with their published practices, not directly cited claims], and Buffer explicitly notes that “in live conversations, sometimes topics come up naturally that wouldn’t have otherwise” (Source). 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. Leadership behavior affects whether published norms are credible. A leader 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. [Inference.] Revisit the routing guide when the work, tools, time zones or team change. The cited cases do not establish a universal 12–18-month expiry period.

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

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

GitLab current communication: https://handbook.gitlab.com/handbook/communication/

Todoist About: https://www.todoist.com/about-us

Doist September 2022 accountability: https://async.twist.com/accountability-remote-workers/

Todoist onboarding: https://handbook.todoist.net/s/6ca6f66e-2d02-4e05-b629-b1c772f5ff23

Inferences

Explicit communication defaults may reduce uncertainty about urgency and response expectations. The cases support the practice, not a claim that undefined defaults are the single most common remote-work problem.
Buffer’s historical routing and GitLab’s current synchronous-start guidance support choosing a mode for the situation rather than treating async as an absolute rule.
Written coordination requires maintenance and participation. Todoist’s regular meetings and public handbook show that structured async can coexist with live support and durable documentation.

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.