RFCs and ADRs as Leadership Tools, Writing Is the Job

TL;DR — RFCs and ADRs aren’t bureaucracy, they’re leverage / writing forces the rigor the meeting was supposed to provide / a culture of written decisions is a culture of legible leadership.

The most expensive sentence in software engineering is “we discussed it in a meeting.” It’s expensive because three months later, when the decision comes back to haunt the team, no one can remember who agreed to what, why, or under what conditions. The context evaporated. The decision lives on as code, but the reasoning lives only in the heads of whoever was in the room.

RFCs and ADRs are the corrective. Both are written artifacts. RFCs (Request for Comments) capture proposals before a decision; ADRs (Architecture Decision Records) capture decisions after they’re made. Together they form the long-term memory of a technical organization, and as a tech lead they’re some of the highest-leverage tools you have.

This is the fifth post in my December leadership series — earlier ones covered discovery questionnaires and multidisciplinary team structure. This one gets concrete on templates and the culture you need around them.

Why Writing Beats Talking

The standard objection to written decision processes is “we’ll lose velocity.” I’ve heard it on every team I’ve introduced these to. It’s almost always wrong, and here’s why.

Verbal decisions feel fast in the moment because the cost is hidden. The cost shows up later, when:

• Someone joins the team six months in and asks “why did we choose Postgres over DynamoDB?” and nobody can give a coherent answer
• The constraint that drove the decision changes, but nobody notices because the constraint was never written down
• A second team makes a contradictory decision because they didn’t know the first one existed
• Two senior engineers each remember a slightly different version of what was agreed

A written RFC takes maybe four hours to draft and an additional two to three hours of comment and revision. The expected cost of those four scenarios above, summed over a year, is much higher than six hours. Writing isn’t slower. It’s just expensive in a visible, upfront way, which makes it feel slower.

There’s a deeper benefit too. Writing forces the rigor that meetings often skip. When you have to type out “the tradeoffs are X, Y, and Z, and we chose Y because of constraint C,” you discover the parts of the reasoning that don’t actually hold up. Meetings let bad reasoning hide in the rhythm of conversation. Documents don’t.

Will Larson has written well about this in Staff Engineer, and it’s also a recurring theme in Camille Fournier’s work — the written word as leadership multiplier. The senior engineers I respect most are, almost without exception, prolific writers.

RFC: The Proposal Document

An RFC is a proposal for a non-trivial change — an architecture, a new system, a significant refactor, a policy change. It exists to gather feedback before a decision is made.

Here’s the template I use:

# RFC: <Short Title>

- **Author:** <Name>
- **Reviewers:** <Names — be specific, not "everyone">
- **Status:** Draft / In Review / Accepted / Rejected / Withdrawn
- **Created:** <Date>
- **Decision deadline:** <Date — usually 1-2 weeks from created>

## Summary
2-3 sentences. If a reader stops here, what do they need to know?

## Context
What's true today? What problem are we solving? What constraints
apply? Include links to the discovery doc, prior RFCs, and any
metrics that frame the decision.

## Goals and Non-Goals
- Goals (what success looks like)
- Non-goals (what this RFC explicitly does NOT cover)

## Proposed Approach
The change being proposed, in enough detail that a competent
engineer could implement it. Diagrams help. Code sketches help.

## Alternatives Considered
At least 2-3 alternatives, with honest pros and cons.
A common failure mode is to list strawmen — alternatives no one
would seriously consider. Don't do that. Steelman the alternatives.

## Risks and Mitigations
What could go wrong? What's the rollback plan? What's the
operational cost?

## Rollout Plan
- Phase 1: <what, when, who>
- Phase 2: <what, when, who>
- Success metrics
- Rollback criteria

## Open Questions
Things you don't know yet, things you want reviewers to weigh in on.

## Decision
Filled in at the end of the review period.
- Decision:
- Decided by:
- Date:
- Summary of reasoning:

A few notes on what makes this work in practice.

Decision deadline matters. Without a deadline, RFCs go into a kind of permanent twilight where everyone has feedback but nobody owns the decision. A two-week window is usually right. Long enough for thoughtful review, short enough to force closure.

Named reviewers, not “the team.” “Please review” sent to a channel of forty people generates maybe one or two comments, mostly nitpicks. The same RFC sent to three specifically named reviewers generates serious engagement. Reviewers are accountable for actually reading and commenting. Use that asymmetry.

Alternatives matter more than the proposal. The proposal is what you walked in wanting to do. The alternatives are what disciplines your thinking. An RFC with weak alternatives is a press release pretending to be a proposal.

ADR: The Decision Record

An ADR is the residue an RFC leaves behind. It’s much shorter — typically half a page — and its job is to be readable in two minutes by someone joining the team a year later.

Michael Nygard’s original ADR template from 2011 is still the right shape:

# ADR-<NNN>: <Short Decision Title>

- **Status:** Proposed / Accepted / Deprecated / Superseded by ADR-<NNN>
- **Date:** <Date>
- **Deciders:** <Names>

## Context
The forces at play, the constraint or problem that drove the decision.
2-4 short paragraphs.

## Decision
The decision itself, stated clearly. One paragraph.

## Consequences
What becomes easier, what becomes harder, what we accept as a tradeoff.
Include operational, organizational, and technical consequences.

## Alternatives Considered
Brief — one line each is fine. Link to the RFC for detail.

ADRs live next to the code, in the repo, in a docs/adr/ directory, numbered sequentially. They are never edited after being marked Accepted — if the decision changes, you write a new ADR that supersedes the old one. The old one stays, marked Superseded, with a link forward. This append-only property is what makes ADRs useful as long-term memory.

A team that’s been writing ADRs for two years has a readable history of every significant architectural decision, why it was made, what the team knew at the time, and what’s changed since. That history is incredibly valuable when onboarding senior engineers, evaluating tech debt, or deciding whether to revisit a past call.

Making It Stick: The Cultural Moves

Templates aren’t the hard part. The hard part is the culture around using them. A team can adopt the templates and still not get the benefit, if the cultural moves don’t come along too.

Write the first ones yourself. Don’t ask the team to start writing RFCs without modeling what good looks like. Write two or three yourself first. Be explicit about what you’re doing and why. Let the team see the work.

Review in writing, not in meetings. The whole point is to capture the reasoning. If feedback only happens in a synchronous review meeting, half of it evaporates. Comment in the doc. Have the doc be the source of truth. Use meetings only to resolve genuinely sticky disagreements.

Lower the bar for what’s RFC-worthy. New teams often write RFCs only for the most important decisions, which makes RFCs feel intimidating. Make them lighter — a one-page RFC for a medium decision is fine. Lower the activation energy and you get more of them.

Celebrate the no-decision. Some RFCs end with “we considered this, decided not to do it, here’s why.” Those are valuable. They prevent the team from re-litigating the same idea every six months. Mark them as Rejected, archive them, and link to them next time someone proposes the same thing.

Tie RFCs to budgets, not preferences. “Any change affecting more than two services” or “any change requiring a new vendor” or “any change touching auth” — pick objective criteria for what requires an RFC. Subjective criteria (“important changes”) produce inconsistent adoption.

Common Pitfalls

RFCs as theater. The decision has already been made; the RFC is a formality. Reviewers can smell this and engagement collapses. If you’ve decided, just write the ADR. Don’t fake the open question.

Document graveyards. RFCs and ADRs that no one ever reads are net negative — they take time to write and provide no value. The fix is integration into the team’s regular work: linking RFCs in PRs, referencing ADRs in onboarding, surfacing recent ADRs in team meetings.

Over-templating. Every section is mandatory, every doc has to look identical, every RFC needs three approvers. The template should serve the team, not the other way around. Be willing to skip sections that don’t apply.

Confusing length with quality. A great RFC can be three pages. A bad one can be twelve. Length signals effort but not necessarily insight. Push for clarity, not volume.

Not linking to discovery. The best RFCs link back to discovery output — the problem statement, the user research, the metric that motivated the work. Without that link, the RFC floats free of business context and reads like a technical exercise.

Wrapping Up

Writing is the most underrated leadership move in software. It scales — one document can inform fifty engineers across two years. It compounds — each ADR makes the next decision easier, because the context is preserved. And it’s quietly disciplining — the act of writing forces the rigor that conversation often skips. If you do one thing in 2024, build an RFC and ADR habit on your team.

Next up I’ll get more specific on decision logs and async leadership — what to do when the team is distributed and you can’t rely on hallway conversations to keep context flowing.