Companies with strong engineering writing cultures (Stripe, Amazon, Anthropic, Stripe again) consistently outperform peers on technical decision-making, onboarding, and asynchronous coordination. Companies without it suffer from re-litigated decisions, status-meeting overload, and lost institutional memory. As an EM, your highest-leverage cultural intervention may be making writing a non-negotiable.
Why writing matters
- Forces clear thinking: most “this needs more discussion” actually means “we have not thought it through”
- Enables async collaboration across time zones
- Creates institutional memory, so new engineers can read instead of asking
- Documents decisions and rationale for future-you
- Levels the playing field, so quiet strong engineers can contribute equally
What to write
Design docs (RFC, Tech Spec)
Before any non-trivial implementation:
- Problem statement
- Constraints and requirements
- Proposed solution
- Alternatives considered
- Risks and unknowns
- Cost estimates
Length: 5–15 pages typically. Reviewed async via comments.
Post-mortems
After every Sev 1 / Sev 2 incident:
- Timeline of events
- Root cause
- Contributing factors
- Action items with owners and dates
Weekly status updates
Per-team async update:
- Shipped this week
- Shipping next week
- Blockers
- Highlights and concerns
1-page proposals
For decisions short of full design docs:
- Recommendation
- Rationale
- Alternatives
- Specific ask
Establishing the practice
Cultural change is slow. Tactics:
- Lead by example: write your own design docs and weekly updates
- Reward writing in calibration: name strong writers explicitly
- Set expectations: “no significant project starts without a design doc”
- Provide templates so engineers do not have to reinvent the structure
Common resistance
- “I prefer to talk about it”: talking is a complement to writing, not a replacement
- “Writing slows me down”: writing surfaces problems before code does, saving time net
- “My English is not good enough”: focus on clarity, not eloquence; native speakers are not necessarily better writers
- “No one will read it”: make it part of approval gates so reading is enforced
Templates that work
Stripe-style design doc template:
- Summary (one paragraph)
- Background and motivation
- Current state
- Proposed change
- API / interface (if applicable)
- Tradeoffs and alternatives
- Migration plan
- Risks
- FAQ
Amazon-style PR/FAQ for product decisions:
- Press release describing the launched feature
- FAQ from internal teams
- FAQ from customers
Async review process
For documents that need broad input:
- Author writes
- Shares with reviewers + open Slack channel
- 3–5 days for async comments
- Author responds inline; resolves threads as addressed
- Optional: live meeting only if there is genuine disagreement
- Decision recorded in the doc
This pattern beats meeting-driven decisions on speed and quality.
The “silent meeting” pattern
Stripe and Amazon use the silent-meeting pattern: doc is read in the first 10 minutes silently. Then discussion. Eliminates “did you read it?” energy.
Storage and findability
Documents need a home. Common patterns:
- Internal wiki (Confluence, Notion, Coda)
- Versioned in a Git repo for design docs
- Searchable; tagged by team, status (draft/active/decided), and date
If documents are buried, no one reads them. Findability matters as much as quality.
The interview probe
“How do you build a writing culture?”
Strong answers describe specific practices, templates, and the cultural changes you led. Vague “I encourage writing” is shallow.
Frequently Asked Questions
Should every project have a design doc?
Set a threshold: any project >1 week of effort or affecting multiple teams. Smaller work can be a Slack message or PR description.
What about juniors who struggle with writing?
Pair them with a senior on the first 2–3 docs. Provide concrete feedback. The skill is teachable.
How do you balance writing with shipping?
Writing is shipping. The doc is a deliverable. Often it saves more time than it costs.
Practice the behavioral round:
