# Building a Writing Culture in Engineering Teams

Source: https://www.techinterview.org/post/3233475147/building-writing-culture-engineering-teams/
Updated: 2026-07-12 · techinterview.org

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.