Writing Engineering RFCs That Get Approved

When I first started writing RFCs at a mid-stage startup, I thought the hard part was the technical solution. I spent days perfecting architecture diagrams and benchmarking alternatives. Then I watched my beautifully crafted RFC sit in review limbo for three weeks before being sent back with "needs more context on business impact."

That experience taught me something important: an RFC isn't a technical document. It's a persuasion document wrapped in technical language. The engineers who consistently get their proposals approved understand this distinction deeply.

Why Most RFCs Fail

I've reviewed hundreds of RFCs over my career, and the ones that stall share common patterns. They jump into solutions without establishing shared understanding of the problem. They assume the reader has the same context as the author. They treat alternatives as a checkbox exercise rather than genuine exploration.

The most common failure mode I see is what I call the "solution-first RFC." The author has already decided what to build and reverse-engineers the document to justify that decision. Reviewers can smell this from a mile away, and it immediately puts them in adversarial mode rather than collaborative mode.

The Structure That Works

After years of iteration, I've landed on a structure that consistently moves RFCs through the approval process smoothly. Here's the framework:

Section	Purpose	Common Mistake
Problem Statement	Build shared understanding	Too vague or too technical
Context & Constraints	Set boundaries for solutions	Omitting business constraints
Proposed Solution	Present your recommendation	Jumping to implementation details
Alternatives Considered	Show intellectual honesty	Strawman alternatives
Migration Plan	Reduce perceived risk	Ignoring the transition period
Success Metrics	Define "done"	Vanity metrics
Open Questions	Invite collaboration	Listing questions you already answered

Start With the Problem, Not the Solution

The single biggest improvement you can make to your RFCs is spending more time on the problem statement. I now spend roughly 40% of my writing time on the first two sections. Here's why: if stakeholders don't agree on the problem, they'll never agree on the solution.

A strong problem statement includes:

• What's happening today that's painful
• Who is affected and how frequently
• What the cost of inaction looks like
• Why now (what changed to make this urgent)

When I was leading the platform team at my previous company, we needed to migrate from a monolithic deployment to microservices. My first RFC draft led with the architecture. It was rejected. My second draft started with "Our deployment frequency has dropped from 12 times per week to 3 times per week over the past quarter because teams are blocked by each other's changes." That version was approved in four days.

Writing Alternatives That Build Trust

The alternatives section is where trust is built or broken. If your alternatives are obviously inferior strawmen, reviewers will question your intellectual honesty. If your alternatives are genuinely competitive, reviewers trust that you've done the thinking.

I follow a rule: every alternative should have at least one dimension where it's genuinely superior to your proposed solution. If you can't find that dimension, you haven't understood the alternative well enough.

For each alternative, I include:

• A brief description of the approach
• Its key advantages (honestly presented)
• Why I'm not recommending it (specific tradeoffs)
• Under what circumstances I would recommend it instead

This last point is particularly powerful. It shows reviewers that you're not dogmatic about your recommendation and that you've thought about conditions that might change your mind.

The Pre-RFC Conversation

Here's a tactic that dramatically improved my approval rate: before writing the full RFC, I have informal conversations with the two or three people most likely to push back. I ask them what concerns they'd have and what evidence would address those concerns.

This isn't political maneuvering—it's research. Those conversations almost always improve the RFC because they surface constraints or context I didn't have. And when those people see their concerns addressed in the document, they become advocates rather than blockers.

Sizing Your RFC Appropriately

Not every decision needs a full RFC. I use this mental model for calibration:

Decision Size	Document Type	Approval Time Target
Affects 1 team, reversible	Lightweight design doc	2-3 days
Affects 2+ teams, reversible	Standard RFC	1-2 weeks
Affects org, irreversible	Full RFC with exec review	2-4 weeks
Platform/infra, high cost	RFC with proof of concept	3-6 weeks

One mistake I made early in my career was writing heavyweight RFCs for decisions that should have been lightweight design docs. This trained the organization to see RFCs as bureaucratic overhead rather than valuable alignment tools.

Handling Feedback Gracefully

When feedback comes in, resist the urge to defend your proposal immediately. I've adopted a "24-hour rule"—I wait at least 24 hours before responding to substantial criticism. This gives me time to actually consider whether the feedback has merit rather than reacting defensively.

When I do respond, I categorize feedback into three buckets:

1. Incorporated: I agree and I'm updating the RFC
2. Acknowledged with explanation: I understand the concern but here's why I'm maintaining my recommendation
3. Deferred: Valid concern but out of scope for this RFC

Being explicit about these categories reduces back-and-forth and shows reviewers that their input was genuinely considered.

The Living Document Approach

One practice that's served me well is treating approved RFCs as living documents. After implementation, I add an "Outcome" section that captures what actually happened versus what we predicted. This builds organizational trust in the RFC process because teams can see that proposals are accountable to reality.

I've found that teams which maintain this practice write better RFCs over time because they learn from the gap between prediction and outcome.

Common Anti-Patterns to Avoid

Through painful experience, I've identified these RFC anti-patterns:

• The Novel: 20+ pages that nobody will read completely
• The Fait Accompli: Writing the RFC after you've already started building
• The Kitchen Sink: Trying to solve five problems in one document
• The Vague Timeline: "We'll implement this over the next few months"
• The Missing Stakeholder: Not including someone who has veto power

Each of these undermines the RFC's purpose as an alignment tool and increases the likelihood of rejection or, worse, approval followed by implementation problems.

Key Takeaways

• An RFC is a persuasion document, not just a technical document—write it for your audience
• Spend 40% of your effort on the problem statement and context sections
• Have pre-RFC conversations with likely critics to surface concerns early
• Make alternatives genuinely competitive to build reviewer trust
• Size your document to match the decision's impact and reversibility
• Wait 24 hours before responding to substantial criticism
• Treat approved RFCs as living documents with outcome tracking
• The goal isn't just approval—it's building organizational trust in the process

The best RFC writers I know aren't necessarily the best engineers. They're the ones who understand that technical decisions happen in a social context, and they design their documents to work within that reality.