Writing That Moves Orgs

Most technical writing in engineering organizations does not move anything. It documents what already happened, or it covers the author in the event of a postmortem, or it satisfies a process checkbox. Docs get written, reviewed perfunctorily, and filed away.

The staff engineers who have real organizational influence write differently. Their documents create alignment before work starts, surface tradeoffs that would otherwise be discovered painfully in production, and establish technical direction that outlasts any single project. The writing is the work, not the record of the work.

Why Writing Is Your Primary Leverage Tool

In-person influence has a ceiling. You can only be in so many meetings, have so many 1:1s, join so many syncs. Written influence scales. A well-constructed RFC can align a dozen engineers across three teams before a single line of code is written. A technical strategy memo can shift quarterly roadmap priorities. A short decision record can prevent the same argument from happening four times in two years.

This is not about becoming a "good writer" in the literary sense. It is about recognizing that writing is the medium through which staff-level work propagates through an organization, and treating it with the same craft you bring to a complex system design.

The Document Types That Matter

Not all technical documents serve the same purpose. Conflating them produces documents that are neither one thing nor another.

The RFC and the strategy memo are the two documents staff engineers write most and write worst. They require different shapes.

The RFC That Gets Read

Most RFCs fail at the opening. They start with background and context — pages of it — before saying anything about what the author actually wants the reader to think or do. By paragraph three, half the readers have skipped to the end.

The structure that works:

## Problem
One paragraph. What is broken, missing, or inadequate today?
Quantify if possible. Name the pain concretely.
 
## Constraints
What is fixed? (timeline, budget, team size, existing contracts)
What is flexible? Be explicit — most RFCs hide this.
 
## Options Considered
2–3 options. For each: what it is, key tradeoffs, why you might or might not choose it.
Do not strawman the alternatives you rejected.
 
## Recommendation
What you recommend and the one or two reasons that make it the right call
given the constraints. This is not the place for hedging.
 
## Open Questions
What do you genuinely not know yet? What feedback do you need?
Unanswered questions you are not surfacing are landmines.
 
## Appendix
Supporting data, benchmarks, diagrams. Everything that matters but
would interrupt the flow of the main doc.

The opening must answer: why does this matter, and why now? Engineers will decide in the first thirty seconds whether to read the rest.

The Strategy Memo

Strategy memos are rarer and more powerful. They answer the question: "Where should we go and why?" They are written when there is genuine ambiguity at the leadership level about direction, and when someone needs to make the case for a particular path.

The structure that works is borrowed from consulting — situation, complication, question, answer (SCQA):

## Situation
What is true today that everyone agrees on?
(Our data infrastructure serves 200 internal teams. Ingestion latency
is p95 at 4 seconds. We have three separate pipeline systems with
overlapping functionality.)
 
## Complication
What has changed, or what tension exists, that makes the status quo
insufficient?
(We are onboarding 40 new teams in Q2. Current systems will not scale
without 3x the operational load. The three systems have diverged enough
that shared tooling is no longer viable.)
 
## Question
The single question this memo answers.
(Should we consolidate onto one pipeline system before Q2 onboarding,
or scale each system independently?)
 
## Answer
Your recommendation, stated directly in the first sentence.
Then: the reasoning, the evidence, the implications.
(We should consolidate onto the event-streaming pipeline.
Here is why...)

The mistake most engineers make is writing the answer last, as if they are proving it to a skeptical reader. State the answer first. Let the reader evaluate the reasoning knowing where you land.

Formatting for Skimmers

Organizational writing is read by skimmers who become readers only if the skim succeeds. Design for the skim.

• Bold the claim in each paragraph, not decoration or emphasis.
• Use headers that are declarative sentences, not category labels. "We Should Deprecate the Legacy API" is a better header than "Legacy API."
• Summaries at the top. TL;DRs are not lazy — they are efficient. Put a three-bullet summary before the body for any document over a page.
• One idea per paragraph. If a paragraph makes two claims, split it.
• Tables beat prose for comparisons. Prose beats tables for reasoning.

Getting Your Doc Read and Acted On

Writing the document is half the work. The other half is distribution and follow-through.

The loop that kills documents: you publish, get five comments, respond to three of them, then move on and hope consensus happened. It did not. Explicitly close the loop — announce when the review period ends, state what decision was made, and record why.

Key Takeaways

• Writing is the primary medium through which staff-level influence propagates — treat it with the same craft as system design.
• Different document types serve different goals; conflating them produces documents that are neither one thing nor another.
• RFCs must lead with the problem and state the recommendation directly — readers decide in thirty seconds whether to engage.
• Strategy memos work best in SCQA format: situation, complication, question, answer — with the answer stated first.
• Format for skimmers: declarative headers, bold claims, summaries at the top, one idea per paragraph.
• Getting a doc acted on requires active distribution, ally pre-reads, and an explicit close-the-loop process after the review window.