RFC and ADR Culture: How Engineering Orgs Make Decisions in Writing — and Why It Scales
RFCs (Request for Comments) and ADRs (Architecture Decision Records) are the load-bearing rituals of decision-making in mature engineering orgs.
On this page▾
- RFCs (Request for Comments) propose a new direction. ADRs (Architecture Decision Records) record a decision already made.
- The point of writing is not the document — it is the thinking the writing forces.
- A working RFC culture has a clear lifecycle: draft → review → decision → archive. Without the archive step it becomes a graveyard.
- Time-box reviews. RFCs open longer than 2 weeks usually never close.
- ADRs are the single highest-ROI artefact a growing engineering org can adopt — they survive every reorg.
Past about 30 engineers, decisions made in meetings stop being remembered consistently, and 'we discussed this six months ago' becomes a daily phrase. Past 100 engineers, decisions made in chat threads disappear entirely. RFCs and ADRs — written, reviewed, archived decision artefacts — are how mature engineering orgs solve this. The IETF has used RFCs since 1969; Michael Nygard popularised the lightweight ADR format in 2011. The two formats serve different purposes and the strongest orgs use both.
What RFCs and ADRs are, and why
| Aspect | RFC | ADR |
|---|---|---|
| Purpose | Propose a new direction; gather input | Record a decision that has been made |
| Written when | Before the decision | When the decision is finalised |
| Length | 3–10 pages typical | 1 page typical |
| Audience | Anyone affected; usually a defined review group | Future engineers (and your future self) |
| Lifecycle | Draft → Review → Decision → Archive | Proposed → Accepted / Rejected / Superseded |
| Tone | Persuasive, exploratory | Declarative, terse |
Amazon's six-page memo culture (Jeff Bezos's 2018 shareholder letter) and Stripe's RFC system both rest on the same insight: writing forces a structure of thought that conversation does not. A document can be ignored or read at 2x; a 60-minute meeting cannot.
The RFC lifecycle
- 11. Draft (author owns; 1–2 weeks)Author writes the RFC. Quiet conversations with 2–3 trusted reviewers before opening it widely.
- 22. Review (open; 5–10 business days)Comments invited from a named review group. Author responds in writing. Discussion in the doc, not in chat, so the rationale is preserved.
- 33. Decision (named decision-maker; 1 meeting)A named individual or small group makes the call. The decision is captured in the doc, with the rationale. 'No decision' is a decision and must be named explicitly.
- 44. Archive (immediately)RFC is moved to an immutable archive with a clear status (Accepted, Rejected, Withdrawn). Linked from the relevant ADR if the decision is architectural.
An RFC that hasn't closed in two weeks almost never closes. Either the decision was already made and the RFC is theatre, or the decision is too large for one RFC. Force the issue at the two-week mark.
A reusable RFC template
- Title and one-line summary
- Status (Draft / In Review / Accepted / Rejected / Withdrawn)
- Authors and reviewers (named individuals, not 'the platform team')
- Context (what changed that we now need to decide this?)
- Goals (what 'good' looks like) and non-goals (what we explicitly aren't doing)
- Proposed approach (with diagrams where helpful)
- Alternatives considered (at least two, with honest pros/cons)
- Risks and open questions
- Decision (filled in at the end) and rationale
A reusable ADR template
Michael Nygard's original 2011 format, still the most-used:
- Title (e.g. 'ADR-0023: Use PostgreSQL for the new metadata service')
- Status (Proposed / Accepted / Deprecated / Superseded by ADR-XYZ)
- Context (the situation that forces a decision)
- Decision (the choice made, in the active voice — 'We will…')
- Consequences (what becomes easier, what becomes harder)
Store ADRs in the code repository, not in a wiki. They evolve with the code. Repositories like adr-tools (Nat Pryce) make this trivial.
When to use which
| Situation | Use |
|---|---|
| Choosing a new database for a service | RFC for the proposal, ADR for the resulting decision |
| Adopting a new third-party tool affecting multiple teams | RFC |
| Recording why we picked option A over B in last week's meeting | ADR (no RFC needed) |
| Internal team retrospective decision | Team-local doc; ADR if architectural |
| Crisis-mode incident decision | ADR after the fact; RFC is too slow |
Scaling the practice past 100 engineers
- Maintain a directory of all open RFCs visible to the whole org. Stale ones get attention.
- Designate review groups by scope: team-level, area-level, org-level. Use the largest group only when needed.
- Run a weekly RFC review meeting for org-level proposals. Most decisions still happen async; the meeting only handles deadlocks.
- Train new engineers on the format in onboarding. Provide examples — accepted, rejected, superseded.
- Track the meta-metric: median time from draft to decision. If it's growing past 3 weeks, the system is jamming.
Anti-patterns
- RFC required for everything — strangles small teams.
- Anonymous reviewers — destroys accountability; reviewers should be named.
- Decisions buried in long comment threads with no summary — defeats the purpose.
- ADRs written but never read — usually means the directory isn't linked from the code.
- Approval by silence — implicit approval gets re-litigated; force an explicit 'I approve' or 'I object'.
Implications for HR
- RFC authorship is high-leverage promotion evidence. Make it explicit in the rubric.
- An engineer who can write a strong RFC is doing Staff-level work regardless of title.
- ADR culture reduces onboarding ramp time measurably (Stripe and Shopify have published estimates). HR should care.
- RFC reviewing is a hidden labour load disproportionately falling on senior engineers and women in tech (see DEI article). Track and credit it.
Monday-morning checklist
- Adopt the Nygard ADR template this week. Store ADRs in the repo.
- Publish an RFC template and one worked example.
- Create a directory of open RFCs with status visible.
- Add 'recent RFC authorship' to your promotion rubric for Senior+ levels.
- Run one 15-minute team session on 'how to read and review an RFC'.
FAQ
Frequently asked questions
Aren't RFCs just bureaucracy?
Only if you require them for everything. Reserved for cross-team or architectural decisions, they save time over the meeting-cycle alternative.
Do we need both RFCs and ADRs?
Strictly no, but pragmatically yes. RFCs are heavy and infrequent; ADRs are light and continuous. They cover different gaps.
What about decisions made in 1:1s?
If they have org-level consequences, write the ADR. The 1:1 is private; the decision usually shouldn't be.
How long should an RFC be?
Long enough to make the case, short enough to be read end-to-end. Most successful RFCs are 4–8 pages.
References
Read next
All playbooksEngineering performance is not productivity, and productivity is not lines of code. A leader's guide to the three modern measurement frameworks — DORA for…
Matthew Skelton and Manuel Pais's Team Topologies — stream-aligned, platform, enabling, complicated-subsystem — is the most-cited org design model in modern…
GitHub Copilot, Cursor, and the broader AI coding tool wave are reshaping engineering productivity, hiring plans, and career ladders.