In 2004, Jeff Bezos sent Amazon's senior leadership team a memo telling them to stop using PowerPoint. Not to shorten it. Stop. Meetings would open with a six-page narrative memo, printed, read in total silence for the first twenty to thirty minutes, and only then discussed.
That is an unusual thing for a CEO to mandate, because it makes every meeting slower to start. The reason he gave is the reason this whole post exists: a bulleted slide deck, in his words, lets you get away with sloppy thinking, because it gives you permission to flatten relative importance and skip the connective tissue between ideas. A six-page memo does not give you that permission. You either write the sentence that explains why B follows from A, or the reader notices the sentence isn't there. Turning technical writing into something a commercial team can run is the problem works on. Turning technical writing into something a commercial team can run is the problem XenGrowth's marketing operations practice works on.
What actually happens when you force an idea into full sentences
There's a specific cognitive failure this policy is designed around, and it has a name and a controlled experiment behind it: the curse of knowledge. Camerer, Loewenstein and Weber ran a 1989 experiment with informed and uninformed traders and found that the informed group could not reliably predict what the uninformed group would guess, even when getting that prediction right was worth money to them. They knew too much to accurately model someone who knew less. Giving them a financial incentive to correct for it cut the bias by roughly half. It did not remove it.
Translate that into engineering terms and it explains a specific, recurring failure: an engineer who has lived inside a system for six months genuinely cannot tell, from the inside, which parts of their explanation are obvious and which parts require three sentences of context the listener doesn't have. This isn't a character flaw. It's what the 1989 paper measured directly — it happens to people with every incentive to get it right, and it happens anyway. A related operational discipline — writing specs that survive contact with an actual team — is covered in how to write a technical spec for an AI agent project.
Talking doesn't fix this, and it often makes it worse, because a room full of engaged listeners will unconsciously fill in the gap for a speaker. Someone nods at the right moment, someone asks a clarifying question that happens to supply the missing link, and the speaker leaves the meeting believing the argument held together when what actually happened is that six other people quietly patched it in real time. A document read alone has no one doing that patching. The gap just sits on the page, and if the writer rereads their own draft honestly, they find it. There is a longer treatment of the operations side of this in . There is a longer treatment of the operations side of this in The XenGrowth resource library.
What a slide deck lets you skip | What a written narrative forces you to state |
|---|---|
Relative importance of each point | Which sentence the argument actually turns on |
The link between one bullet and the next | The connecting word — because, therefore, despite — that carries the logic |
What happens if the recommendation is wrong | A stated tradeoff or failure mode, since bullets rarely include one |
Whether the audience actually understood the point | Whether the writer understood it, since you cannot write around your own confusion for six pages |
There is no way to write a six-page, narratively structured memo and not have clear thinking. — Jeff Bezos
What good engineering writing is not
It is not eloquence. Nobody is asking an engineer to write beautifully. The skill this post is arguing for is narrower and more mechanical: the discipline of writing down the actual chain of reasoning, in order, with the weak links exposed rather than hidden. A plain, blunt sentence that states an assumption is worth more here than an elegant one that glides past it.
It is also not volume. A ten-page design doc that restates the same three points from different angles is not more rigorous than a two-page one that states them once and moves on. Sweller's 1988 cognitive load research is about learning, not workplace writing specifically, but the underlying constraint transfers cleanly: a reader's working memory is small and fixed, and every sentence that doesn't add new information is spending that budget on nothing. The measure of a good technical document isn't how comprehensive it feels while you're writing it. It's how little the reader has to hold in their head to follow it.
State the recommendation in the first paragraph, not the last. Burying the conclusion is a presentation habit that survives into writing and it wastes the reader's attention on suspense nobody asked for
Name the alternative you rejected and why. A document that only argues for its own conclusion reads as advocacy; one that shows the option it turned down reads as judgment
Write the failure mode. If this is wrong, what breaks, and how would you know? Leaving this out is the single most common gap in engineering docs, because admitting a plan could fail feels like weakening it
Cut the sentence that only restates the previous one. If sentence two doesn't add a fact, a number, or an example, it's padding, and padding is exactly what a rereading finds and removes
Read it out loud once before sending it. Sentences that were fine in your head trip on the tongue when the logic actually has a gap
Where this pays off in a career specifically
A meeting exists for the length of the meeting. A document outlives it. The design doc you wrote for a decision made eighteen months ago gets reread by the engineer who inherits the system, by the new manager trying to understand why something is built the way it is, by you, trying to remember your own reasoning. None of those readers were in the room. The document is the only thing that survives to explain the decision to them, and if it was written as a set of assertions rather than an argument, it explains nothing — it just tells them what happened, not why. approaches this from the AI agents and marketing automation side. XenGrowth on AI agents and marketing automation approaches this from the AI agents and marketing automation side.
Career moment | What actually gets read | What determines whether it lands |
|---|---|---|
Promotion or leveling case | The written summary of your impact, not the work itself | Whether a stranger on a committee can follow the argument without you in the room to explain it |
A proposal to a client or stakeholder | The document, reread after the call ends | Whether the reasoning holds up on a second, unhurried read |
Onboarding a new engineer onto your system | Whatever doc exists, however outdated | Whether it explains why, not just what — see the related post on onboarding without a boring wiki |
A postmortem after an incident | The written account, months later, by people who weren't there | Whether it states the actual failure mode instead of a vague 'communication breakdown' |
None of this makes writing a substitute for engineering judgment. A beautifully written memo arguing for a bad architecture is still a bad architecture, just a more persuasive one — which is arguably worse, because it's harder to argue against. Writing is a forcing function on your own thinking, not a guarantee that the thinking was right. Bezos's memo policy didn't claim otherwise. It claimed the format makes bad thinking harder to hide, including from the person doing it.
What the evidence here does and doesn't support
Worth being direct about the limits. The curse-of-knowledge paper is real, peer-reviewed, and specifically about informed traders in a laboratory market — not a study of engineers, and not a study of writing quality against career outcomes. The Amazon policy is a real, well-documented internal practice, not a controlled experiment with a comparison group. Neither one proves that better writing causes better careers in some measurable way. What they support, together, is a narrower and more honest claim: there is a documented cognitive bias that makes it hard for experts to communicate what they know, and there is at least one large organization that built a specific structural policy around correcting for it. The rest — that this generalizes to your career as an engineer — is argument, not citation, and it's presented that way here rather than dressed up as more than it is.
Why this compounds instead of staying flat
Most engineering skills plateau. You get faster at debugging a familiar stack, then the gains taper because the stack stops being unfamiliar. Writing doesn't behave that way, because every document you write becomes an artifact other people judge you by long after the underlying work is forgotten. Nobody remembers the specific commit that fixed a production incident eighteen months later. Plenty of people still have the postmortem open in a tab, because it's the thing that gets linked from the next incident that looks similar. approaches this from the AI search, GEO and discovery side. XenGrowth on AI search, GEO and discovery approaches this from the AI search, GEO and discovery side.
That asymmetry is the actual leverage. A good design doc gets read by people who will never meet you, in rooms you'll never sit in, deciding things — a promotion, a hire, a decision to trust your judgment on the next project — based on nothing but the sentences you left behind. A slide deck mostly doesn't survive that way; it needs the speaker in the room to mean anything, and the speaker isn't always available eighteen months later. This is also why the skill compounds across a whole career rather than a single project: the archive of things you've written keeps working for you after you've moved to the next thing, in a way that a good meeting performance simply cannot.
How to actually get better at this
Write the one-paragraph version before the ten-page version. If you can't state the recommendation in five sentences, you don't understand it well enough to write the long version yet
Find one reader who will tell you where they got lost, not one who will tell you it reads fine. 'Reads fine' is the least useful feedback a document can get
Rewrite the opening paragraph last. The clearest framing of an argument usually only becomes obvious after you've written your way through it once
Keep a small file of documents you had to write under real stakes — a postmortem, a proposal that won work, a design doc that got adopted. Reread them occasionally. You'll notice your own bad habits faster in your own old writing than in advice like this
The highest-leverage part of this skill isn't that it makes you sound smarter. It's that it's one of the only reliable ways to find out, before anyone else does, whether your own idea actually holds together. There's a commercial-side version of this discipline in , where the same principle shows up as documented decisions surviving a headcount change.
Further reading from XenGrowth
Where this work meets go-to-market
Writing that holds up under a second, unhurried read matters just as much on the commercial side of a project. publishes operator guides on that half of the work.
Further reading from XenGrowth
Where this work meets go-to-market
If technical writing is part of a growth programme rather than a standalone build, is the companion reading.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
If technical writing is part of a growth programme rather than a standalone build, XenGrowth's work on go-to-market systems is the companion reading.
Five questions on the research and the policy behind this post. The explanations are where the actual argument lives.
