What Is an RFC? The Complete Guide for Engineering Teams

On April 7, 1969, Steve Crocker — a UCLA graduate student working on ARPANET — wrote a document titled "Host Software." He numbered it RFC 1. Crocker deliberately chose the name "Request for Comments" to avoid sounding too authoritative. He was 23 and didn't want to step on anyone's toes. That choice of tone — inviting discussion rather than dictating — turned out to be one of the most influential design decisions in computing history.

The IETF has published over 9,000 RFCs since then. They defined TCP/IP (RFC 793), HTTP (RFC 2616), and pretty much every protocol the internet runs on. But somewhere along the way, the RFC format escaped the standards body and found its way into engineering organizations as an internal tool for making decisions.

How RFCs Work Inside Engineering Teams

An internal RFC is a written proposal for a significant technical change. You write one before building, not after. The document describes what you want to do, why, and how — then your team reviews it asynchronously.

The goal isn't to produce a spec that lasts 30 years. It's to force clarity of thought before anyone writes code, and to give the team a structured way to weigh in.

Here's the typical lifecycle:

Draft — An engineer writes the proposal.
Review — The team reads it, leaves comments, asks questions.
Discussion — The author revises based on feedback. Sometimes there's a synchronous meeting for contentious points.
Decision — The RFC is accepted, rejected, or deferred.
Implementation — The team builds it, using the RFC as a reference.

The document stays around as a record of what was decided and why. Six months later, when someone asks "why did we build it this way?", you have an answer.

Who Uses RFCs?

RFCs aren't a niche practice. Some of the most effective engineering organizations run on them.

Google uses design docs as a core part of their engineering culture. Before significant projects, engineers write a document that covers motivation, design, alternatives, and trade-offs. These get reviewed by peers and, for larger efforts, by senior engineers. Google's design doc culture is well-documented in their "Software Engineering at Google" book (Winters, Manshreck, Wright — O'Reilly, 2020).

Uber formalized an RFC process as the company scaled past the point where decisions could happen in hallway conversations. Their engineering blog has described how they use RFCs to coordinate across hundreds of engineering teams working on interconnected systems.

Rust uses RFCs to propose changes to the language itself. The rust-lang/rfcs repository on GitHub is public — anyone can read the proposals that shaped features like async/await or the module system. Each RFC goes through a structured review period before it's merged or closed.

React adopted a similar public RFC process. The reactjs/rfcs repository is where features like Hooks (RFC 68) and Server Components were proposed and debated before implementation.

Oxide Computer and HashiCorp have both written publicly about their RFC processes, emphasizing that writing things down before building is what lets small teams punch above their weight.

The pattern scales from 5-person startups to 10,000-person organizations. The process details vary, but the core idea is the same: write it down, get feedback, then build.

What Does an RFC Contain?

There's no universal template, but most RFCs cover these sections:

Summary — A one-paragraph explanation of what you're proposing. Someone should be able to read this and know whether the rest of the document is relevant to them.

Motivation — Why are you proposing this? What problem exists today? What happens if you do nothing? This is the most important section. If the motivation isn't compelling, the rest doesn't matter.

Detailed Design — How the proposed solution works. This is where you get specific about APIs, data models, system interactions, and implementation details. The level of detail should match the scope — a database migration needs more precision than a logging strategy.

Alternatives Considered — What other approaches did you evaluate? Why did you reject them? This section builds trust. It shows you didn't just grab the first idea that came to mind.

Drawbacks — What are the downsides of your proposal? Every design has trade-offs. Acknowledging them honestly makes reviewers more likely to trust your judgment.

Open Questions — What haven't you figured out yet? It's fine to have unresolved details. Calling them out explicitly invites focused feedback.

Some teams also include a Migration Plan (how you get from here to there) and Security Considerations (relevant for anything touching auth, data access, or external APIs).

When Should You Write an RFC?

Not every change needs an RFC. Writing one for a CSS fix or a dependency bump is overhead that buys you nothing. Here's a reasonable heuristic:

Write an RFC when a change is irreversible or expensive to reverse. Choosing a database, defining an API contract, restructuring a monolith — these are hard to undo once code is in production and other teams depend on it.

Write an RFC when a change affects multiple teams. If your proposal changes how another team's service behaves, they deserve a chance to review it before you ship.

Write an RFC when reasonable engineers would disagree about the right approach. If the answer is obvious, just do it. If three people on your team would make three different choices, the discussion is worth having on paper.

Skip the RFC for well-understood patterns, small scope changes, or anything easily reversible. Feature flags, A/B tests, and minor refactors don't need formal proposals.

Who Writes Them?

Anyone. RFCs shouldn't be a senior-engineer-only practice. In fact, one of the strongest arguments for the RFC process is that it levels the playing field. A junior engineer with a well-reasoned written proposal can be more persuasive than a senior engineer arguing from gut instinct in a meeting.

Writing an RFC also develops engineering judgment. The act of writing down your reasoning — articulating trade-offs, anticipating objections, structuring an argument — makes you a better engineer whether or not the RFC is accepted.

That said, authoring an RFC doesn't mean working in isolation. Most good RFCs start with informal conversations. Talk to the people who know the system, sketch ideas on a whiteboard, then write the document. The RFC captures the thinking; it doesn't have to be the first time anyone hears the idea.

The Real Value

The document itself matters, but the process around it matters more. RFCs create a forcing function for clear thinking. They give introverts an equal voice. They produce a searchable archive of decisions. And they save teams from the endless loop of relitigating past choices because nobody wrote down why something was decided.

If your team makes architectural decisions in Slack threads, meeting rooms, or "whoever talks loudest" sessions — and then wonders why new hires take months to understand the system — an RFC practice is probably the highest-leverage process improvement you can make.