Why Most RFCs Fail
I've read a lot of RFCs that were really just design documents with a comment box at the bottom. They present a solution, explain how it works, and ask for approval.
This misses the point. An RFC's primary value is not the document — it's the process of writing it.
The RFC as a Thinking Tool
Writing an RFC forces you to articulate:
- What problem are you actually solving? - What alternatives did you consider? - What are the failure modes of your chosen approach? - What are you explicitly not solving?
The act of writing these sections surfaces assumptions you didn't know you were making.
Structure That Works
The RFC structure I've settled on:
Problem Statement — One paragraph. If you can't explain the problem in one paragraph, you don't understand it well enough yet.
Constraints — What are the non-negotiables? Latency budget, cost ceiling, team expertise, timeline.
Options Considered — At least 3. Including the "do nothing" option. Each with honest pros and cons.
Proposed Solution — Your recommendation with rationale. Not just what, but why this over the alternatives.
Open Questions — What you don't know yet. This is where reviewers add the most value.
Rollout Plan — How you get from here to there without breaking things.
Getting Useful Feedback
The most common RFC failure mode is getting feedback like "looks good to me" from everyone. This means either the RFC is too vague to critique, or reviewers don't feel safe disagreeing.
I explicitly ask reviewers: "What would have to be true for this to be the wrong decision?" This reframes the review from approval-seeking to genuine stress-testing.
The Living Document Problem
RFCs should be updated as decisions change. A stale RFC is worse than no RFC — it misleads future engineers about why things are the way they are.
I add a "Decision Log" section at the bottom that tracks significant changes and the reasoning behind them.