Documentation feels like overhead until the moment someone needs it and it isn't there: the one person who knew the process is out, an incident takes three hours instead of twenty minutes, a new hire reinvents a fix that already existed. The cost of missing docs is real — it just shows up later, as wasted time, repeated mistakes, and work that depends on one person's memory.
But not all documentation pays off. Some is written once, never read, and quietly goes stale. The skill is telling the difference. This is a short, practical way to think about documentation ROI — what it actually saves, and which docs are worth your time.
What good documentation actually saves
- Repeated lookups. A process five people do weekly, each guessing, is a tax you pay every week. Write it once.
- Incident time. A runbook turns a panicked, improvised response into a checklist — and the savings show up at the worst possible moment.
- Onboarding. Every new person who can self-serve an answer is time the team didn't spend re-explaining.
- Bus factor. Anything only one person knows is a risk. Documentation is the cheapest insurance against it.
Which docs are worth writing
Write the doc when the answer is reused, easy to get wrong, and expensive when it's wrong. A one-off task that never repeats usually isn't worth documenting. A recurring, high-stakes process almost always is.
You can put rough numbers on this. The Documentation ROI Calculator estimates the payback of a given doc from how often it's used, how long it saves, and how many people rely on it — so "should I write this down?" becomes a number instead of a guess. For the docs that clear the bar, the Runbook Composer helps turn a process into a usable, repeatable runbook.
The honest rule
Document the things people will actually reach for under pressure, keep them short enough to stay current, and skip the rest. Documentation nobody reads is just a slower way to lose the same knowledge.
This is part of how I think about technical operations. If you're deciding what's worth writing down — or want help building the systems that keep it current — here is how to work with me.