That kind of RFC doesn’t produce decisions. It produces comment threads.

An effective RFC is not a document that describes a solution. It is a document that frames a decision — that lays out the problem, the constraints, the viable options, and the trade-offs clearly enough that reviewers can evaluate them and reach a conclusion. The solution you prefer is in there, but it’s one item in a structured argument, not the whole document.

This distinction matters because the purpose of an RFC is not to present your thinking to an audience. It is to create the conditions for a decision to be made. A document that accomplishes that purpose is structurally different from one that doesn’t.

What Makes an RFC Hard to Review

Before talking about how to write a good RFC, it’s worth naming what makes most RFCs difficult to review:

The problem isn’t clear. Reviewers can’t evaluate a proposed solution if they don’t share your understanding of the problem. If you jump to “here’s what we should build” without establishing “here’s the specific problem this solves and why it matters,” reviewers spend their cognitive load trying to infer the problem from the solution — and they often infer different problems, which produces confused or contradictory feedback.

The trade-offs are hidden. Every technical decision involves trade-offs. If your RFC presents only the chosen solution and dismisses alternatives in a sentence or two, reviewers sense that you’ve done the trade-off analysis in your head and haven’t shared it. The most common response is to force that analysis out in comments — which extends the review time and gives the impression that the trade-offs weren’t considered.

There’s no clear outcome. An RFC that ends with “What do you think?” is not driving toward a decision. It’s requesting input. Input without a decision mechanism produces more input. Clearly framing what you need from reviewers — “approve the proposed approach,” “choose between options A and B,” “raise blockers by Friday” — converts a comment thread into a decision process.

The Structure That Works

The following sections are not a template to fill in. They are a sequence of questions that, when answered well, produce a document that drives decisions.

Context and Problem Statement

What is the problem, and why does it matter now?

Write this section as if the reader has never thought about this problem before. What is the current state? What is the specific failure mode, gap, or constraint that’s motivating this proposal? Why is this worth addressing now rather than later?

The problem statement is the hardest section to write well because it requires you to separate the problem from the solution you already have in mind. Resist the urge to frame the problem in terms of the solution (“we need to replace X with Y”) and instead frame it in terms of the state you want to change (“under current conditions, we observe X, which causes Y, which costs us Z”).

One test: if someone reads your problem statement and proposes a completely different solution than the one you prefer, is that solution actually viable? If yes, your problem statement is correctly scoped. If no, you’ve probably framed the problem to match your preferred solution — which makes the document less useful and less trustworthy.

Goals and Non-Goals

What does a successful outcome look like, and what is explicitly out of scope?

Goals should be stated in terms of outcomes, not implementations. “Reduce checkout latency below 200ms at P99” is a goal. “Replace the synchronous database call with an async queue” is an implementation choice. Stating goals at the right level lets reviewers evaluate whether a proposed approach actually achieves them.

Non-goals are underused but valuable. They signal that you’ve considered scope creep and made a deliberate choice about what not to solve. “This proposal does not address multi-region failover” tells reviewers not to evaluate the document on those terms, and it signals that you’ve made a deliberate scope choice rather than missing something obvious.

Proposed Approach

What is your recommended solution?

Describe the solution in enough detail that a reviewer can evaluate whether it achieves the goals and what the trade-offs are. Include the key design decisions and why you made them. Don’t pad this section with implementation details that aren’t relevant to the decision — if someone needs to read 10 pages of implementation specifics to evaluate whether the approach is sound, the RFC is at the wrong level of abstraction.

Be explicit about what you are choosing and why. “We are using approach X instead of Y because…” is more useful than “We are using approach X.” The “because” is the substance of the trade-off analysis that reviewers need to evaluate your reasoning.

Alternatives Considered

What other viable approaches did you evaluate, and why didn’t you choose them?

This is the section most commonly written poorly — either skipped, or filled with strawman alternatives that were never serious options. Both approaches undermine the RFC’s credibility.

A well-written alternatives section requires genuine engagement with the alternatives. For each alternative: what is it, what are its genuine advantages over the proposed approach, and what specifically makes you prefer the proposed approach over it?

Reviewers who would have chosen differently often do so because they weight the trade-offs differently, not because they identified an alternative you didn’t consider. Showing that you considered the same alternatives with a specific rationale for your preference converts a challenge (“why didn’t you do X?”) into a discussion (“you preferred X for reasons A and B; I would have weighted B more heavily because…”).

Risks and Open Questions

What are the known risks, and what is still uncertain?

A good RFC doesn’t pretend to have all the answers. It distinguishes between what is decided (the recommended approach) and what is open (implementation questions, dependencies, risks that need mitigation). Listing open questions with owners and resolution paths shows reviewers that you’re not sweeping uncertainty under the rug.

Risks worth naming: performance at scale you haven’t tested, dependency on another team’s work, backwards compatibility concerns, operational overhead, security surface expansion. Name the risk and your proposed mitigation or monitoring approach.

Success Criteria

How will you know if this worked?

State how you will evaluate success after implementation. Quantitative metrics are preferred: latency targets, error rate thresholds, adoption metrics. Qualitative criteria are acceptable for decisions whose impact is harder to measure, but be specific about what “success” looks like. “Teams adopt the new pattern” is not a success criterion. “5 of 8 product teams have migrated to the new pattern within two quarters” is.

Getting Reviews That Converge

An RFC with clear structure still fails if the review process doesn’t drive toward a decision. A few practices that help:

Set a review deadline. “Comments open through [date]” converts an open-ended process into a bounded one. Reviewers are more likely to engage by a deadline, and you can move to a decision without waiting indefinitely for comments that may never come.

Name the decision-maker. Who has final approval? Is it the tech lead of the impacted team, the engineering manager, the architect? If this isn’t clear, approval is ambiguous and the RFC can remain “under review” indefinitely. State explicitly who makes the call.

Distinguish blocking concerns from non-blocking feedback. Ask reviewers to flag blocking concerns explicitly. This separates “I have concerns that need to be resolved before this proceeds” from “I have suggestions that would improve this.” The first category requires action before the decision; the second can be addressed in implementation.

Close the RFC explicitly. When you have the decision, document it. Update the RFC with the outcome: “Approved — proceeding with Option A. Options B and C rejected for reasons stated in comments from [reviewer].” An RFC without a recorded outcome is a discussion that never ended.

RFC as a Career Signal

At senior level and below, your code is the primary evidence of your technical judgment. At staff level and above, your written reasoning — in RFCs, design documents, and architectural proposals — is what scales your influence beyond the rooms you’re in.

An RFC that frames a decision clearly, engages honestly with trade-offs, and produces an outcome is evidence of operating at the staff level: it demonstrates breadth (understanding the full context), judgment (making defensible trade-off calls), and influence (getting to a decision without authority to mandate it).

An RFC that gets stuck in comment threads, requires repeated clarification, or produces no decision is a missed opportunity — and a signal that the skill needs development. The good news is that it’s a learnable skill. Each RFC you write teaches you something about what your reviewers need to see to converge.

VividMap helps you log impact evidence from your technical leadership work — including RFCs you’ve driven, design documents you’ve written, and decisions you’ve shaped. See how it works.