Writing RFCs That Actually Get Read

Most internal RFCs fail before anyone reads past the summary. The problem is not that engineers dislike writing — it is that RFCs are optimized for the author's need to think out loud, not the reviewer's need to decide quickly. We changed two things on a 22-person platform team: a fixed document skeleton and a 48-hour async comment window with an explicit decision gate. Adoption of the resulting designs went from "implemented anyway after the meeting" to "referenced in PR descriptions six months later."

The format that actually gets skimmed

We stopped calling them RFCs internally and started calling them decision memos. Same artifact, different expectation: the first screen must answer four questions without scrolling.

1. What are we deciding? One sentence. Not "explore options for caching" — "Adopt Redis Cluster for session state by Q3."
2. What happens if we do nothing? Quantify if possible. "P99 checkout latency stays at 800 ms; we miss the holiday SLA."
3. What are the two real options? Not seven. If you have seven, you have not framed the decision.
4. What do you recommend and what would change your mind?

Everything else — background, alternatives rejected, migration plan — goes below a ## Details fold. Reviewers who agree with the recommendation never open it. Reviewers who disagree know exactly where to aim comments.

We enforce this with a Notion template (works fine in Confluence or a git-backed docs/decisions/ folder too). The template has hard character limits in the section headers as reminders: summary ≤ 400 characters, recommendation ≤ 200.

The 48-hour async window

The forcing function was a calendar rule: no synchronous design review until 48 hours after the memo is posted in #eng-decisions (Slack) with @channel and linked stakeholders tagged individually.

During those 48 hours:

• Comments must be inline on the doc, not side threads in Slack. Slack is for "I left a comment on section 3" — not the debate itself.
• The author cannot edit the recommendation after posting. They can add a changelog section at the bottom for typos and clarifications. Changing the recommendation resets the clock.
• Silence after 48 hours counts as lazy approval, not consent. The memo template includes a checkbox: "I have read this and have no objections" that named approvers must click. We track who has not clicked.

After 48 hours, a 30-minute sync happens only if there are unresolved [BLOCKING] tags in comments. Non-blocking feedback is the author's problem to incorporate or explicitly defer.

This killed the meeting where six people hear a design for the first time and the loudest person wins.

What we measured

Over two quarters (Q1–Q2 2025), we tracked 31 decision memos on a team that ships ~40 meaningful architectural changes per quarter.

Metric	Before format + window	After
Median time from draft to decision	11 days	4 days
Memos with zero inline comments	38%	9%
Design docs referenced in PRs 90+ days later	2 of 19	11 of 14
"We already decided this" re-litigation incidents	4	0

The re-litigation number is the one I care about. That is wasted senior engineer time.

Common failure modes we still hit

Kitchen-sink memos. Someone posts a 40-page doc "for context." We send it back. Context belongs in an appendix or a linked spike branch — not in the decision path.

Fake options. "We could rewrite in Rust" when nobody will fund it. Reviewers stop trusting the author. We require each option to name an owner who would execute it and a rough eng-week estimate.

Missing rollback. For anything touching production data paths, the template requires a ## Rollback section: what flag, what revert commit, what data migration undo. Skipping this was an automatic [BLOCKING] from our SRE liaison.

Stakeholder theater. Legal, security, and infra each get one tagged section: "Impact on you: yes/no + one paragraph." Not a separate 20-page review doc.

Tools and versions

We run Notion 3.x for memos, GitHub for implementation, and ADRs (Architecture Decision Records) in docs/adr/ only after the decision memo is approved — the ADR is the tombstone, not the debate venue. Mermaid diagrams embed fine in Notion; for git-native teams, the same template works as Markdown.

For teams on Google Docs, the 48-hour rule still works. The inline-comment discipline is harder — we had to ban "suggested edits" mode because it bypasses the discussion thread.

What I'd do next

I would add a decision registry queryable by tag (caching, auth, data-model) so new hires can find "why we use JWT + opaque refresh tokens" without archaeology. Right now search works but only if you know the vocabulary.

I would also tighten the lazy-approval rule: after 48 hours, non-responders get a bot DM with the one-sentence recommendation and a link. Two ignored DMs and their approval is recorded as "deferred — not consulted" rather than assumed yes. That sounds harsh; it stopped us from discovering three months later that security never saw the memo.

If you are designing incident authority and escalation paths, the same "decide before the meeting" discipline shows up in incident response runbooks. Hiring decisions have a parallel tradeoff frame in hiring ICs vs managers.