2026-10-16
October 16, 2026
The document was never the point. The point is a decision that someone owns, by a date, in a form people can find later.
Most engineering organizations that adopt RFCs adopt the template and skip the contract. The template is easy to copy: context, goals and non-goals, alternatives, risks. The contract is harder: who decides, by when, and what happens to the thing afterward. Without it, the RFC becomes the most polite way to avoid a decision. A doc gets posted, fourteen people leave comments over three weeks, two threads turn into a debate that never resolves, and the project starts anyway on the strength of whoever was most persistent.
Gergely Orosz's survey of how companies use RFCs and design docs shows the practice is nearly universal among well-run engineering orgs, with Google, Uber, Spotify, HashiCorp, Monzo, Stedi and many others in the list. It also shows how much the formats differ. Some use heavyweight design docs. Stedi uses short decision records. Others use Architecture Decision Records. The common thread is not the template. It is that a plan gets written down and exposed to review before the work is expensive to change.
If you run programs, this is your territory whether or not anyone gave you the title. The RFC is an async ceremony: it replaces a meeting, and like any ceremony it needs an owner, a clock, and an output. Fridays in this newsletter are about running meetings and their async substitutes. Today's point is narrow: the RFC fails at exactly the places a TPM is trained to notice, and you can fix those without writing a single page yourself.
Start from what an RFC replaces. A synchronous design review gives you three things for free: a time box (the meeting ends), a forcing function (people must speak or stay silent), and a recorded outcome (someone says "so we're doing X"). Moving the conversation to a document deletes all three. Comments accumulate without end, silence is ambiguous, and nothing in the format says the conversation is over. That is not a flaw in written communication. It is a missing piece of process that the meeting used to supply.
Katrin Freihofner's LDX3 London talk for LeadDev, built on interviews with more than fifty tech professionals, describes the same pattern: RFC processes meant to speed up informed decisions turn into bureaucratic bottlenecks. Her proposed fixes are modest and operational: streamline the template, set clear timelines, use DACI to engage the right stakeholders, automate the feedback collection, and keep living documentation so teams stop relitigating old debates. Note the "cut decision time in half" line is the talk's stated aim, not a measured result, so treat it as a goal to test in your own org, not a benchmark.
Here is the failure analysis I would run on any stalled RFC, in order of how often each one is the real cause.
No named decider. The most common failure. "The team" does not approve things; a person does. The DACI model, which traces back to Intuit and is documented in the Atlassian Team Playbook, handles this cleanly: a Driver runs the process and writes the recommendation, a single Approver makes the call, Contributors supply input, and the Informed hear the result. The Driver is not necessarily the one who decides. If the RFC header does not name an Approver, the review is a discussion forum, not a decision process.
No deadline. An open-ended review period selects for the loudest reviewer and the longest thread. A fixed window, say five working days, with the decision date written on the first line, does two things. It tells reviewers when their input stops mattering, which increases the quality of what arrives early. And it gives the Approver legitimacy to decide on incomplete consensus, which is the only kind there is.
The wrong reviewers. Broadcasting to a whole engineering channel yields shallow comments from people with no stake and silence from the three people who will actually be broken by the change. A TPM can fix this with ten minutes of dependency mapping: name the teams whose on-call, API, or roadmap the change touches, and ask each directly. RAPID, from Paul Rogers and Marcia Blenko at Bain, is the heavier tool for cases where specific parties hold formal Agree rights. For most RFCs, DACI is enough.
Comments that smuggle in a different decision. Half of review friction is people arguing about a decision the RFC did not propose. The goals and non-goals section exists to head this off. Make the non-goals section earn its keep: if a reviewer wants a non-goal, that is a new RFC, not a comment.
No output. This is the failure that costs most, because it is invisible. Six months later nobody remembers why the team picked the queue over the stream, a new hire proposes the stream, and the debate restarts. An RFC is a long, narrative artifact optimized for persuasion during review. It is a poor record of what was decided. Michael Nygard saw this problem in 2011 and proposed a lightweight answer, the Architecture Decision Record: one or two pages, with a title, a status, the context, the decision stated in active voice ("We will..."), and the consequences, good and bad. His argument for brevity is the one worth stealing: large documents are never kept up to date, while small modular ones at least have a chance.
The structural insight is that an RFC and an ADR do different jobs. The RFC is the deliberation; it can be as long as the problem requires and it is allowed to rot afterward. The ADR is the verdict; it is short, numbered, immutable except through supersession, and it is the thing you link from the project plan. Teams that conflate the two end up either with RFCs nobody can mine for the answer or ADRs with no argument behind them. Run both, in sequence, and let the RFC end by producing the ADR.
What changes for the TPM? You stop being the person who chases comments and become the person who owns the ceremony's clock and its output. You do not need to have an opinion on the architecture. You need to know who the Approver is, when the window closes, who has not yet replied that should have, and where the verdict will live. That is program management applied to a document, and it is a high-leverage use of a role that is often asked to produce status instead.
A last warning, from Orosz's own account of the field: optional processes get skipped, and writing less is not automatically a model to copy. Incident.io, for example, does not mandate RFCs. That is a defensible choice for a small, fast team with high context. It is not a template for an organization where work spans teams and people join and leave. The more distributed your org, the more the written decision has to carry the weight that shared memory used to.
Try this week. Pick one RFC currently open in your org and add three lines to its header: the named Approver, the date the review window closes, and the link where the resulting ADR will live. Message the Approver to confirm. If you cannot name an Approver, that is your finding: escalate that one question, with a recommended name, before anyone leaves another comment.
What it is. A one-to-two-page record of a single significant decision, introduced by Michael Nygard in his November 2011 post "Documenting Architecture Decisions." Each record has a title, a status, a context, a decision, and consequences.
When to use it. At the moment an RFC or design review concludes, or any time a decision will outlive the people who made it: platform choices, vendor selections, data-model changes, API contracts, migration strategies.
How to run it:
When NOT to use it. For reversible, low-stakes choices that a normal pull request description already captures; a record nobody will ever look up is just overhead.
Link the ADR from the project plan and the on-call runbook, so the next reader finds it where they will already be looking.
How to master decision making (Katrin Freihofner, LeadDev) — A talk built on interviews with fifty-plus tech professionals about why decisions stall and how RFC bureaucracy slows them; worth reading for the template and timeline fixes, with the caveat that its headline time savings are a stated goal, not a measurement.
Companies using RFCs or design docs, and examples (Gergely Orosz) — A survey of how Google, Uber, Stedi, Spotify and others structure these documents; the useful part for leaders is how much the formats differ while the intent stays the same.
"Large documents are never kept up to date."
— Michael Nygard, "Documenting Architecture Decisions," 2011
Don't miss what's next. Subscribe to Critical Path: