How to write an RFC that actually gets read (with template)
A practical guide to writing engineering RFCs - what to include, what to cut, how to route them for review, and a copy-paste template your team can adopt today.
Feb 20, 2026 · 4 min read · Kash Gohil
An RFC (Request for Comments) is a short written proposal that gives your team a chance to improve a decision before it's implemented. Most RFCs fail at exactly that: they get skimmed, rubber-stamped, or ignored. This guide covers how to write one that actually gets read - and includes a template you can copy today.
What is an RFC, really?
An RFC is a decision-making document, not documentation. You write it before the work, when the decision is still cheap to change, and it asks reviewers one clear question: "here's what I propose and why - what am I missing?"
That framing matters because it defines what belongs in the document. Anything that helps a reviewer evaluate the decision stays. Anything that merely proves you did homework goes.
Why do most RFCs go unread?
Four failure modes account for almost all of it:
They're too long. Reviewers budget ten minutes. A 4,000-word document doesn't get more scrutiny than a 1,000-word one - it gets less, because people skim past the parts that needed attention.
They bury the ask. If a reviewer can't tell what decision is being requested and by when, they'll leave a comment about naming and move on.
They have no deadline. "Comments welcome" means "this can wait forever." Every RFC needs an explicit decision date.
They're write-only. The RFC gets approved, the work happens, and the two never meet again. Six months later the document describes a system that doesn't exist, and the next author learns RFCs aren't worth reading.
The template below is designed against all four.
The template
Copy this into your docs tool of choice. Every section has a one-line purpose; if a section doesn't apply, delete it rather than padding it.
# RFC: <short, specific title>
- **Status:** Draft | In review | Approved | Rejected | Superseded
- **Owner:** <one person, not a team>
- **Reviewers:** <the 2-5 people whose objections matter>
- **Decision by:** <a real date>
## Problem
What hurts today, who it hurts, and why now. 2-3 paragraphs max.
If you can include a number (latency, cost, support tickets), do.
## Proposal
What you want to do. Concrete enough that two engineers reading it
would build roughly the same thing. Diagrams welcome, prose required.
## What we're not doing
Scope you're explicitly cutting. This is the section that prevents
the review from sprawling.
## Alternatives considered
The 1-2 serious contenders and the sentence explaining why not.
Not a survey - a defense against "did you consider X?"
## Risks and open questions
What could make this wrong, and what you genuinely don't know yet.
An RFC with no open questions reads as a decision already made.
## Rollout
How it ships: behind a flag, migration steps, what we watch, how we
roll back. One paragraph is usually enough.How do you get people to actually read it?
Name reviewers individually. "Team, please review" diffuses responsibility to zero people. Two to five named reviewers, chosen because their objection would change the plan, each explicitly asked.
Set the decision date in the request. "I'd like to decide by Friday - if I don't hear objections by then, I'm proceeding as written" is not rude; it's respectful of everyone's time. Silence becomes consent with a timestamp.
Keep the discussion anchored to the text. Comments that live in the document, next to the sentence they're about, stay resolvable. Discussion that scatters across chat threads produces decisions nobody can find later. (This is much easier when docs and chat share a workspace - link the thread to the doc and back.)
Record the decision in the document. When it's approved, mark it. When it's rejected, say why. The status line is what makes a pile of RFCs a usable archive instead of a graveyard.
What happens after approval?
This is where most processes leak. The RFC says one thing, the issue tracker says another, and the code does a third. The fix is mechanical, not cultural: the approved spec should become the work items, not inspire them.
In Rezee, that's built in - an approved RFC in Ideate & Design converts to issues in Plan & Track in one step, each issue back-references the section it came from, and live status flows into the document as branches merge in Code & Ship. The RFC stays true because it's connected to the work, not a snapshot of intentions. If you're on a different stack, you can approximate this with disciplined linking - it just won't maintain itself.
FAQ
What does RFC stand for?
Request for Comments. The name comes from the documents that defined the early internet, where proposals were circulated for feedback before becoming standards. Engineering teams borrowed the term for internal design proposals.
How long should an RFC be?
Aim for 800-1,500 words - about a ten-minute read. If the problem genuinely needs more, split the document: one RFC for the decision at hand, linked appendices for the deep detail.
What's the difference between an RFC and a design doc?
Usage varies by team, but a useful distinction: an RFC requests a decision (should we do this?), while a design doc records how something is built. An approved RFC often evolves into or links to a design doc.
When should you skip the RFC?
When the decision is cheap to reverse, affects only you, or would cost more to document than to redo. RFCs earn their cost on one-way doors: schema changes, public APIs, new services, anything with a migration.