Writing Engineering RFCs

What Is an RFC?

A Request for Comments (RFC) is a written document that proposes a significant technical change, describes the problem being solved, presents a solution, evaluates alternatives, and solicits feedback from the team or organization. RFCs are one of the most important tools in an engineering organization's decision-making toolkit.

The RFC process serves multiple purposes: it forces the author to think through their proposal rigorously, it distributes knowledge across the team, it creates a searchable record of technical decisions, and it gives everyone a voice in important choices regardless of their meeting schedule or timezone.

The RFC Template

// RFC metadata and structure
interface RFC {
  id: string;           // "RFC-042"
  title: string;        // "Migrate User Service to Event-Driven Architecture"
  author: string;       // "Jane Smith"
  status: "draft" | "in-review" | "accepted" | "rejected" | "superseded";
  created: string;      // "2026-03-15"
  reviewDeadline: string; // "2026-03-29"
  approvers: string[];  // ["Tech Lead", "Staff Engineer"]
  stakeholders: string[]; // ["Platform Team", "Product Team"]
}

// The document sections:
// 1. Summary (2-3 sentences)
// 2. Context and Problem Statement
// 3. Goals and Non-Goals
// 4. Proposed Solution (with diagrams)
// 5. Alternatives Considered
// 6. Data Model Changes
// 7. API Changes
// 8. Migration Plan
// 9. Risks and Mitigations
// 10. Observability and Monitoring
// 11. Security Considerations
// 12. Timeline and Milestones
// 13. Open Questions
// 14. Decision (filled post-review)

Writing Each Section Well

Summary

Write this last. It should be 2-3 sentences that a busy VP could read and understand the proposal at a high level. If someone reads only the summary, they should know what you are proposing and why.

Context and Problem Statement

This is the most important section. If the reader does not understand the problem, they cannot evaluate the solution. Include:

• What is the current state of the system?
• What problem or opportunity does this RFC address?
• What data supports the need for change? (metrics, incident counts, developer surveys)
• What happens if we do nothing?

Goals and Non-Goals

Explicitly stating what the proposal does NOT aim to solve is as important as stating what it does. This prevents scope creep during review and sets clear expectations.

Alternatives Considered

This section builds trust. It shows the author has done their homework and considered other approaches. For each alternative, explain why it was rejected. A proposal with no alternatives considered suggests the author has a solution in search of a problem.

The Review Process

Tips for Effective Review

• Set a review deadline: Without a deadline, reviews drag on indefinitely. Two weeks is usually sufficient.
• Name specific reviewers: "Everyone should review this" means nobody will. Name 3-5 people whose input is essential.
• Respond to all comments: Even if the response is "Acknowledged, no change needed because X." This shows respect for the reviewer's time.
• Separate must-address from nice-to-have: Label comments so the author knows which feedback requires changes before approval.
• Accept good-enough: The goal is a good decision, not a perfect document. Do not let perfect be the enemy of good.

Building an RFC Culture

Introducing RFCs to a team that has never used them requires patience and modeling:

• Start by writing RFCs yourself as the Tech Lead. Show the team what good looks like.
• Keep the initial template simple. You can add sections as the team matures.
• Celebrate good RFCs publicly. "Sarah's RFC on the caching layer is a great example of thorough analysis."
• Make the RFC repository easily searchable and discoverable.
• Do not require RFCs for small changes. Use good judgment about when the process is warranted.