Writing That Changes Decisions — The Staff Engineer Track — Scope, Influence, Strategy and Judgment

Ask a group of senior engineers what separates the staff engineers they admire, and “they write incredibly well” comes up every time. Not “they write beautifully”, but “when they write something, things happen”: teams align, a bad plan gets stopped, a decision gets made. Writing is the single most leveraged skill on the staff IC path, because a document is the only thing you make that scales to people you’ll never meet and persists after you’ve left the room. A great idea you can only explain in person reaches a dozen people once. The same idea written well reaches hundreds, repeatedly, for years. This lesson is how to write like that.

Why Writing Is the Staff Skill

A meeting aligns the people in the room, for an hour, and then memory fades and the decision drifts. A document aligns everyone who reads it, forever, and can be debated, improved and referred back to. For a staff engineer who leads through influence rather than authority (Lesson 7), writing is the primary tool: it’s how your strategy (Lesson 3) travels, how your decisions get recorded (Lesson 5), how cross-team projects stay coordinated (Lesson 6). If you want to operate at staff level and you’re not writing regularly, that’s the first thing to change.

Writing is also a thinking tool. The discipline of putting an argument on paper exposes the gaps you can hand-wave past when talking. Many times I’ve started writing a design doc convinced of an approach, and discovered while writing the “alternatives” section that a rejected option was actually better. The doc didn’t just communicate my thinking; it improved it. Writing is thinking made visible, and visible thinking is easier to fix.

Anatomy of a Design Doc That Gets Approved

The most common staff document is the design doc (also called an RFC or technical spec). A good one has a structure that forces clear thinking and makes a reviewer’s job easy:

Walking the sections:

Context & problem: what’s broken or needed, and why now. One paragraph that a VP could follow without being technical. If a reader doesn’t understand the problem, nothing else lands.
Goals & non-goals: what success looks like, and explicitly what you’re not trying to solve. The non-goals are quietly powerful, they’re how you stop a design (and a reviewer’s feedback) from sprawling into everything.
Proposed approach: the actual design, with a diagram. Enough detail to build it; not every line of code. A diagram here is worth a thousand words of prose.
Alternatives considered: two or three real options you weighed and why you rejected them. This section earns more trust than any other, it proves you thought broadly, and it answers the reviewer’s inevitable “but why not X?” before they ask.
Trade-offs & risks: what you’re giving up with your choice, what could go wrong, and how you’ll know. Every real design gives something up; naming it shows maturity.
Rollout & migration: how it ships safely, how old and new coexist, how you roll back. A design that can’t be rolled out safely isn’t done.
Open questions: what you’re genuinely unsure about. Counterintuitively, naming your doubts makes the doc stronger: it signals honesty and tells reviewers exactly where their input is most valuable.

The counterintuitive trick: write the hard parts first

Most people write a design doc top to bottom: context, goals, then lovingly detail their chosen approach, and finally, tired, dash off a thin “alternatives” section. That’s backwards. Write the alternatives and trade-offs first, before you commit to the approach. The reason is simple: if you can’t clearly articulate the options you’re rejecting and why, you haven’t actually thought hard enough to know your chosen approach is right. Forcing yourself to argue the alternatives first either confirms your choice or changes it, and either way the doc gets better. The approach section almost writes itself once you’ve genuinely wrestled with what you’re not doing.

Write for the Reader, Not for Yourself

A design doc that’s perfect for an engineer is often useless to a VP, and vice versa. The same idea has to be pitched to the reader who’s actually deciding:

Before you write, ask: who’s reading this, and what decision do they need to make?

Engineers care about the how: the design, the trade-offs, the failure modes, the migration. Give them detail and rigour, they’ll be building it.
Managers and peer leads care about the what and the cost: scope, risk, timeline, who’s affected, and what you need from them. Give them a clear ask.
Directors and VPs care about the why and the bet: the business impact, the one decision that’s needed, and the cost of not doing it. Give them the conclusion immediately.

A wall of technical detail sent to a VP fails (they won’t read it and can’t act on it). A one-line summary sent to the engineers who must build it also fails (they can’t build from it). Match the document, or the section, to the reader’s altitude (Lesson 2). For a doc with mixed readers, a common pattern is a crisp executive summary at the top for the leaders, then the technical depth below for the builders.

BLUF: Bottom Line Up Front

The single most useful writing habit for busy readers: put your conclusion at the top. BLUF, “bottom line up front”, comes from the military, where people genuinely don’t have time to read to the end. Your recommendation, your ask, the decision you need, goes in the first few lines, not buried in a “conclusion” section after ten pages the reader won’t reach.

This feels wrong to engineers, we’re trained to build an argument step by step and reveal the answer at the end, like a proof. But a reader deciding whether to even keep reading needs to know the point first, then the supporting detail. Lead with “I recommend we build X; it costs Y; I need a decision on Z by Friday”, then explain. The people who need the detail will read on; the people who just needed the answer already have it. A good test: if someone read only your first paragraph, would they know what you’re proposing and what you need from them? If not, rewrite the top.

A Reusable Design-Doc Template

Here’s a template you can copy for your next design doc. Delete what doesn’t apply; keep the shape.

# [Title]: one line that states the decision or change

**Author:** you · **Status:** Draft / In Review / Approved · **Date:** ...
**Reviewers:** names · **Decision needed by:** date

## Summary (BLUF)
2-4 sentences: what you propose, the key trade-off, and the one decision
or approval you need. A busy reader should get the point from this alone.

## Context & problem
What is broken or needed, and why now. One paragraph a non-expert could follow.
What happens if we do nothing?

## Goals
- Measurable outcomes that define success.
## Non-goals
- What this explicitly does NOT try to solve (prevents scope creep).

## Proposed approach
The design, with a diagram. Enough to build; not every line of code.

## Alternatives considered
- **Option A:** ... — rejected because ...
- **Option B:** ... — rejected because ...
(Write this section FIRST. If you can't argue these, you're not done thinking.)

## Trade-offs & risks
- What we give up with the chosen approach.
- Top risks, each with a mitigation and how we'll detect it.

## Rollout & migration
How it ships safely, how old and new coexist, how we roll back.
How we measure success in production.

## Open questions
- The things you're genuinely unsure about and want input on.

Keep it as short as the problem allows. A two-page doc that gets read beats a twenty-page one that doesn’t. And circulate it as a draft, inviting comments, a doc people shaped is a doc people support.

Pitfalls to Avoid

Relying on meetings instead of writing. Meetings align a room for an hour; docs align everyone, forever.
Writing the approach lovingly and the alternatives thinly. Write the hard parts first; weak alternatives mean weak thinking.
Burying the conclusion. Lead with the bottom line and the ask (BLUF); don’t make readers dig for it.
One doc for all readers at one altitude. Match the depth to who’s deciding; add an exec summary for mixed audiences.
Hiding your doubts. Naming open questions makes a doc stronger and tells reviewers where to help.
Writing to look smart. Write to be understood and to get a decision; clarity beats cleverness.
A twenty-page doc nobody reads. Shorter and read beats longer and ignored.

Quick Recap

Writing is the staff engineer’s highest-leverage skill: it scales your thinking beyond the room and persists.
A good design doc has a clear structure; write the alternatives and trade-offs FIRST, as a test of your own thinking.
Write for the actual reader: engineers want the how, managers the what/cost, executives the why and the one decision.
Use BLUF, put your conclusion and ask at the top, not in a conclusion section.
Name your open questions; it strengthens the doc. Keep it short, and circulate it as a draft to invite ownership.

Next lesson: how to make the decisions those docs are about, reversible vs irreversible choices, trade-off matrices, and recording decisions so they stick.