Writing as thinking

Writing as thinking names a specific use of a document: you draft it to reach a conclusion rather than to record one you have already reached. The best-known case for it is Paul Graham's, and it rests on an observation anyone who writes regularly will recognize: a large share of the ideas in a finished piece did not exist when the writing started. They turned up because writing in full sentences forces you to say what each claim depends on. Leslie Lamport, who spent a career getting distributed-systems proofs right, said the same thing in one line: "If you're thinking without writing, you only think you're thinking." I lean on this in my own work because the page keeps catching mistakes I did not know I was making.

The writing advice a manager runs into is aimed at a later stage of the work. One genre teaches formats: how to structure a six-page memo, what sections a design document needs. Another teaches reader-facing craft: open with the summary, and sequence the ideas in the order the reader needs them. Both are useful, and both assume the thinking is finished and only needs packaging. The moment neither covers comes earlier: the reorg half-decided in your head, or the promotion case due Friday. The five moves below are how I use the principle in those moments.

Write before you decide

Before any call that would be expensive to get wrong, the kind you are about to make from memory and instinct in a meeting or in a reply, write the argument down as one page of prose: which options you weighed, and why the winner wins. Where the prose breaks down, the thinking usually has too. If the paragraph explaining why option B loses refuses to say anything specific, option B was never seriously weighed.

I write this page before reorgs and before architecture commitments. The last time it changed my mind was a service migration the whole room, me included, considered settled. The one-pager went fine until the rollout section, where the plan turned out to depend on a system another team was midway through replacing, a dependency nobody had said out loud. We spent the meeting re-sequencing the two projects instead of committing to a date.

Watch for the memo written after the call is already made, the one that exists so the call looks considered. Nothing gets discovered while writing it, because the conclusion came first. Ask whether the decision can still change while you write; if it cannot, you are documenting, which is a worthwhile habit and a different one.

Stay in prose while the thinking is unfinished

Bullets let unrelated claims sit next to each other and look like an argument. Each line reads as individually true, reviewers nod along, and the relations between the lines, which are where the argument lives, never get stated. Prose takes that option away: full sentences keep asking for "because" and "unless", and you find out quickly whether you have one.

Amazon turned this into policy in 2004, banning slide decks from senior meetings in favor of six-page narrative memos read silently in the room before discussion starts. The reason Amazon gives is the same mechanism: narrative forces the writer to connect claims, and connected prose exposes the gaps that bullets glide over.

None of this makes bullets bad; they are the right form for finished thought, the checklist or the summary of a decision you have already examined. Use prose while the thinking is forming, and compress once it has set.

Prose is not a guarantee either, because six fluent pages can hide the same gaps behind confident sentences. Whatever the length, find the "because" in each paragraph and ask whether what follows it would survive one "why".

Treat the stuck sentence as a signal

Some sentence in the draft refuses to land: you rewrite it four times, each version differently worded and equally wrong, and it is natural to read that as a style problem more effort at the keyboard will fix, but in my experience it rarely is. A sentence that keeps collapsing marks something you have not figured out yet, a number you do not have or a conversation you have not had. Stop wordsmithing and go get the missing thing; once you have it, the sentence stops being hard to write.

Promotion cases are a good example. A manager sits down to write the impact section for an engineer they genuinely believe in, and the one paragraph that should demonstrate scope beyond the team will not come together. After an evening of rearranging the same three examples, the honest conclusion is that the paragraph cannot be written because the evidence for the level does not exist yet. The case needs another quarter of bigger projects more than it needs better wording, and it is much cheaper to learn that from your own draft than from the committee.

You can always get the stuck sentence written by loosening it, and then everyone who reads the document inherits the confusion you did not resolve.

Write twice

The draft that helps you think is rarely fit to send. Its job is to show you what you do not know, which means it holds half-arguments you are still testing and dead ends you needed to walk down before ruling them out. A document that has to survive a design review, or a read from your VP, cannot afford any of that; it needs a summary at the top and a sequence built around the reader's decision, with none of your wandering left in. Making one document do both jobs damages both, because you either send people your confusion or you start performing for an audience while the thinking is still unfinished.

Document-heavy cultures earn their bad reputation right here: a team stalled for two weeks while someone polishes a memo, and the polish is going into the wrong draft. The thinking draft is supposed to be cheap and disposable, thirty minutes of rough prose that nobody else needs to see. Save the craft for the version you send, and start that version once the thinking has settled. Building it, whether it is a case made upward or direction made legible to the team, is a different job, and other essays here cover it.

Keep the first draft yourself

A model will now produce a plausible version of any document a leader needs, the design review or the promotion case, in seconds. If writing were only packaging, that would be pure gain. But if a large share of the thinking happens during the drafting, then whoever writes the first draft does the thinking, and reviewing what a model produced leaves you with a document whose reasoning you never went through.

A 2025 MIT Media Lab study measured this: people who wrote essays with an assistant were measurably less engaged with what they were writing than people who wrote unaided, even though the finished essays read fine to evaluators. Paul Graham predicts that as models absorb the drafting, people will divide into those who still write and those who do not, and, since writing is thinking, into those who still think their own positions through and those who have stopped.

I type the first rough paragraphs myself, before the model sees anything: what I believe and why. After that I use it freely, to argue the other side and to cut six paragraphs down to two for the version I send. The one part I have not found a good way to hand over is forming the argument in the first place.

The drift into model-written thinking is hard to notice, because nothing looks wrong: the documents read well and they carry your name. It shows when someone asks a second follow-up question and you realize the reasoning under your own memo was never yours.

Know when not to write first

Writing first is not always the right move. An interface question between two systems resolves faster with the two engineers at a whiteboard, and a prototype answers "will this feel right" better than any memo. Some people reason best out loud, and a page from them is a transcript of thinking that already happened in conversation.

The pages cost real time too: twenty to thirty minutes before each big call, and in a bad week those minutes lose to the calendar. I spend the page in proportion to how hard the call would be to reverse, and I skip it without guilt for anything a conversation or a quick build can settle.

The pages that pile up afterward are not waste, either. They are what a reflection practice revisits and what decision records formalize, and a team document culture starts from this raw material. Each of those is its own practice; this one only supplies the pages.