The hardest part of an RFC isn't writing the proposal. It's writing the questions.
Most RFCs end with something like "Open Questions: 1. What do you think of this approach? 2. Any concerns?" Those aren't questions. They're exit ramps — carefully paved routes to "looks good" that let a reviewer feel like they engaged without engaging. Nobody is going to volunteer that your proposal rests on a fatal assumption when the ask is that vague. You designed the questions to be ignored, and they will be.
Good questions are uncomfortable. They name the thing you're least sure about and ask someone to stress-test it. They make a lazy "LGTM" feel obviously, visibly inadequate.
Here's the method for writing them.
Start with assumptions, not topics
Most people write questions about sections of their RFC. They have a section about the data model, so they write a question about the data model. That's backwards.
Instead, start by listing every load-bearing assumption in your proposal. An assumption is load-bearing if the proposal fails or changes materially when it turns out to be false.
These come in a few flavors:
- Problem assumptions: The problem exists, it's big enough to justify the change, it affects who you think it affects.
- Solution assumptions: Your approach actually fixes the problem. The side effects are tolerable. The migration path works.
- Ecosystem assumptions: Other teams will adapt. The upstream API won't change. The library can handle the load.
- Silent assumptions: Things stated as fact with no evidence. Alternatives dismissed in one sentence. These are the most dangerous because they don't look like assumptions — they look like context.
Write them all down. Then rank by blast radius: if this assumption is wrong, how badly does the proposal break?
Split data from opinion
Not every assumption needs a reviewer's input. Some are answerable by querying logs, running a benchmark, or reading the docs.
"Our p99 latency will stay under 200ms" — that's a data question. Run the test. Don't ask a stakeholder to guess.
"The platform team can absorb the operational overhead of a new service" — that's a stakeholder question. Only they know their capacity and priorities.
Some assumptions are hybrid. Data gives you a floor, stakeholders give you the ceiling. "We expect 50K events per day" might be verifiable from logs, but "can your pipeline handle 50K events per day of a new event type" requires someone from the data team to actually think about it.
Strip out the data questions. Those are tasks for you, the RFC author, to validate before you circulate. Every assumption you can resolve with data is one less question cluttering the review — and one less thing that makes reviewers feel like you didn't do your homework.
Map assumptions to people
For every remaining assumption, ask: who actually knows the answer?
Not "the team." A specific role. The SRE who runs the deployment pipeline. The PM who owns the customer relationship. The downstream engineer who'll have to integrate with your new API.
If nobody can answer it, it's not a question — it's a research task. Cut it.
If everyone can answer it equally well, it doesn't need an audience label. Most questions should be answerable by any reviewer. Only tag an audience when the question is genuinely unanswerable without that specific perspective.
Write questions that resist "LGTM"
This is where most people stop too early. You have your assumptions, you've filtered out the data tasks, you know who to ask. Now you need to write questions that are hard to dismiss.
Here are the rules:
One question per assumption. Compound questions get half-answered. "Should we use Postgres, and if so, is the schema in section 3 right?" is two questions pretending to be one.
Under 25 words for the question itself. If you need more, add a line of context — but keep the question itself short enough to answer in your head before you finish reading it.
Ask about current state, not predicted feelings. "How do you handle schema conflicts today?" gets a real answer. "Would schema conflicts bother you?" gets "probably not" from someone who hasn't thought about it.
Include your proposed default. "We're planning to reject on hash collision. Does that break anything for you?" is better than "How should we handle hash collisions?" The first invites pushback. The second invites a design session.
Try to falsify, not confirm. If "no" is a comfortable answer, flip it. "What's the last time a migration of this size finished on schedule?" is harder to brush off than "Are you comfortable with the timeline?"
State what it gates. "This determines whether we build one service or two" tells the reviewer their answer matters. Without it, every question feels like a nice-to-have.
Budget ruthlessly
Hard cap of 8 questions. Target 3 to 5. You'll be tempted to ask more. Don't.
If you have 12 assumptions, cut by blast radius. Keep the ones whose worst-case answer kills the proposal. A question about color-coding the dashboard can wait. A question about whether the downstream team can actually consume your new event format cannot.
Fewer questions means each one gets a real answer. Ten questions means none of them do.
An example
Bad RFC questions:
- What do you think of this approach?
- Any concerns about the timeline?
- Does the API design look right?
Better:
For the payments team: We're adding a 500ms sync call to the checkout flow. What's your current p95, and how much headroom do you have? Gates: whether we go sync or async for payment verification.
We're assuming the legacy events can be backfilled from the warehouse. Has anyone tried a backfill of this size before, and what broke? Gates: whether we need a migration tool or can use the existing pipeline.
The RFC dismisses option B (separate service) as too much operational overhead. We currently run 4 services. Is a 5th actually a problem, or is the overhead already amortized? Gates: build-vs-extend decision in phase 1.
The second set is harder to ignore. Each question names a specific assumption, makes the stakes clear, and asks for something concrete. Answering "LGTM" to question 1 isn't lazy — it's conspicuous.
The questions are the review
A good template gets the proposal written. The questions are what get it reviewed. Every public RFC process we've studied — Rust, Go, React, and the rest — does the writing part well and the feedback part badly, and the gap is exactly this: the author's real uncertainties never get put to reviewers as direct, answerable asks.
So before you hit share on your next RFC, delete "Any concerns?" and do the twenty minutes of work: list the assumptions that would kill the proposal, cut the ones you can verify yourself, and turn what's left into questions that name the risk out loud. You'll get fewer responses than you got thumbs-up emoji on the last one — and every one of them will matter.