How to Write RFCs That Actually Get Read
The RFC Nobody Read
You spent two weeks writing a 15-page RFC. You shared it in Slack. Three people reacted with 👍. Nobody left comments. You shipped the design. Six months later, the team discovered a fundamental flaw that would have been obvious if anyone had actually read the document.
The problem isn't your team. The problem is the format.
Why RFCs Fail
Too Long
If your RFC is more than 2 pages, most people won't read it. Engineers are busy. A 15-page document competes with code reviews, bug fixes, and actual building. The document loses.
Too Abstract
"We propose a microservices architecture leveraging event-driven patterns..." Nobody can evaluate this. It's architecture astronautics. People need concrete examples and specific tradeoffs.
No Clear Decision
The RFC describes a system but doesn't frame the decision. What are the options? What are the tradeoffs? What specifically do you need feedback on?
Wrong Audience
Sending a deep technical RFC to the entire engineering team means 80% of readers lack context and 20% who have context are buried in noise.
The One-Page RFC Format
# RFC: [Title]
**Author:** [Name] | **Date:** [Date] | **Status:** Draft
**Reviewers:** [2-4 specific people who should review]
**Decision needed by:** [Date]
## Context (3-5 sentences)
What problem are we solving? Why now? What's the business impact?
## Proposal (1 paragraph + diagram)
What are we building? Include ONE architecture diagram.
## Alternatives Considered
| Option | Pros | Cons | Effort |
|--------|------|------|--------|
| Option A (proposed) | ... | ... | 4 weeks |
| Option B | ... | ... | 6 weeks |
| Option C (do nothing) | ... | ... | 0 |
## Key Decisions
1. [Specific decision point] — Proposed: [choice]. Why: [reason]
2. [Specific decision point] — Proposed: [choice]. Why: [reason]
## Risks
- [Risk 1]: Mitigation: [plan]
- [Risk 2]: Mitigation: [plan]
## Open Questions
- [ ] [Specific question you need answered]
- [ ] [Specific question you need answered]That's it. One page. If you can't fit your proposal on one page, you either don't understand it well enough or you're trying to decide too many things at once.
The Review Process That Works
Step 1: Name Your Reviewers (2-4 People)
Don't share with "the team." Name 2-4 specific people whose feedback you need:
Reviewers:
- Sarah (owns the payment system this touches)
- Mike (built the original architecture)
- Alex (will implement this if approved)
- Jordan (security implications)
Why specific reviewers: Named reviewers feel responsible. "The team" feels like someone else's job.
Step 2: Set a Deadline
"Please review by Thursday EOD. If I don't hear objections
by then, I'll proceed with the proposal."
This is not aggressive — it's respectful of everyone's time.
Silence after the deadline = consent.
Step 3: Async First, Sync If Needed
Day 1: Share RFC with reviewers
Day 2-3: Reviewers leave written comments
Day 4: If there are unresolved disagreements,
schedule a 30-minute meeting with ONLY
the people who disagree
Day 5: Decision made, RFC updated with outcome
The meeting is the exception, not the rule. Most RFCs should be decided asynchronously. If you need a meeting for every RFC, your RFCs aren't clear enough.
Step 4: Record the Decision
## Decision (added [date])
**Approved:** Option A with modifications
**Key changes from original proposal:**
- Added rate limiting per Mike's feedback
- Deferred the caching layer to Phase 2 per Sarah's concern
**Dissent:** Alex preferred Option B but accepts the decision
**Implementation starts:** [date]Recording dissent is important. It shows the decision was considered, not rubber-stamped. And if the dissenter turns out to be right, the team can learn from it.
When to Write an RFC
Not everything needs an RFC. Use this decision tree:
Is this change reversible in < 1 day?
→ Yes: Just do it. No RFC needed.
→ No: Continue...
Does this affect more than one team?
→ Yes: Write an RFC.
→ No: Continue...
Is the effort > 2 weeks?
→ Yes: Write an RFC.
→ No: Continue...
Does this change a public API or data model?
→ Yes: Write an RFC.
→ No: Just do it. Maybe write a brief design doc.
Examples
| Change | RFC? | Why |
|---|---|---|
| Add a new API endpoint | No | Reversible, single team |
| Migrate to a new database | Yes | Irreversible, multi-week, affects everyone |
| Change authentication system | Yes | Affects all teams, security implications |
| Refactor internal module | No | Reversible, single team |
| Adopt a new framework | Yes | Multi-week, affects hiring and onboarding |
| Add a feature flag | No | Reversible in seconds |
| Change pricing model | Yes | Business impact, cross-team |
The RFC Culture
What Good Looks Like
- RFCs are short and focused
- Feedback is specific and actionable
- Decisions are made within a week
- Disagreements are resolved, not avoided
- Past RFCs are searchable and referenced
What Bad Looks Like
- RFCs are 15+ pages that nobody reads
- Feedback is "looks good" with no substance
- RFCs sit in review for weeks with no decision
- Meetings are scheduled for every RFC
- Past RFCs are lost in Slack threads
The Metrics
Track these quarterly:
| Metric | Healthy | Needs Work |
|---|---|---|
| Average RFC length | 1-2 pages | > 5 pages |
| Time to decision | < 5 days | > 2 weeks |
| Review participation | > 80% of named reviewers | < 50% |
| RFCs per quarter | 3-8 (for a team of 10) | 0 or > 20 |
Zero RFCs means decisions are being made without documentation. Twenty RFCs means the team is over-processing and under-building.
Start This Week
Pick the next technical decision your team needs to make. Write a one-page RFC using the format above. Name 2-3 reviewers. Set a 3-day deadline. See what happens.
The goal isn't perfect documentation. It's better decisions made faster with less meetings. One page, specific reviewers, clear deadline. That's it.