RFC Writing Guide

Why Write RFCs?

An RFC (Request for Comments) is how experienced engineering organizations make significant technical decisions. Unlike an ADR, which records a decision already made, an RFC is written before the decision to gather feedback. Google, Meta, Uber, and Stripe all use RFC processes for cross-team technical alignment.

The RFC process does three things: it forces the author to think rigorously, it gives stakeholders a structured way to weigh in, and it creates a durable record of the design rationale.

RFC Structure That Gets Read

Keep your RFC under 5 pages. Engineers will not read longer documents. Use this structure:

1. Summary (3-5 sentences)

What are you proposing and why? A busy VP should be able to read just this section and understand the proposal. Include the expected impact: "This will reduce order processing latency from 2s to 200ms for 95% of orders."

2. Problem Statement

Describe the pain precisely. Use data: error rates, latency percentiles, developer hours wasted, customer complaints. Quantified problems get faster approvals than vague ones. Also state what happens if you do nothing. The cost of inaction is part of the justification.

3. Proposed Solution

Describe the architecture at the right level of abstraction. Include a system diagram if the proposal involves multiple services. Call out which components change and which stay the same. Specify the API contract if other teams depend on it.

4. Alternatives Considered

List 2-3 alternatives you evaluated. For each, explain why you rejected it. Be honest. If an alternative was a close call, say so. This section builds trust with reviewers because it shows you actually explored the design space.

5. Rollout Plan

How will you ship this incrementally? What is the feature flag strategy? What is the rollback plan if things go wrong? What metrics will you watch during rollout? This section separates senior proposals from junior ones.

6. Open Questions

List anything you are uncertain about. This directs reviewer attention to where you actually need help, instead of having them bikeshed on sections you are already confident about.

Running the RFC Process

Set a review period of 5-7 business days. Assign 3-5 explicit reviewers who bring different perspectives (downstream consumers, platform team, security, SRE). After the review period, the author synthesizes the feedback, updates the proposal, and calls a 30-minute decision meeting. The meeting ends with one of three outcomes: Approved, Approved with Modifications, or Send Back for Revision.

Anti-Patterns to Avoid

The rubber stamp RFC, where you circulate it after you have already started building. The novel RFC, where you write 15+ pages that nobody reads. The ghost RFC, where you publish it and never follow up on comments. The consensus trap, where you wait for unanimous approval instead of informed consent from key stakeholders.