7 RFC Anti-Patterns That Kill Your Engineering Culture

An RFC process can be one of the most valuable tools in your engineering organization. It can also become a bureaucratic wasteland that engineers dread and managers ignore. The difference usually comes down to a handful of anti-patterns that creep in gradually, each one eroding trust in the process a little more.

Here are seven of the most common, how to spot them, and what to do about each.

1. The Novel

What it looks like: A 50-page RFC that covers every conceivable edge case, includes a full literature review of prior art, and reads like a dissertation. Nobody finishes reading it. Reviewers skim the introduction, skip to the conclusion, and approve.

Why it happens: The author is thorough to a fault, or insecure about the proposal and trying to preempt every possible objection. Sometimes it is a cultural problem -- the team equates length with rigor.

How to fix it: Set a soft page limit. Two to five pages covers most proposals. If an RFC needs more, it probably needs to be split into multiple proposals. Encourage authors to move detailed analysis into appendices that reviewers can consult if needed but are not required to read. The core document should answer three questions: what problem are we solving, what is the proposed solution, and what are the alternatives.

2. The Rubber Stamp

What it looks like: RFCs are approved within hours with comments like "LGTM" or "looks good to me." No substantive questions are raised. The approval rate is suspiciously close to 100%.

Why it happens: Reviewers are too busy to engage deeply. There is a social cost to pushing back -- nobody wants to be the person who blocks a colleague's proposal. Or the organization has no real expectation that reviewers will do more than glance at the document.

How to fix it: Require at least one substantive question or piece of feedback from each reviewer before approval. Make it explicit that pushing back is not adversarial -- it is the point. Some teams rotate a "devil's advocate" role for each RFC, giving one reviewer explicit permission (and responsibility) to challenge the proposal. Track review depth as a health metric. If every RFC is approved in under a day with no discussion, the process is not working.

3. The Ghost RFC

What it looks like: An RFC is written, circulated for review, comments trickle in... and then nothing happens. It sits in "Under Review" for weeks, then months. Nobody makes a decision. The author eventually builds the thing anyway, or moves on to something else.

Why it happens: There is no clear decision-maker. The process defines how to propose and how to review, but not how to decide. Or the decision-maker is a committee, and scheduling the meeting to make the call keeps slipping.

How to fix it: Every RFC needs a designated decision-maker -- one person (not a committee) who is responsible for moving the RFC to Accepted, Rejected, or Needs Revision within a defined timeframe. Two weeks is a reasonable default. If the deadline passes without a decision, the RFC should escalate automatically. The decision-maker does not need to be the most senior person; they need to be the person with the most context on the problem space.

4. The Solution-First RFC

What it looks like: The RFC opens with "I propose we use Kafka for our event bus" and spends four pages describing the Kafka architecture. The problem statement is a single sentence buried in the second paragraph: "We need a way to handle async events." There is no analysis of why the current approach is insufficient, no discussion of requirements, and the alternatives section reads "We could use RabbitMQ but Kafka is better."

Why it happens: The author has already decided on the solution and is writing the RFC to justify it. This is natural -- engineers are problem-solvers, and by the time they sit down to write, they have usually been thinking about the solution for days.

How to fix it: Make the problem statement the first section of the template, and make it mandatory for reviewers to evaluate the problem statement before the solution. A good test: could a reasonable person read the problem statement and propose a completely different solution? If yes, the problem statement is doing its job. If the problem statement only makes sense in the context of the proposed solution, it needs rewriting. Some teams require the problem statement to be reviewed and approved before the author writes the solution section.

5. The Solo RFC

What it looks like: One engineer writes the entire RFC in isolation, drops it into the review queue, and waits for feedback. The proposal is technically sound but misses context that other team members could have provided. Reviewers feel like they are being presented with a fait accompli rather than being invited to collaborate.

Why it happens: The author treats the RFC as a deliverable rather than a conversation. Or the team culture frames RFC writing as an individual contribution rather than a collaborative one.

How to fix it: Encourage co-authorship. Two or three engineers collaborating on an RFC produce a better document than one engineer working alone. Even if one person does most of the writing, having a "sparring partner" who challenges assumptions during drafting catches problems before the review phase. Another approach: share a one-paragraph problem statement with the team before writing the full RFC, and incorporate early feedback into the draft. This turns the RFC from a presentation into a dialogue.

6. The Retroactive RFC

What it looks like: The system is already built. The code is in production. Now someone writes an RFC describing what was built and asks for approval. The "review" is awkward because everyone knows the decision is already made. Rejecting it would mean throwing away working code.

Why it happens: Deadlines. A feature needed to ship fast, there was not time for the RFC process, and the team promised to write it up afterward. Sometimes it is a new process -- the team adopted RFCs recently, and there is an implicit expectation to retroactively document existing systems.

How to fix it: Distinguish between RFCs (forward-looking proposals) and ADRs (Architecture Decision Records, which document decisions already made). Both are valuable, but they serve different purposes. If a team consistently writes retroactive RFCs, the real problem is that the RFC process is too heavy for the pace of development. Simplify it. A lightweight RFC that takes an hour to write is more likely to be written before implementation than a heavyweight one that takes a week. For genuinely urgent decisions, allow a "lightweight decision record" that captures the what and why in a paragraph, with a commitment to write a full RFC if the system needs to evolve.

7. The Bikeshed

What it looks like: The RFC proposes migrating the payment system to a new architecture. The comments are entirely about whether to name the new service "payment-gateway" or "payment-proxy." Three days of debate ensue about naming conventions. The actual architecture receives no scrutiny.

Why it happens: This is Parkinson's Law of Triviality in action. C. Northcote Parkinson observed that a committee asked to approve a nuclear power plant will spend most of its time debating the design of the staff bike shed -- because everyone feels qualified to opine on a bike shed, while the reactor design is too complex for most members to engage with.

In RFC reviews, the same dynamic plays out. Naming, formatting, and API surface details are accessible to every reviewer. Distributed systems tradeoffs, consistency models, and failure mode analysis require deep expertise. The path of least resistance is to comment on what you understand.

How to fix it: Separate structural feedback from surface-level feedback. You can do this with explicit labels: "Blocking" comments address fundamental issues with the approach, while "Non-blocking" comments address details that can be resolved after the proposal is accepted. The decision-maker should focus on resolving blocking feedback and batch non-blocking feedback for the implementation phase. Another technique: ask reviewers to explicitly state their assessment of the core proposal ("I agree with the approach" or "I have concerns about the approach") before leaving detailed comments. This forces engagement with the substance.

The Common Thread

Every one of these anti-patterns shares a root cause: the process has become disconnected from its purpose. The purpose of an RFC is to make better technical decisions by thinking through problems collaboratively and in writing. When the process serves that purpose, engineers value it. When it becomes a checkbox, a bottleneck, or a performance, engineers route around it.

The fix is almost always the same: make the process lighter, make the expectations clearer, and make the feedback loops faster. If your RFCs are painful, the process is probably too heavy. If your RFCs are rubber-stamped, the expectations are probably too vague. If your RFCs are ghosted, the feedback loop is probably too slow.

Pay attention to which anti-patterns show up in your team. They are diagnostic. Each one tells you something specific about what is broken and where to intervene.