How to Write a Technical RFC That People Actually Read

The RFC — Request for Comments — is one of the most powerful tools in an engineering team’s process toolkit. It’s also one of the most abused. When RFCs are long, unstructured, and written to demonstrate thoroughness rather than facilitate decisions, they become a form of process theater that slows engineering down rather than guiding it.

The Problem With Most RFCs

They’re too long. They describe the solution in exhaustive detail before establishing why the problem matters. They don’t make the recommended decision clear. And they don’t give reviewers a clear ask: do you want feedback, approval, or just visibility?

The Format That Works

Context (2 paragraphs): What’s the problem and why does it matter now? Decision (1 paragraph): What are we proposing? Alternatives considered (1 paragraph each): What else did we think about and why did we reject it? Open questions (bulleted list): What are we still unsure about? The author’s recommendation should be explicit and at the top, not buried at the end after fifteen sections of context.

The Review Process

Set a deadline. Specify who needs to approve vs. who is being kept informed. Time-box the review to one week maximum. After one week, the author closes the RFC with a decision — approved, rejected, or revised. Endless review cycles where nothing gets decided are worse than no RFC process at all.