The RFC Process: Engineering Democracy

What Is an RFC?

Imagine you're a city planner proposing a new bridge. You don't just build it — you publish the plans, hold public comment periods, respond to objections from engineers and residents, and revise the design before breaking ground. An RFC (Request for Comments) is the engineering equivalent of that process.

An RFC is a document that proposes a significant technical change — adopting a new programming language, re-architecting a service, defining a new API standard, or establishing a new operational practice. The name comes from the IETF (Internet Engineering Task Force), the body that has used RFCs to define internet standards like HTTP and TCP/IP since the 1960s. Modern engineering teams have adapted the format for internal use.

The RFC Lifecycle

The value of an RFC is less about the final document and more about the process it fosters:

1. Drafting: An engineer identifies a problem, considers multiple options, and writes a proposal detailing the preferred solution, its trade-offs, and the alternatives considered (and why they were rejected). The act of writing forces the author to stress-test their own thinking.
2. Reviewing: The draft is shared widely — typically via a pull request in a proposals or rfcs repository, or a shared Google Doc. Other engineers, even from unrelated teams, leave comments, ask hard questions, and point out potential failure modes. A comment period of 1–2 weeks is common.
3. Iterating: The author responds to feedback, updates the document, and builds consensus. Some objections lead to design changes; others are acknowledged and explicitly overruled with documented reasoning.
4. Finalizing: Once rough consensus is reached, the RFC is marked as Accepted (or Rejected, with reasons) and becomes the official plan of record. Accepted RFCs are archived and referenced in future design discussions.

A Minimal RFC Template

Most teams use a template to ensure consistency. A minimal version looks like this:

# RFC-042: Migrate Internal Services to gRPC

**Status:** Draft | Under Review | Accepted | Rejected
**Author:** Jane Smith
**Date:** 2024-01-15
**Reviewers:** Platform Team, Backend Guild

## Problem Statement
Our REST-based internal APIs have no enforced schema, leading to 
integration bugs that are only caught in production. Debugging 
cross-service calls is difficult because there is no standard 
error format.

## Proposed Solution
Adopt gRPC with Protocol Buffers for all new internal service 
communication. Existing REST endpoints will be maintained until 
a migration path is defined in a follow-up RFC.

## Alternatives Considered
- **GraphQL:** Rejected because it adds complexity for non-query 
  use cases (streaming, bidirectional communication) and has 
  weaker type enforcement at the transport layer.
- **JSON Schema + OpenAPI:** Rejected because it requires 
  additional tooling and doesn't enforce schema at the 
  serialization layer.

## Trade-offs
- **Pro:** Strong typing, code generation, built-in streaming.
- **Con:** Requires learning curve; not human-readable on the wire.
- **Risk:** Browser clients cannot use gRPC directly without a 
  proxy layer (e.g., gRPC-Web or Envoy).

## Open Questions
1. How do we handle versioning when a proto schema changes?
2. Which teams will pilot this first?

## Decision
[To be filled after review period]

Why RFCs Are a Superpower for Junior Engineers

This process democratizes decision-making in a way that meetings never can. A junior engineer with a well-written RFC can influence the direction of the entire platform. It shifts influence from the loudest voice in the room to the most cogent argument on the page. It also creates a paper trail: when someone asks "why did we choose gRPC over REST?" six months later, the answer is a link, not a shrug.

The failure mode to watch for is RFC theater — where documents are written after the decision has already been made informally, and the review process is a rubber stamp. This destroys trust in the process and discourages genuine participation. The antidote is cultural: senior engineers must visibly change their minds based on RFC feedback, demonstrating that the process has real teeth.