Writing as a Leadership System

There was a period where I ran a 25-person engineering team almost entirely through meetings and Slack threads. Things moved. Decisions got made. But three months later, nobody could explain why we had built certain things the way we did. Including me.

That was the moment I understood that writing isn’t a communication style. It’s a memory system for an organization.

The real cost of not writing

When decisions live only in your head or in a meeting recording nobody watches, you pay for that later. You pay in re-explained context every time someone new joins. You pay in debates that rehash the same tradeoffs already settled six months ago. You pay in features built on assumptions nobody questioned because they were never written down.

The compounding effect is brutal. A team that doesn’t write accumulates invisible debt, not in the codebase but in shared understanding.

What changed when I started writing more

I started requiring written proposals for anything that would take more than a sprint to build. Not long documents. A page, sometimes less. Just enough to answer: what problem are we solving, why now, and what does success look like?

Two things happened almost immediately.

First, about a third of proposals fell apart during the writing process itself. Not because they were bad ideas, but because writing forced the author to confront gaps they’d glossed over in conversation. The argument that sounded solid in a meeting didn’t hold up on paper. That’s the first filter, and it’s free.

Second, the meetings that followed were shorter and sharper. People came having read the document. The conversation moved from “let me explain what I want to build” to “I disagree with assumption three.” That’s a different quality of discussion entirely.

Three documents I keep active

Every team I work with eventually lands on some version of these three:

Product intent memo. One page. What we’re building, for whom, and why it matters now. Not a PRD. No user stories. Just the argument for why this is worth the team’s time. I update this as the understanding of the problem evolves.

Technical decision record. Not a full ADR system, just a running doc where we log the meaningful choices. The architecture call we made under time pressure. The vendor we chose and why. The thing we deliberately decided not to build. Future-you will be grateful.

Weekly delivery notes. Three to five lines per team. What shipped, what’s blocked, what changed. I started these partly for stakeholder visibility, but the real beneficiary was the team itself. Writing down what you shipped each week forces a kind of accountability that’s hard to fake.

The thing nobody tells you

Writing doesn’t come naturally in engineering cultures that reward speed and shipping. There’s always a reason to skip it: the sprint is tight, everyone already knows the context, we’ll document it later.

Later never comes.

The teams I’ve seen operate at consistently high quality write things down. Not because they have more time, but because they’ve learned that writing is how fast teams stay fast. It removes the biggest source of drag: unclear intent.

A team that can explain its decisions in writing can execute them. That correlation has held true for me across every context I’ve worked in.