Async vs sync engineering decisions: how to choose
Not every decision should be async. A practical framework for choosing the right mode based on reversibility, stakes, urgency, and team size — and the failure modes of each.
Choose async vs sync based on four dimensions: reversibility, stakes, urgency, and team size. Sync for incident response, relational decisions, and small reversible calls. Async for architecture decisions, 5+ stakeholders, and cross-timezone work. Hybrid (async first, sync only for unresolved dissent) is often best.
Async-first culture is fashionable. So is the backlash against it. Both are too simple. The right answer is decision-by-decision: some calls are obviously sync, some are obviously async, and the interesting cases are the ones in the middle.
What are the four dimensions of a decision-mode choice?
Every engineering decision has four properties that determine its right mode: reversibility (Bezos's one-way vs two-way doors), stakes (revenue impact, eng-quarters of work), urgency (must decide today vs this quarter), and team size (3 engineers vs 30).
High reversibility, low stakes, low urgency, small team — sync is fine. The meeting cost is small and the social bandwidth is high.
Low reversibility, high stakes, low urgency, large team — async is correct. You want independent reasoning from everyone before converging.
Most decisions are mixed. That is where the framework helps.
When is sync the right mode?
Incident response. New information arriving in real-time, decisions need to be made in minutes not hours, the team needs to coordinate action immediately. Async is malpractice here.
Relational decisions. Performance reviews, difficult hiring calls, conflict resolution. The signal in someone's voice and face is part of the decision. Async strips it out.
Small reversible calls. Choosing a library for a one-engineer-week prototype. The cost of being wrong is days, the cost of an async process is hours. Just decide.
When is async the right mode?
Architecture decisions with multi-quarter cost. You will not improve on a 48-hour async process by adding a one-hour meeting.
Decisions with 5+ stakeholders. The marginal cost of one more person in a meeting is large; the marginal cost of one more contributor in an async room is near zero.
Decisions across timezones. Sync meetings here always tax the team in the worst timezone. Async removes the tax.
What is the async-then-sync hybrid pattern?
Many teams' best decisions run async-then-sync. The async phase gathers independent reasoning, the sync phase resolves remaining dissent.
Run the async phase first. Generate the synthesis. If consensus is high (8 of 10 engineers aligned with shared reasoning), the engineering manager calls it and there is no meeting. If dissent is structural (4 vs 6 with different framings), schedule a 30-minute sync with only the engineers whose positions diverged.
This is the pattern KFC is built for: cheap async first, expensive sync only when the synthesis shows you need it.
What are the common failure modes of each?
Async failure mode: the room is open for two weeks because no one set a deadline. Decisions decay. Engineers forget the context. Avoid by setting hard deadlines (48h is right for most calls).
Sync failure mode: the meeting is dominated by two voices and the seven others nod along. The decision is made but no one is bought in. Avoid by running async first when team size is more than 5.
Worst-of-both failure mode: a Slack thread that drifts for three days then gets resolved in an emergency meeting. This is the default mode of most engineering teams. Replace it with a deliberate choice.
Async vs sync is a tool choice, not an identity. Teams that use both deliberately ship better decisions than teams that pick one and apply it to everything.