At the large US technology company, RFCs circulate widely. A proposal touching platform infrastructure might be read by engineering leadership, a dozen affected teams, security review, and a product counterpart — none of whom share the same technical context.

Writing for a narrow expert audience is one skill. Writing for a wide, mixed audience is a different one.

The Problem with Expert-Audience RFCs

RFCs written for a single team’s internal review typically:

  • Assume shared context (“as you know, the current auth approach has the limitations we discussed”)
  • Lead with the solution rather than the problem
  • Use jargon fluently without definition
  • Assume the reader cares about the problem without arguing for it

This works when the audience is three engineers who were in the meeting where the problem was identified. It fails when the audience includes a security team that’s reviewing the proposal cold, an engineering director who needs to sign off but doesn’t have time to re-read the entire history, or a team in another org that will be affected but wasn’t part of the original conversation.

Wide-audience RFCs need to carry their own context.

Structure That Works for Wide Audiences

The executive summary (paragraph one). A single paragraph that a reader can stop at and understand: what problem exists, what the proposal does about it, and what the stakes are. Write this last. Every section you write clarifies what belongs here.

The test: if someone reads only the first paragraph and makes a decision, would they make a reasonable one? If not, the summary isn’t doing its job.

The problem statement (explicit, not assumed). Don’t assume the reader knows the problem. Even if they were in the meeting. State the problem plainly: what is the current state, why is it inadequate, what happens if nothing changes.

The current state section should be factual and neutral. Save the argument for why it’s inadequate for the next section. Mixing “here’s what we have” and “here’s why it’s bad” in the same sentence makes both harder to evaluate.

The requirements (distinct from the solution). Before presenting the solution, state the requirements. This separates “here’s what we need to be true” from “here’s one way to make it true.” It creates space for reviewers to propose alternative solutions rather than just accepting or rejecting yours.

Requirements should be testable. “The system should be fast” is not a requirement. “The p99 latency for auth token validation should be under 5ms at 10,000 requests/second” is a requirement.

The proposal (with alternatives). Present the proposed solution with enough detail that reviewers can evaluate it, but don’t exhaust the reader with implementation detail. The implementation detail goes in the appendix for people who need it; the proposal section is for decision-makers.

Include alternatives that were considered. This is not politeness — it demonstrates that the space was explored and serves reviewers who might otherwise suggest the alternatives you already evaluated. One or two alternatives with brief explanations of why they were not chosen is usually enough.

The tradeoffs (honest, not defensive). Every solution has costs. A proposal that acknowledges no downsides is either poorly considered or hiding something, and experienced reviewers know it.

State what the proposal makes worse, what it requires, what risks it carries. Be specific: “this approach increases operational complexity because it introduces a new dependency” is more useful than “some additional complexity may be introduced.”

The open questions. Name the things you don’t know. This signals intellectual honesty and focuses review attention on where input is most needed.

The review asks (specific, per-audience). Different reviewers can provide different things. A security team can review the credential handling; a platform team can review the operational model; an affected team can confirm the migration path is viable.

State explicitly what you’re asking from each audience. “Security team: please review sections 3.2 and 3.4 for credential handling and audit log compliance.” This makes the review process tractable for readers who would otherwise have to infer what’s needed from them.

Writing for Non-Technical Stakeholders

When the audience includes non-engineers (product leadership, legal, compliance), the calibration changes further.

The technical depth in the proposal section should be minimal. Move technical detail to appendices. The main document should be readable by someone who understands the business domain but not the implementation details.

Use concrete examples instead of abstract descriptions. “The current approach requires manual intervention whenever a deployment fails, which happened 4 times last quarter and required 2 hours of engineer time per incident” lands differently than “the current approach has reliability limitations.”

Quantify impact wherever possible. “This change will reduce our infrastructure cost by approximately 15%” is more useful than “this change will reduce our infrastructure cost.”

The Pre-Circulation Review

Before circulating widely, get the RFC read by one person from each major audience segment.

The questions to ask them: “Is there anything in this document that you don’t understand, that you’d push back on, or that you expected to see and didn’t?” This surfaces gaps before they become objections in a wide review thread.

This is uncomfortable — showing an unfinished document to leadership or a peer team early feels like exposure. The alternative is finding out in a broad review thread that the executive summary is confusing to a non-technical reader, or that security has a fundamental objection that should have been surfaced earlier.

What Makes Review Tractable

Wide reviews fail when reviewers don’t know what’s being asked of them, when the document is too long to read in one sitting, or when the review comment thread becomes a design discussion rather than an approval process.

The practices that help:

  • Set a clear review deadline (2 weeks is usually right for wide circulation)
  • State the approval process (who needs to sign off for this to proceed)
  • Keep the main document under 3,000 words — appendices can be longer
  • Respond to every substantive comment, even if the response is “acknowledged, will not change because…”
  • Separate “questions” from “blocking objections” in comments, and address them differently

The goal of a wide-audience RFC is not to write a comprehensive technical document. It’s to enable a diverse group of people to make an informed decision. That’s a communication task, not a documentation task. The structure serves the decision, not the author’s understanding.

Writing well for wide audiences is slower than writing for a narrow expert audience. It requires more drafts, more pre-review, more explicit context. The investment pays off in faster approvals (reviewers can evaluate rather than interrogate), fewer surprises in implementation (concerns are surfaced before rather than during), and better decisions (more relevant input reaches the proposal while it can still be changed).