Early in my career, I believed that the strongest engineers were the ones who could hold the whole system in their heads. They could talk through a payment flow from authorization to settlement without notes, recall why a particular timeout was set to seven seconds, and reconstruct an incident timeline from memory under pressure. I admired that, and for a while I tried to be that person. What I eventually learned is that the engineers and leaders who scale are almost never the ones with the best memory. They are the ones who write things down.
This sounds almost too simple to be worth a post. But after years of running engineering organizations in regulated fintech, I have come to see writing as one of the highest-leverage habits a team can build. Not writing for show, but the quiet discipline of putting decisions, reasoning, and context into durable text. It is unglamorous work that compounds quietly, and it has saved me from more bad outcomes than any tool or framework I have adopted.
Writing Is Thinking, Not Reporting
The most common mistake I see is treating writing as something you do after you have already decided. You make the call in a meeting, in a hallway, or in your own head, and then someone is asked to write it up. By that point the writing is reporting, and reporting is cheap because the hard part is over. The real value happens earlier, when the act of forming sentences forces you to confront the gaps in your own reasoning.
When I draft a design proposal for a new ledger reconciliation process, I almost always discover that two or three things I believed were settled are not. I cannot write a clean sentence about how we handle a partial refund against a captured authorization until I actually know how we handle it. The blank page is an honest critic. It does not let you wave your hands the way a whiteboard conversation does, where momentum and confidence paper over a hole nobody notices until it becomes a production incident six weeks later.
This is why I push teams to write the document before the decision feels final, not after. The first draft is not a record of what we concluded. It is the instrument we use to reach a conclusion worth recording.
Decisions Decay Without Their Context
Every meaningful engineering decision is made against a backdrop of constraints: a regulatory deadline, a vendor limitation, a performance target, a staffing reality. The decision itself is often a single sentence. The context behind it is a paragraph, sometimes a page. And the context is the part that disappears first.
I have watched teams spend a week relitigating a choice made carefully two years earlier, simply because nobody recorded why. The original engineers had good reasons, but those reasons lived only in their heads, and those engineers had since moved on. The decision survived in the code, stripped of its justification, looking arbitrary to people who never saw the trade-off it resolved.
A decision without its reasoning is just a rule, and rules without reasons are the first thing a smart new hire tries to break.
Writing down the why is what turns a decision into something a future team can actually reason about. It lets people change it deliberately rather than accidentally, and it lets them keep it for the right reasons rather than out of fear.
Writing Builds the Asynchronous Organization
A team that relies on meetings to transfer knowledge has a hard ceiling on how large and how distributed it can become. Every fact that lives only in someone's head is a meeting waiting to happen, a Slack thread that will be relitigated, a question that gets asked four times because the answer was never written somewhere findable. Meetings do not scale. Documents do.
In a regulated environment this matters even more. Auditors, risk partners, and compliance teams do not attend your standups. They read what you wrote. When a regulator asks how we decided on a particular fraud threshold or validated a model change, the answer cannot be that three people remember discussing it. It has to be a written artifact with a date, a rationale, and a clear owner. The teams that treat writing as a habit find these moments routine. The teams that do not find them terrifying.
Good written context also changes who gets to contribute. When the reasoning is on the page, a junior engineer can read it, understand it, and push back on it. When the reasoning lives in the heads of two senior people, you have quietly built an organization where only those two can participate in the most important conversations.
Aim for Precision, Not Polish
I want to be careful here, because the word writing can summon images of beautifully crafted essays, and that is not what I am advocating. The writing that matters most inside an engineering organization is rarely elegant. It is precise. It says exactly what is true, what is assumed, and what is unknown, and it does so plainly enough that someone tired at the end of a long day can read it without misunderstanding.
Polish can even be counterproductive. A document that reads too smoothly can hide the seams where the reasoning is weak. I would rather see a blunt sentence that admits we are not sure whether a downstream provider guarantees idempotency than a graceful paragraph that glides past the uncertainty. The goal is not to impress a reader. The goal is to be understood correctly by someone who has every incentive to misread you under pressure.
When I review writing from my teams, I am not grading prose. I am asking a few specific questions:
- Could someone act on this without needing to find the author?
- Are the assumptions stated, or are they hiding inside confident-sounding claims?
- If this turns out to be wrong, will we be able to tell why we believed it?
- Is the most important sentence easy to find, or buried in the middle of paragraph four?
If a document passes those, I do not care whether the sentences sing.
The Incident Review Is Where It Pays Off
Nothing reveals the value of writing like an incident. When a payment processor degrades at two in the morning and transactions start failing, the people responding are stressed, tired, and working with incomplete information. The single most useful thing in that moment is a written record: a runbook that says what to check, a design document that explains how the failover is supposed to behave, a past incident report describing the last time something similar happened.
I insist on written incident reviews not to assign blame but to capture what the organization just learned at great cost. An incident is the most expensive education a company ever buys. To go through it and write nothing down is to pay the tuition and skip the class. The review turns a painful night into durable knowledge, and the next person who faces a similar failure inherits that knowledge instead of rediscovering it the hard way.
Over time, a corpus of honest incident reviews becomes one of the most valuable assets a team owns. It is a map of where the system is fragile, written by the people who got burned, and no architecture diagram tells you that much truth.
Writing Is How Leaders Actually Scale
As I moved from writing code to leading the people who write it, I noticed that my words started to carry more weight than my keystrokes. A clear written statement of strategy, repeated and referred to, did more to align a hundred people than any number of one-on-one conversations could. Speaking aligns the room you are in. Writing aligns the rooms you will never enter.
This is uncomfortable for many technical leaders, because writing is slow and feels less productive than doing. But the leverage is enormous. When I write down how we make trade-offs between speed and safety, I am not just informing the people who report to me directly. I am setting a standard that propagates to teams I have never met, in language they can interpret without me in the room.
If you cannot write your strategy down clearly, it is not because writing is hard. It is because the strategy is not yet clear, and your team already senses that.
I have come to treat the difficulty of writing something down as a diagnostic. When a memo will not come together, it is usually a sign that the thinking underneath it is muddy, and the discomfort of the blank page is doing me a favor by surfacing that early.
Make Writing Cheap and Findable
None of this works if writing is treated as a heavy ceremony. If every document needs a template, three approvals, and a formatting review, people will simply stop writing, and the knowledge will retreat back into heads and chat threads. The goal is to lower the cost of capturing a thought until it is lower than the cost of not capturing it.
In practice this means valuing a rough but honest note over a polished document that never gets written. It means making the place you write searchable, so that a document written today can be found by someone with a question in eighteen months. A brilliant design document that nobody can locate is functionally equivalent to one that was never written. I would rather have a slightly disorganized wiki that people actually use than a pristine system that intimidates everyone into silence.
It also means accepting that some of what gets written will turn out to be wrong or obsolete. That is fine. A document that captured the best thinking at a moment in time is still useful even after the conclusion changes, because it shows the path the team walked and why. The cost of an outdated document is small. The cost of a decision nobody can explain is enormous.
Building the Habit on a Team
You cannot mandate a writing culture into existence with a policy. People write when they see that writing is read, valued, and acted upon. The fastest way to kill the habit is to ask for documents that disappear into a folder nobody opens. The fastest way to build it is to visibly use what people write: to reference a design doc in a decision, to thank someone for a clear incident review, to make the written word the place where real conversations happen.
I try to model this myself rather than delegate it. When I make a significant decision, I write the reasoning down and share it, even when it would be faster to just announce the outcome. When someone asks me a question that has a written answer, I link to the document instead of re-explaining, which quietly teaches the whole team that writing things down is what lets you stop repeating yourself. Habits spread far more reliably through example than through instruction.
The teams that internalize this develop a kind of institutional memory that survives turnover and growth. People leave, and the knowledge stays. That continuity is not luck. It is the accumulated result of thousands of small acts of writing things down, each one feeling almost too minor to matter at the time.
Conclusion
The power of writing things down is quiet because it never announces itself. There is no dramatic moment where you point to a sentence and say that it saved the quarter. Instead it works in the negative space, in the incidents that resolved faster, the decisions nobody had to relitigate, the new hires who got up to speed without monopolizing a senior engineer's calendar. It is the rare habit whose benefits are mostly invisible and almost entirely real. If you lead a team and want a single discipline that compounds over years, start here: write the hard things down, write them plainly, and make sure they can be found.