Why I stopped writing RFCs

The RFC process at the last three places I worked was, for the most part, a way of pretending we were having a conversation. Long documents went out, long documents came back, and the actual decision was made in a private DM forty minutes before the deadline.

I’ve stopped writing RFCs. Mostly. There are still situations where they are the right tool, but they are rarer than the prevailing engineering culture suggests.

What the RFC was supposed to be

The original idea is good: a long-form, asynchronous, written-down record of a proposed change. People can engage on their own time. The argument is on paper, so future-you can find it. The author has to make the case explicitly, which improves the quality of the proposal.

I have written RFCs that worked exactly this way. They are rare. The thing that makes them rare is that they require a culture where written debate is the substrate of decision-making — where reading the doc, commenting on it, and reading the responses is the work. Most engineering orgs do not have that culture, even the ones that loudly claim to.

What it usually becomes

In the absence of that culture, the RFC document becomes a ritual:

• Author writes 4,000 words.
• Two people skim it. One leaves a comment about a typo. One leaves a comment about a section the author already addressed.
• A meeting is scheduled to “discuss the RFC.”
• The meeting becomes the actual decision-making forum.
• The RFC document is never updated to reflect what was decided in the meeting.
• Six months later, someone reads the RFC and is misled about the system.

I have been the author in this loop. I have been the reader. I have been the person leaving the typo comment. None of these positions feel productive, and the system as a whole produces a worse decision than a 30-minute call would have.

What I do instead

For 90% of the things I would have written an RFC for, I now write a much shorter document — usually a single page, often a paragraph — and I send it directly to the people whose buy-in I actually need.

The shape is roughly:

• What I want to do, in one sentence.
• Why, in two or three.
• What I considered and ruled out, in two or three bullets.
• What I’d like from you, specifically. Not “thoughts?” — “I need to know if this conflicts with anything in the auth layer that you’re closer to than I am.”

This forces the kind of thinking the RFC was supposed to force, but in 200 words instead of 4,000. The reviewer can engage in five minutes. The decision happens in the same channel where everything else happens, instead of in a parallel ritual.

When a real argument breaks out, then I escalate to a longer document — and the longer document gets engagement, because the people reading it have already opted in to the conversation by responding to the short one.

The exceptions

There are still cases where I’d reach for an actual RFC:

• Multi-team change. When five teams need to be aligned, no DM is going to do it. Someone has to write the doc.
• Decisions you’ll need to defend in the future. When the cost of “we don’t remember why we did it that way” is high — usually for security, compliance, or load-bearing architectural choices — write it down. Even if nobody reads it now, future-you will be grateful.
• When the org genuinely has the culture for it. A few do. If yours does, ignore everything I just said.

The rest of the time, the RFC is a way of pretending we are doing more thinking than we actually are. The way out is to do less ritual and more deciding.