Skip to main content

Written-First Culture: Memos, Design Docs, RFCs

What This Concept Is​

A written-first culture defaults to written artifacts before live discussion. Three common shapes:

  • Memo. A narrative document explaining a situation, a proposal, or a decision. Amazon's 6-pager is the well-known form; 1-pagers are the engineering norm.
  • Design doc. A proposal for a technical approach, circulated for review, with context / proposal / alternatives / consequences. Usually 2-5 pages. Results in an ADR or a decision section.
  • RFC (Request for Comments). A structured proposal for a change affecting multiple teams or long-lived systems. Circulated widely, comment window named, status explicit.

The common thread: the author writes the best version of the argument before the first meeting, and reviewers comment in writing before anyone speaks. Meetings, when they happen, exist to resolve specific disagreements - not to rehash context.

Why It Matters Here​

Spoken-first cultures burn senior engineers' time on repeated context-setting. Written-first cultures front-load that cost once and reclaim it every time the document is read. Specific gains:

  • Alignment scales. Ten reviewers comment in parallel; a meeting of ten serializes everyone.
  • Decisions persist. The written decision survives the meeting; spoken consensus evaporates in days.
  • Junior reviewers participate. Writing gives them time; spoken fast-loops silence them.
  • Better arguments. Writing forces the author to finish the thought before defending it.

A Staff+ engineer who cannot produce a clear written proposal is operating with one hand tied.

Concrete Example​

Same proposal, two cultures:

Spoken-first. Engineer A calls a meeting titled "Let's discuss the data pipeline." 8 people attend. First 25 minutes are context-setting. Last 20 minutes are inconclusive argument. No artifact. Three follow-up meetings. One month later, the original proposal is being re-explained to a new stakeholder.

Written-first. Engineer A writes a 3-page design doc: context, proposal, two alternatives, consequences. Posts it with a 5-day comment window. 9 people comment, 40 comments total. Three specific disagreements survive. A 30-minute meeting resolves them. Decision section is written at the end of the meeting, before anyone leaves.

Same engineer, same proposal, ~4x less total time, a durable artifact, and a wider audience that heard the argument.

Common Confusion / Misconception​

"Written-first means never meeting." No. It means meetings exist for resolution, not context. A written-first culture still has meetings - they are just shorter and rarer.

"A long doc is a thorough doc." Often the opposite. A 2-page doc that a VP reads in 5 minutes beats a 10-page doc no one finishes. Length is a symptom of unclear thinking more often than thorough thinking.

"Comments are a signal of disagreement." Comments are a signal of engagement. Docs with zero comments were either not read, not circulated, or so uncontroversial that they did not need writing in the first place. Treat zero-comment docs with suspicion.

"RFC is just a fancier design doc." RFCs usually have a wider blast radius, a named comment window, an explicit status lifecycle, and a formal acceptance step. Design docs are lighter and stay inside a team or two. Both are valid; pick the weight that matches the decision.

"If I write it, the reviewers will read it." They will not, by default. Reviewers read documents that are short, well-structured, and circulated with their name explicitly tagged. An un-tagged doc in a shared channel with no named comment window reads as "optional homework" to every senior reviewer.

"The meeting is where the decision happens." In a written-first culture, the decision is drafted in the doc, pressure-tested in comments, and only ratified in the meeting. If the meeting is still doing the thinking, the doc was not ready for the meeting.

A related failure mode: the author who refuses to pre-socialize the doc with the two or three reviewers whose objections would be fatal. Surprise in the wider meeting is then guaranteed, and the author loses the chance to have pre-answered the hardest objections.

"Written-first cultures produce fewer ideas because fewer people speak up." The opposite holds in practice. Meetings are dominated by loud extroverts; written review gives the thoughtful introvert and the junior engineer parity of voice. The volume of ideas drops; the quality and breadth of contributors rises. Teams that measure participation by who spoke miss this; teams that measure it by who commented see it clearly.

"Decision section is optional if everyone leaves the meeting agreeing." False consensus evaporates in days. Anyone who missed the meeting, re-reads the doc later, or joins the team next quarter will need the decision in writing. Leaving without it is how the same decision gets re-litigated three times a year.

Length Rules That Actually Work​

Length is the most-argued and least-useful dimension of written-first culture. A few rules that reliably land the right weight:

  • If the decision is reversible in a sprint, the doc should fit on one page. The 1-pager is the right weight for tool choice, library selection, naming conventions, most refactors.
  • If the decision locks a contract for 6-12 months, the doc is 2-5 pages with named alternatives. The design-doc zone. Most feature and service-level decisions belong here.
  • If the decision affects more than one team or lasts beyond a year, escalate to an RFC with an explicit review window and a status lifecycle. Rarely should this doc exceed 10 pages; if it does, the decision is almost certainly two decisions in a trench coat.
  • If the doc is over 10 pages and unavoidable, split it. Split into a short decision doc plus one or more appendix documents that are referenced, not re-read. Reviewers will read the decision doc; they will not read the appendices unless they have a specific question.

Length is a reviewer-attention budget, not an author-completeness badge. Authors who over-invest in completeness produce docs that nobody reads, which is the worst outcome of all - invisible work that also took a week.

How To Use It​

A workable write-first loop:

  1. Author drafts to completion. Full argument, not a skeleton. Include alternatives and tradeoffs.
  2. Circulate with a named comment window. 3-5 business days is typical. Longer for RFCs.
  3. Tag reviewers explicitly. "Required: A, B. Optional: C, D." Otherwise everyone assumes someone else is reviewing.
  4. Resolve comments inline. Short answers in the doc, not in Slack threads that scroll away.
  5. Name the disagreements. If three specific disagreements remain, schedule a 30-minute meeting to resolve them. The meeting's output is a written decision section, not vibes.
  6. Archive with a decision. A doc without a decision section is not done.

Check Yourself​

  1. Name the three common written-first artifacts in this module's culture. What distinguishes them?
  2. Why is a 2-page doc read by 10 people usually better than a 10-page doc read by 2?
  3. What is a "decision section" and why must it be written before the meeting ends?

RFC Lifecycle in Practice​

RFCs differ from design docs because they have an explicit lifecycle. A serviceable lifecycle looks like:

  • Draft. The author's private draft. Not circulated. No status badge.
  • In review. Comment window open, reviewers tagged, status visible to the organization. Typical window: 1-2 weeks.
  • Final comment. 48-72 hours, no new arguments accepted, only objections to existing resolutions. Prevents late-breaking derailment.
  • Accepted. Decision section locked. Implementation begins or is scheduled.
  • Superseded / deprecated. When a later RFC replaces it, the old one is marked and the new one is linked. The record is not deleted; it is annotated.

Organizations that skip the "final comment" step repeatedly discover that a new objection lands the afternoon before implementation begins; organizations that skip the "superseded" step discover they are implementing two incompatible decisions in parallel. The lifecycle is not bureaucracy - it is how a written-first culture keeps the written record coherent.

Mini Drill or Application​

Take a decision your team made in the last 30 days that was decided verbally. Write the design doc that should have preceded it. Include:

  • Context (250 words)
  • Proposal (200 words)
  • At least two alternatives with reasons rejected (200 words)
  • Consequences, including at least one negative (150 words)
  • A decision section (50 words)

Circulate it for real comments. The goal is not the doc; the goal is the surprise of what the review surfaces that the verbal decision missed.

Extension: repeat the exercise for a decision you made that turned out wrong. Write the doc as it would have read at the moment of decision, with only the information available at the time. Did the doc's alternatives and consequences sections already contain the signal that the choice was wrong? Usually yes - which is the case for written-first culture.

Transfer / Where This Shows Up Later​

Written-first is the substrate every other influence concept stands on:

  • Stakeholder mapping (Concept 8). The stakeholder map goes at the top of the doc; comments-by-stakeholder let you see who engaged and who did not.
  • Disagree-and-commit (Concept 9). The disagreement is written in the doc's comment thread; the commit memo cites the doc by ID. Without a doc, disagreements live in Slack scrollback and die with the channel.
  • Audience-aware explanation (Concept 10). The design doc is the peer-audience artifact; it is a source from which exec-, junior-, and customer-audience artifacts are re-drafted, not summarized.
  • Exec summary (Concept 11). The exec summary is literally the first paragraph of the doc. A strong written-first culture makes writing a good exec summary a weekly exercise, not an annual crisis.
  • Architectural storytelling (Concept 12). The doc's context/proposal/alternatives/consequences sections are the six-part story in expanded form.
  • Semester 7 cross-link. S7 M5 (Architecture Decision Records) is this concept's structural twin - an ADR is a written-first artifact optimized for decisions. S8 M2-M4 all rely on written-first artifacts (service contracts, RFCs on reliability, strategy memos). Semester 10 M5 returns to written-first as the core staff+ habit.

Read This Only If Stuck​