"A meeting is a failure mode of a document."

Async or sync? The decision rubric that prevents most useless meetings

Before scheduling any synchronous meeting, run the following five questions. They take 30 seconds and prevent the majority of unnecessary meetings:

If four or five of the five questions indicate async, go async. If three or more say sync, schedule a meeting but cap it at 30 minutes, require an agenda, and send a pre-read at least 24 hours in advance.

The honest list of scenarios where synchronous communication genuinely earns its cost:

• Crisis response and incident review. An active outage requires real-time coordination. During the incident, sync is the right call. After the incident, the retrospective can and should be largely async-first (written pre-doc, then a 30-minute discussion).
• Hiring debriefs. Tone, conviction, and the dynamic between panelists all matter in a hiring decision. Running a debrief in Slack produces lower-quality decisions and slower consensus.
• Architecture decisions with multiple hard-to-reverse choices. When a decision will constrain the system for years and reasonable engineers disagree, live discussion is the right tool. Pre-read the proposed architecture doc async; discuss and decide sync.
• Creative brainstorming from zero. Async is excellent for refining an idea already in flight. It is poor for the first 45 minutes of 'what should we even build here?' Live riff matters.
• Difficult personnel conversations. Performance conversations, team-change notifications, and conflict resolution belong in a conversation, not a Slack thread.
• First meeting with a new person or partner. Relationship capital is built in synchronous interaction. The first 15 minutes of any important new relationship should be live.

The canonical list for async treatment. If your team runs any of these as recurring meetings, you are paying a context-switching tax for no benefit:

• Status updates (write one, read once; a weekly written post replaces every status standup)
• Decisions the team is already pre-aligned on (if the decision is obvious, write it up, give 48 hours for objections, close it)
• Code review feedback (asynchronous, thread-based, already the standard)
• Design review feedback on non-critical changes (Loom walkthrough, async comments)
• Project retrospectives: written pre-doc, then 30 minutes of discussion - NOT 60 minutes of discussion from scratch
• Most cross-functional coordination (status doc shared across teams replaces the weekly alignment sync)
• Meeting summaries (always write, never read aloud in the following meeting)

The single most effective organisational tool for async decision-making is a short written doc circulated before any discussion. Amazon's six-page memo culture and GitLab's handbook-first communication policy are the most prominent examples. The template:

A team that uses this template consistently eliminates approximately 60% of standing coordination meetings within 90 days. The investment is writing quality: the template only works if the author genuinely thinks through the options before circulating, rather than using the meeting as the thinking-through process.

Async-first is a default, not an absolute. It breaks under three conditions:

Ambiguity at high speed. When the problem is genuinely unclear and the cost of a wrong interpretation is high, async creates lag that damages decisions. A Slack thread with 12 replies in 20 minutes is a symptom of a problem that would have resolved in a 5-minute call. Experienced async-first teams name the threshold explicitly: "if this thread has more than 8 replies in 20 minutes, call it."

Interpersonal tension. Conflict managed via Slack text loses tone, body language, and the social mechanisms that resolve disagreement naturally. A difficult conversation via text typically takes longer and produces more damage than the equivalent 15-minute call.

New relationships. The first weeks with a new colleague, manager, or client require more sync than the mature relationship will. Async scales once the relationship is established; it cannot bootstrap it.