Writing Technical RFCs That Get Approved

The best technical decision I ever made wasn't a technology choice. It was writing a three-page RFC (Request for Comments) before starting a project that would have taken two months. The RFC process surfaced a fundamental flaw in the architecture within a week. We pivoted to a better design before writing a single line of code. Two months of work, saved by three pages of structured thinking.

RFCs are the unsung hero of engineering culture. While code reviews catch bugs, RFCs catch wrong directions. They force you to think through problems before committing to solutions. They create a written record of why decisions were made. They democratize technical decision-making by giving everyone a voice before code is written.

Yet most engineers struggle with RFCs. They write too much or too little. They focus on the solution without explaining the problem. They treat the process as bureaucracy rather than a thinking tool. According to a 2024 InfoQ survey of engineering practices, 67% of companies with more than 50 engineers have an RFC process, but only 34% of those engineers report it as "effective."

This guide shows you how to write RFCs that are clear, compelling, and actually get approved. It covers structure, common mistakes, the review process, and real patterns from companies that do this well.

When to Write an RFC (And When Not To)

Write an RFC When:

• The change affects multiple teams or services. If your change touches code owned by other teams, those teams need to understand and agree to the approach.
• The change is hard to reverse. Database schema changes, API contract changes, infrastructure migrations — anything that creates long-term commitments.
• There's significant ambiguity. If reasonable engineers would disagree on the approach, an RFC surfaces that disagreement before code is written.
• The effort exceeds 2 engineer-weeks. Large projects deserve upfront alignment to avoid expensive pivots later.
• You're introducing new technology. New frameworks, languages, services, or infrastructure components affect the whole team.

Don't Write an RFC When:

• The change is small and well-understood. Bug fixes, minor features, refactoring within a single module.
• There's an established pattern. If you're building the 10th CRUD endpoint using the same patterns as the other 9, just do it.
• Speed is critical and the risk is low. Sometimes you need to ship fast. If the worst case is easily reversible, skip the RFC.
• You're prototyping. Prototypes are meant to be thrown away. Write the RFC when you're ready to build the real thing.

The RFC Template

After reading hundreds of RFCs at various companies, here's the structure that works best. Every section serves a purpose; don't skip any of them.

1. Title and Metadata

Keep the title descriptive and specific. Not "Database Improvements" but "Migrate User Sessions from PostgreSQL to Redis." Include: author(s), date, status (Draft/In Review/Approved/Rejected/Superseded), and reviewers.

2. Summary (3-5 sentences)

If a VP reads only this section, they should understand what you're proposing and why. This is not a technical summary; it's a business-context summary.

3. Motivation / Problem Statement

Why are we doing this? What problem are we solving? What happens if we don't solve it? This is the most important section. If the problem isn't compelling, no solution will be approved.

Include data. "The API is slow" is not a problem statement. "P99 latency for the /checkout endpoint has increased from 200ms to 1,400ms over the past 3 months, correlating with a 12% drop in conversion rate" is a problem statement.

4. Proposed Solution

Your recommended approach. Be specific enough that another engineer could implement it without further clarification, but don't write code. Diagrams are extremely valuable here.

5. Alternatives Considered

What other approaches did you consider? Why did you reject them? This section builds credibility. It shows you've thought broadly, not just latched onto the first idea.

Always include "Do Nothing" as an alternative. It forces you to articulate why action is necessary.

6. Technical Design

The detailed technical approach. Data models, API contracts, system diagrams, migration steps. This is where you go deep.

7. Risks and Mitigations

What could go wrong? How will you handle it? Be honest here. Reviewers respect transparency more than false confidence. According to Google's SRE book, the best design documents explicitly acknowledge what the author doesn't know.

8. Rollout Plan

How will you deploy this? All at once? In phases? Behind a feature flag? What's the rollback plan? Include a timeline.

9. Success Metrics

How will you know if this was successful? Define specific, measurable criteria. "The API will be faster" is not a success metric. "P99 latency for /checkout will be below 300ms within 2 weeks of rollout" is.

10. Open Questions

Things you haven't figured out yet. This invites collaboration and prevents reviewers from feeling like the decision is already made.

Common Mistakes (And How to Fix Them)

Mistake 1: Solution Before Problem

The RFC opens with "We should use Kafka." No context, no problem statement, just a technology choice. The reader immediately asks "why?" and the author has lost them.

Fix: Write the Motivation section first. Don't mention any solution until the reader understands and agrees that the problem is worth solving.

Mistake 2: Too Long

A 20-page RFC will not be read carefully. Most reviewers will skim it, miss important details, and approve it without understanding it. Amazon famously limits narratives to 6 pages. Your RFC doesn't need to be that short, but 3-8 pages is the sweet spot.

Fix: Move implementation details to appendices. The main body should convey the what and why. The how goes in appendices that interested readers can dig into.

Mistake 3: Only One Option

If you present only one option, the RFC feels like a fait accompli, not a discussion. Even if you're confident in your approach, present alternatives to show you've explored the space.

Fix: Always present at least 3 alternatives (including "do nothing"). Genuinely consider each one.

Mistake 4: No Success Metrics

Without success metrics, you can never close the loop. Did the project succeed? Nobody knows, because success was never defined.

Fix: Define 2-3 specific, measurable metrics. Set a date to evaluate them.

Mistake 5: Treating Comments as Attacks

An RFC with no comments is an RFC nobody read. Comments are a gift, they mean people care enough to engage. Responding defensively to comments poisons the RFC culture.

Fix: Thank every commenter. Address every comment, even if the answer is "Good point, but I've decided to keep the current approach because X."

The Review Process

Who Should Review

Timeline

Set a review deadline. Without one, RFCs languish in perpetual "In Review." A good default:

• Small RFCs: 3 business days for review
• Medium RFCs: 5 business days
• Large/cross-team RFCs: 10 business days

If no blocking comments are raised by the deadline, the RFC is approved by default (lazy consensus). This prevents a single absent reviewer from blocking progress.

How Top Companies Do RFCs

Tools for Managing RFCs

My recommendation: Google Docs for writing, GitHub for archiving. Write the RFC in Google Docs (better for real-time collaboration and inline comments). Once approved, convert to Markdown and store in a /rfcs directory in your repository. This gives you the best of both worlds: easy writing and permanent, searchable records.

My Opinionated Take

1. RFCs are thinking tools, not approval gates. The value of an RFC is not the approval at the end. It's the thinking that happens during the writing. If writing the RFC doesn't change your understanding of the problem, you probably didn't write it honestly.

2. Short RFCs get better feedback. A 3-page RFC with clear sections will get thoughtful comments from 5 reviewers. A 15-page RFC will get "LGTM" from 2 reviewers who skimmed it. Brevity is a feature.

3. The Motivation section is worth 50% of the RFC. If your problem statement is compelling, the solution almost writes itself. If it's weak, no amount of technical detail will save the RFC.

4. Every rejected RFC is valuable. A rejected RFC means you avoided building the wrong thing. Celebrate rejections. They saved time and money. The worst outcome is an approved RFC that should have been rejected.

5. RFCs should be written by the person doing the work. Not by a tech lead dictating to a junior engineer. The person who will implement the solution has the most to gain from the thinking process. Senior engineers should review, not write, most RFCs.

6. Start the RFC process before you need it. If you wait until your team is 50 engineers, introducing RFCs feels like bureaucracy. Start at 10 engineers, when it still feels like collaboration.

Action Plan: Introducing RFCs to Your Team

Step 1: Start Small

• Write your first RFC for a real upcoming project
• Use the template from this article (adapt it to your needs)
• Ask 2-3 trusted colleagues to review it
• Iterate on the template based on feedback

Step 2: Formalize the Process

• Create a shared template document that the team can copy
• Define when an RFC is required (use the criteria from this article)
• Set review timeline expectations (3-5 business days)
• Choose a storage location (Google Docs folder, GitHub repo, Notion database)

Step 3: Build the Habit

• Lead by example: write RFCs for your own projects
• Provide constructive feedback on others' RFCs
• Reference past RFCs in discussions ("We addressed this in RFC-12")
• Periodically review whether the process is helping or hindering

Step 4: Iterate

• After 10 RFCs, retrospect: What worked? What didn't?
• Adjust the template, the review process, or the criteria
• Archive old RFCs so they remain searchable
• Consider an RFC index page for discoverability

Key Takeaways

• RFCs catch wrong directions before code is written, saving weeks or months of wasted effort.
• Write an RFC for changes that are large (2+ engineer-weeks), cross-team, or hard to reverse.
• The Motivation section is the most important part. Spend 50% of your writing time there.
• Always present at least 3 alternatives (including "do nothing").
• Keep RFCs short (3-8 pages). Move implementation details to appendices.
• Set review deadlines and use lazy consensus to prevent blocking.
• RFCs are thinking tools first, approval gates second. The process of writing is more valuable than the document itself.

Sources

• Martin Fowler - Feature Toggles (Toggle Types Framework)
• Google SRE Book
• Amazon Science - Narrative Documents
• Rust Language RFCs (GitHub)
• HashiCorp Engineering Practices
• InfoQ - Engineering Culture Practices Survey

I'm Ismat, and I build BirJob — Azerbaijan's job aggregator scraping 80+ sources daily.