How to run an async RFC process for distributed engineering teams
A complete playbook for running technical decisions asynchronously across timezones: framing the question, gathering independent input, synthesizing the call, and shipping the decision in 48 hours.
Run async RFCs in four steps: frame a binary question with a 48-hour deadline, gate contributions so engineers cannot see each other's input until they submit, synthesize into consensus/dissent/blind-spots/confidence, then decide and log. The gating step is the only one that defeats anchoring.
If your engineering team spans more than two timezones, every synchronous architecture meeting taxes someone's evening. The async RFC process exists to make that tax unnecessary — but most teams run it badly. This guide is the playbook we use at KFC.
Why do most async RFCs fail?
The default async RFC is a Google Doc with a comment thread. It fails for one reason: the first three comments anchor everyone else. Engineer A reads the doc, drops a sharp comment. Engineer B sees A's comment before forming her own opinion. By comment ten, the team has converged on whatever A said — not because it was right, but because it was first.
This is anchoring bias, documented since Tversky and Kahneman's 1974 paper. Every engineering team has seen it. The retrospective lament 'we should have heard from X earlier' is anchoring bias talking.
Async RFCs also fail on incompleteness. Free-text comments let engineers duck dimensions they would rather not engage with. Almost nobody volunteers the risks of their own preferred option. Almost nobody articulates the conditions under which they'd change their mind.
Step 1: How do you frame the question?
A good async decision question is binary or trinary. 'Should we migrate to services?' is binary. 'What database should we use?' is too open — split it. Async input does not converge on open-ended questions.
Include: the decision, the deadline, the rough cost of being wrong, and a link to context (existing RFC, prior thread, architecture doc). 100 to 300 words of context. Not more — engineers will not read it.
The deadline matters more than people think. 48 hours is the sweet spot for distributed teams: long enough for everyone to think, short enough that nobody postpones.
Step 2: How do you gate the contribution phase?
This is the core of an async RFC done right. Until an engineer submits their own position, they must not see anyone else's. This is the only mechanism that reliably defeats anchoring.
If you are doing this in a doc, it requires hard discipline (one document per engineer, no peeking). If you are doing it in a tool like KFC, the gating is automatic.
Each contribution should have three fields: position (for, against, conditional), reasoning (why), risks (what could go wrong if your position wins).
Step 3: What is synthesis (not summary)?
After contributions are in, do not write a summary. Write a synthesis. The difference: a summary lists what was said. A synthesis maps where the team agrees, where it disagrees, and what nobody addressed.
The four blocks of a good synthesis: (1) Consensus — what most engineers agreed on with reasoning. (2) Dissent — where engineers split and why each camp held their position. (3) Blind spots — risks, costs, or considerations that came up in less than 20% of contributions and may have been under-weighted. (4) Confidence — how settled this decision feels, on a scale.
Claude is good at this. So is a careful engineering manager with an hour. The point is the structure, not the author.
Step 4: How do you close and document the decision?
The synthesis is not the decision. The decision-maker (usually the engineering manager or tech lead) reads the synthesis and calls the shot.
Document the decision in your ADR or RFC database with three things: the call made, the rationale, and the synthesis link. Future you needs all three.
Close the room. The decision is final until someone surfaces new information that justifies re-opening it.
When are async RFCs the wrong choice?
Async is not always right. Use sync when: there is genuine new information arriving in real-time (e.g. incident response), when the relational stakes are high (e.g. a difficult hiring call), or when the decision is small and reversible (a one-hour meeting is cheaper than a 48-hour process).
Use async for everything else. That is the majority of engineering decisions.
Async RFCs done right are not slower than meetings. They are faster, because the synthesis arrives with structure already in it. The only thing they cost is the discipline to gate contributions. That cost is what KFC removes.