The RFC Process That Gets Read

We socialize the architecture in a thread. We align in standup. We open the RFC two days later and ask for "async feedback." We collect three thumbs-up, call it consensus, and file the doc under Process.

That's not an RFC process.

That's ratification with nicer fonts.

I've watched this movie on three teams that swore they had a "strong RFC culture." The folder was full. The decisions weren't. The docs showed up when the only remaining work was formatting the inevitable.

The IETF named these things for a reason — a Request for Comments starts as a draft shared for discussion, not as a trophy after the hallway already closed. Company RFCs borrow the name. Most of them skip the request.

Proposal, Not Record

An RFC is a decision instrument while the choice is still open. An ADR is a record of a decision taken.

The names do the work if you let them. Request for comments means you still want pushback. Architecture decision record means you already decided and you're writing it down for the next engineer.

Confuse the two and you get the costume everyone recognizes: a twelve-section "RFC" that arrives after Kafka was already chosen in standup. The stamp says Approved. The decision was never on the page.

A late RFC is a ratification memo. Call it that, or don't write it.

Use the RFC when you need buy-in and alternatives still matter. Use an ADR when the team decided — in a room, on a spike, under incident pressure — and you need institutional memory without pretending the conversation is still open.

Stedi's split is useful here: heavier RFCs for broad, hard-to-reverse proposals; lighter decision records when you're codifying something already made. Pick the instrument that matches the decision state. Template shopping can wait.

The Pre-Decision Window

Before you open a doc, name the decision state.

Open — options are still live; a strong objection can change the recommendation. Leaning — there's a favorite, but you're still willing to lose. Closed — the hallway, the spike, or the incident already picked a winner.

Only the first two deserve an RFC.

Closed deserves an ADR — or a short decision note — and zero theater.

Here's the three-part horror story I keep seeing.

The hallway. Two leads agree after standup: "Just use Kafka for the order events. We'll clean up the outbox later." Nobody writes the options. Nobody names the cost of another broker in the fleet.

The doc. Someone opens RFC-014: "Messaging options for Order Service." Motivation takes a page. The proposal section restates Kafka. Alternatives get two polite bullets that read like they were written under protest. Review window: one week.

The stamp. Three LGTMs. One comment about partition keys. Status flips to Accepted. Six months later a new senior asks why not SNS+SQS and gets pointed at RFC-014 — which never evaluated that path while minds were open.

It's not that Kafka was wrong.

It's that the RFC never got a chance to be right about anything else.

Design docs earn their keep in the cheap-change moment — surface issues before code freezes the shape. Write the doc after the shape is socially frozen and you skipped the only moment the process was for.

And if the solution isn't ambiguous — if there's one obvious path and no real trade-off — skip the RFC. An implementation manual dressed as a proposal is overhead without the upside. Write the code, or write the ADR. Don't launder a closed choice through Collecting Feedback.

One more failure mode: the "pre-RFC" that never becomes an RFC. Someone drops a Notion page titled Thinking Out Loud, collects private DMs, then ships. When the design breaks, there's no public trail of options or dissent — only folklore. If the conversation can change the architecture, put it on a dated RFC with a status. If it can't, stop calling it consensus.

Page-One Load

Busy reviewers decide in the first screen whether this is a decision packet or a novel.

Put the load-bearing pieces above the fold:

• Decision state — open / leaning / closed (and if closed, stop and write an ADR).
• Context — three to five sentences. Why now. What breaks if we do nothing.
• Options — at least two real alternatives plus "do nothing," each with a cost and a risk.

If page one can't name options, you're not proposing — you're narrating.

• Recommendation — your bet, in one paragraph.
• Falsifiers — what evidence would make you change your mind.
• Named reviewers + deadline — not "the team," two to four people who own a stake.
• Decision owner — one human who will Accept, Reject, or Send Back when the window closes. A doc with four "approvers" and no owner is how LGTMs accumulate without a call.

RFCs that are thin on motivation, blind to impact, or dishonest about drawbacks and alternatives get a cold reception for a reason. Page one is where you prove you're not that author.

Same proposal, two first screens.

Bad page one. Two paragraphs of history about the Order Service. A diagram from last quarter's all-hands. "We propose a modern event-driven approach." No options. No decision date. Reviewers arrive already tired.

Good page one. Status: Open. Decision needed by Friday. Options: (A) Kafka topic + outbox, (B) SNS/SQS fan-out, (C) keep synchronous HTTP and accept coupling. Recommendation: A, because we already operate Kafka for billing events and the ops cost is paid. Falsifier: if SRE says another consumer class blows the broker SLO, prefer B. Reviewers: Maya (payments), Jon (SRE), Priya (orders).

The second one gets comments.

The first one gets emoji.

Shorter RFCs with named options invite real pushback. Maximal templates train skimmers.

Depth still belongs in the doc — APIs, rollout, failure modes — but below the fold or linked. Nobody reads large documents — that line was about ADRs, and it applies to proposals too.

Put the decision first and push schematics later — same inverted-pyramid habit that keeps short decision records readable. A bounded problem can live in a few pages; a novel nobody finishes helps nobody. Completeness is not a word count.

Review Without Comment Theater

An RFC without a review process is a blog post in your docs folder.

Name reviewers. Set a deadline. Prefer async comments. Escalate to a short sync only for unresolved disagreement — not to re-read the doc out loud.

Ask for the strongest objection, not for vibes. "Looks good" is not a review. Neither is a thread of twenty nitpicks about heading levels while nobody engages Option B.

Activity is not deliberation.

A loud thread can still leave every alternative untouched.

A useful review comment names a failure mode, a missing option, or a falsifier you skipped. "Have we priced the on-call load of another consumer class?" beats "curious what others think." If your reviewers only leave tone notes, your page one didn't give them a decision to attack.

Record the outcome in the doc: approved with modifications, rejected, or withdrawn — plus who dissented and why. Accepted should mean the major stakeholders agreed the design is worth trying — not that emoji arrived and the author got tired of waiting.

You might want to broadcast every RFC to #engineering for "transparency." That's how you bury the people who can actually change the decision under noise from people who can't. Transparency is a searchable archive and a clear status. It is not tagging eighty people so nobody owns the reply.

Time-box the window. A week is plenty for most service-boundary decisions; two weeks is a smell that nobody owns the call. When the deadline hits, decide — accept, revise, or kill. Endless Collecting Feedback is how teams pretend they're deliberating while the hallway decides again in parallel.

If Slack already decided, say so. Write the ADR. Link the thread. Don't open Collecting Feedback on a closed mind and call the silence consensus.

What Gets Read

We keep mistaking archive hygiene for deliberation.

The process that gets read is boring on purpose — open while options are alive, heavy on page one, light on ceremony, owned by named reviewers, honest when the decision already happened elsewhere.

Write the request while comments can still change the answer. Or admit you're filing the record — and file the record.