Scrolls
8 min read
On this page

The RFC Process

RFC stands for Request for Comments, and the name is intentional. It is a request — not an announcement, not a decree, not a fait accompli. An RFC is a formal mechanism for proposing a change, inviting structured feedback, and reaching a decision that the organization can commit to. When the process works, it produces better decisions with broader buy-in. When it does not, it produces bureaucracy that slows teams down without improving outcomes.

Understanding when and how to use RFCs — and when to skip them — is a skill that separates engineers who can influence an organization from engineers who can only influence their immediate team.

What an RFC Is

An RFC is a written proposal for a significant change, published to a broad audience for structured review. It differs from an informal design doc in several ways:

Design Doc                        RFC
-----------                       ---
Audience: immediate team          Audience: org-wide or cross-team
Scope: single project/feature     Scope: standards, patterns, infra
Process: informal review          Process: formal lifecycle
Decision: team lead decides       Decision: designated approvers
Duration: days to 1-2 weeks       Duration: weeks to months

An RFC is appropriate when a decision affects people beyond your immediate team. If you are choosing between two caching strategies for your service, that is a design doc. If you are proposing that all services in the organization adopt a standard caching pattern, that is an RFC.

The key distinction is audience and impact radius. Design docs serve a team. RFCs serve an organization.

When to Write an RFC vs. Just Talking

Not every cross-team decision needs an RFC. The overhead of a formal process is only justified when the benefits — broad input, documented reasoning, clear decision — outweigh the cost of writing, reviewing, and managing the process.

Write an RFC when:

  • The decision affects multiple teams that do not regularly coordinate
  • The change sets a precedent or establishes a pattern others will follow
  • The decision is difficult or expensive to reverse
  • There is genuine disagreement about the right approach and you need a structured way to resolve it
  • You need a documented record of the decision and its rationale for future reference
  • The change affects shared infrastructure, APIs, or standards

Just talk when:

  • The decision affects only your team
  • The people whose input you need are easily reachable
  • The change is easily reversible
  • There is broad informal agreement and you just need to formalize it
  • The cost of the RFC process exceeds the cost of getting the decision slightly wrong
Needs an RFC:
- Adopting a new programming language for backend services
- Changing the organization's API versioning strategy
- Introducing a new service mesh
- Deprecating a widely-used internal library
- Changing the on-call rotation structure across teams

Does not need an RFC:
- Choosing a library for a single service
- Refactoring internal code that no other team depends on
- Adding a feature flag framework to your team's service
- Updating a team's coding style guide

The test: if you implemented this change without telling anyone outside your team, would anyone notice or be affected? If yes, consider an RFC. If no, just do it.

The RFC Lifecycle

A well-run RFC process has clear stages with defined transitions:

Draft

The author writes the initial proposal. During this stage, the RFC is not yet open for formal review. The author may share it informally with a few trusted reviewers to improve the draft before broader publication.

Draft checklist:
- Problem statement is clear and well-motivated
- Proposed solution is described with sufficient detail
- Alternatives are documented with rejection reasoning
- Impact assessment: who is affected and how
- Migration plan if the change affects existing systems
- Success criteria: how will we know this worked

Review

The RFC is published to its intended audience with a clear review period. This is the stage where feedback is actively solicited and the proposal may change significantly based on input.

Review period norms:
- Minimum: 1 week (for focused, low-controversy proposals)
- Typical: 2 weeks (for most RFCs)
- Extended: 3-4 weeks (for highly impactful or controversial
  proposals, or when key stakeholders are unavailable)

The review period should be stated explicitly:
"This RFC is open for review from April 7 to April 21.
Please provide feedback by April 21 EOD."

During review, the author should:

  • Respond to all substantive comments
  • Update the RFC to incorporate valid feedback
  • Track changes so reviewers can see what evolved
  • Escalate unresolved disagreements when needed

Decision

After the review period, a designated decision-maker (or committee) reviews the RFC, the feedback, and the author's responses. The outcome is one of three states:

Accepted: The proposal is approved. Implementation can proceed.
The RFC becomes a reference document for the decision.

Rejected: The proposal is declined. The RFC documents why,
preserving the reasoning for future reference. A rejected RFC
is not a failure — it means the process worked and the idea
was evaluated on its merits.

Deferred: The proposal has merit but the timing is not right,
more information is needed, or dependencies must be resolved
first. The RFC is revisited at a specified future date.

Implementation

For accepted RFCs, the proposal moves to implementation. The RFC itself does not need to cover implementation details exhaustively — that is what design docs are for. The RFC establishes the direction; design docs handle the execution.

Superseded

Over time, some RFCs are replaced by newer proposals. When this happens, the original RFC is marked as superseded with a link to its replacement. This maintains the historical chain of decisions.

Anatomy of an RFC

A good RFC template includes these sections:

# RFC-NNN: [Title]
Author: [name]
Status: [Draft | In Review | Accepted | Rejected | Deferred]
Created: [date]
Review deadline: [date]

## Summary
One paragraph explaining the proposal. A reader who only reads
this should understand what is being proposed and why.

## Motivation
Why is this change needed? What problem does it solve? What
happens if we do nothing?

## Detailed Proposal
The specifics of what is being proposed. Enough detail for
reviewers to evaluate the approach.

## Impact Assessment
Who is affected by this change? What teams need to take action?
What systems need to be modified?

## Migration Plan
If the change affects existing systems, how will they transition?
What is the timeline? Is there a backward-compatibility period?

## Alternatives Considered
What other approaches were evaluated? Why were they rejected?

## Risks
What could go wrong? What are the mitigations?

## Success Criteria
How will we know this change achieved its goals?

Not every RFC needs every section. A lightweight proposal to standardize a naming convention needs less ceremony than a proposal to migrate the organization's primary database. Scale the formality to the impact.

Making the Process Work

The RFC process fails in predictable ways. Avoiding these failure modes is more important than perfecting the template.

Failure: RFCs that nobody reads. If the organization publishes RFCs to a mailing list that nobody checks, the process is theater. Fix: establish a clear channel for RFCs (a dedicated Slack channel, a wiki category, a GitHub repository). Make reading RFCs part of senior engineers' explicit responsibilities.

Failure: Reviews that are rubber stamps. If RFCs are always approved without substantive feedback, the process is not surfacing disagreements — it is suppressing them. Fix: actively recruit skeptics as reviewers. Make it safe to dissent.

Failure: Endless review cycles. Some RFCs get stuck in perpetual review, with new objections surfacing every week. Fix: enforce review deadlines. After the deadline, the decision-maker decides based on available input.

Failure: RFCs as territory markers. Sometimes people write RFCs not to improve a decision but to claim ownership of a technical area. The RFC becomes a political tool rather than a technical one. Fix: evaluate RFCs on their technical merits. The author's seniority or team should not determine the outcome.

Failure: Too many RFCs. If every minor decision requires an RFC, the process creates more overhead than value. Engineers spend more time writing and reviewing proposals than building software. Fix: set clear thresholds for when an RFC is needed. Most decisions should not require one.

Healthy RFC cadence for a 50-engineer organization:
- 2-4 RFCs per month
- Most are resolved within 2-3 weeks
- About 70% accepted, 20% modified significantly during
  review, 10% rejected or deferred

Unhealthy signals:
- More than 10 RFCs open simultaneously
- RFCs taking more than 6 weeks to decide
- RFCs with zero comments
- 100% acceptance rate

RFC Culture

The RFC process is only as good as the culture surrounding it. Technical culture determines whether the process produces genuine intellectual engagement or performative compliance.

Good RFC culture looks like:

  • People disagree respectfully and with evidence
  • Junior engineers feel empowered to comment on senior engineers' proposals
  • Rejected RFCs are treated as learning, not failure
  • Authors genuinely change their proposals based on feedback
  • The focus is on finding the best solution, not on being right
  • Past RFCs are referenced when making related decisions

Bad RFC culture looks like:

  • Comments are personal attacks disguised as technical feedback
  • Only senior engineers write RFCs
  • Authors defend their proposals regardless of feedback quality
  • RFCs are approved based on the author's political standing
  • Nobody reads RFCs from other teams
  • Rejected RFC authors are stigmatized

Building good RFC culture is a leadership responsibility. It starts with senior engineers modeling the behavior: writing RFCs that honestly assess trade-offs, accepting feedback gracefully, engaging genuinely with proposals from junior engineers, and treating the process as a learning tool rather than a gatekeeping mechanism.

Common Pitfalls

Writing an RFC when a conversation would suffice. If the three people who need to agree are all in the same Slack channel, talk to them directly. Do not create process overhead for decisions that can be made informally.

Treating the RFC as the final design. An RFC establishes direction. The implementation details still need design docs, prototypes, and iteration. Do not try to solve every implementation question in the RFC.

Not assigning a decision-maker. An RFC without a designated approver drifts indefinitely. Someone must have the authority and responsibility to make the final call.

Ignoring rejected RFCs. Rejected RFCs contain valuable thinking. They document approaches that were considered and why they were declined. Archive them accessibly. They save future engineers from proposing the same rejected idea without new information.

Making the RFC process too heavyweight. If writing an RFC requires filling out a 15-section template and getting approvals from three committees, engineers will avoid the process and make decisions informally. Keep the process lightweight enough that people actually use it.

Not evolving the process. Periodically review whether the RFC process is serving the organization. If it is too slow, streamline it. If it is not catching important decisions, lower the threshold. If it is creating too much overhead for minor decisions, raise the threshold.

Key Takeaways

  • An RFC is a formal mechanism for proposing cross-team changes, inviting structured feedback, and reaching documented decisions. Use it when the decision affects multiple teams and is hard to reverse.
  • The RFC lifecycle has clear stages: draft, review, decision (accepted/rejected/deferred), implementation, and eventually superseded. Each stage should have defined criteria and timelines.
  • Do not write an RFC when a conversation will do. The overhead of a formal process is only justified for decisions with broad impact.
  • The process fails predictably: unread RFCs, rubber-stamp reviews, endless cycles, political misuse, and over-proliferation. Design the process to prevent these failure modes.
  • RFC culture matters more than RFC templates. A culture where people engage honestly, disagree respectfully, and treat the process as a thinking tool produces better outcomes than any document format.
  • Keep the process lightweight. An RFC process that people avoid because it is too heavy is worse than no process at all.