When NOT to Write an RFC

The hardest part of running an RFC process is not getting engineers to write RFCs. It is getting them to write the right RFCs. An organization that requires an RFC for every technical decision will grind to a halt. An organization that never writes RFCs will make the same mistakes repeatedly. The sweet spot is somewhere in the middle, and finding it requires judgment, not rules.

The Cost of Over-Documenting

When everything requires an RFC, several things go wrong simultaneously.

Engineers start treating the process as overhead. Writing a two-page proposal for a change that could be reviewed in a pull request feels like bureaucracy. Once engineers view the RFC process as red tape, they stop engaging meaningfully with the RFCs that actually matter.

Decision velocity drops. If renaming a database column requires an RFC, an RFC review, and an RFC approval, changes that should take a day take a week. Multiply this across dozens of small decisions per sprint and the team is spending more time writing about work than doing work.

The signal-to-noise ratio collapses. When there are thirty open RFCs and only two of them involve genuinely consequential decisions, reviewers cannot tell which ones deserve their attention. Important proposals get the same cursory glance as trivial ones.

When to Skip the RFC

Some categories of work almost never need an RFC.

Bug fixes. If the production service is returning 500 errors because of a null pointer dereference, the fix does not need a design document. Fix it, write a postmortem if warranted, and move on.

Small refactors. Renaming a module, extracting a helper function, consolidating duplicate code -- these are improvements to existing decisions, not new decisions. A pull request with a clear description is sufficient.

Well-understood patterns. If your team has built twelve CRUD services and you are building a thirteenth, you do not need an RFC. The pattern is established. The RFC was the first time you decided on the pattern; every subsequent instance follows it.

Reversible changes with limited blast radius. Adding a feature flag, changing a log format, updating a dependency version, tweaking a cache TTL -- these can be reverted in minutes if they cause problems. The cost of being wrong is low, so the cost of the decision process should be low too.

Routine operational work. Scaling up a database, rotating credentials, updating CI pipelines. These are execution tasks, not design decisions.

When to Write the RFC

Other categories of work almost always warrant an RFC.

Cross-team changes. Any change that requires coordination between two or more teams needs a written proposal. Verbal agreements in a Slack thread are not sufficient when three teams need to align on a migration plan. The RFC is the shared understanding.

New systems or services. Standing up a new service, introducing a new data store, or building a new pipeline is an architectural decision with long-term consequences. The RFC should capture why this system exists, what alternatives were considered, and how it fits into the broader architecture.

Irreversible decisions. Choosing a database engine, defining a public API contract, selecting a wire protocol, or committing to a vendor. Once these decisions are made and other systems depend on them, changing course is expensive. The cost of the decision justifies the cost of a thorough proposal.

Breaking changes. Any change that will break existing consumers -- whether they are other internal services, external API clients, or users -- needs a written plan. The RFC should include a migration path and a rollback strategy.

Changes to shared infrastructure. Modifying the authentication system, the logging pipeline, the deployment process, or the CI/CD configuration affects everyone. These changes deserve scrutiny proportional to their blast radius.

Decisions with significant cost implications. Adopting a new cloud service, committing to a contract, or making a build-vs-buy decision that locks in spending for the next year.

The Two-Way Door Framework

Jeff Bezos articulated a useful mental model for decision-making in his 2015 letter to Amazon shareholders. He distinguished between two types of decisions:

One-way doors (Type 1 decisions) are irreversible or nearly so. Once you walk through, you cannot easily walk back. Choosing your primary database, defining a public API schema, or committing to a multi-year vendor contract -- these are one-way doors. They deserve careful analysis, broad input, and a written record of the reasoning.

Two-way doors (Type 2 decisions) are reversible. If you walk through and do not like what you see, you can walk back. Trying a new caching strategy, experimenting with a different UI framework on an internal tool, or adjusting a rate limit -- these are two-way doors. They should be made quickly, by individuals or small teams, without heavyweight process.

Bezos's observation was that as organizations grow, they tend to treat all decisions like one-way doors. This makes them slow without making them better. The RFC process should be calibrated to the door type.

One-way doors get an RFC. Two-way doors get a pull request.

A Simple Decision Framework

If you want a concrete checklist, here is one. Write an RFC if the answer to any of these is yes:

1. Does this affect more than one team? Cross-team changes need a shared written understanding.
2. Is this hard to reverse? If rolling back takes more than a day of work, write it down.
3. Does this introduce a new architectural component? New services, new data stores, new external dependencies.
4. Will people need to understand this decision six months from now? If future-you will ask "why did we do this," present-you should write it down.
5. Does this change a public contract? APIs, data formats, or interfaces that external consumers depend on.

If the answer to all five is no, skip the RFC. Use a pull request description, a Slack thread, or a brief note in your team's decision log.

The Gray Zone

Some decisions live in between. A moderately complex feature that only affects one team. A refactor that touches many files but does not change behavior. A dependency upgrade that is theoretically reversible but practically painful.

For these, use a lightweight decision record instead of a full RFC. A lightweight record is a paragraph or two: what the decision is, why you are making it, and what you considered. It takes fifteen minutes to write and gives future engineers enough context to understand the choice. This can live in a PR description, a doc comment, or a brief page in your team's documentation.

The key insight is that the RFC process is not binary. It is not "full RFC or nothing." Having a lightweight option for medium-stakes decisions prevents two failure modes: writing a heavyweight RFC for a medium-stakes decision (which is wasteful) and writing nothing for a medium-stakes decision (which is risky).

Calibrating Over Time

The right threshold for "when to RFC" is different for a five-person startup and a five-hundred-person engineering org. It changes as your team grows, as your architecture matures, and as your institutional knowledge develops.

A young team with a new codebase should RFC more aggressively, because most decisions are precedent-setting. A mature team with established patterns should RFC less, because most decisions follow existing precedent.

Review your RFC frequency quarterly. If you are writing fewer than one RFC per team per month, you are probably under-documenting important decisions. If you are writing more than one per team per week, you are probably over-documenting and slowing yourselves down.

The goal is not to document everything. The goal is to document the things that matter, at the level of depth they deserve, and to skip the rest without guilt.