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.
A worked example
Put a number on the most common case — the repeated lookup. Say five people hunt for the same answer once a week, and each hunt burns ten minutes of stop-and-ask. That's 5 × 52 × 10 minutes ≈ 43 hours a year; at a loaded rate of about $60/hour, roughly $2,600 — for one answer that would take an afternoon to write down once. The cost of writing it is bounded and one-time; the cost of not writing it recurs quietly, forever. The numbers here are illustrative — the calculator runs the same math on your real usage.
What to document first
When everything feels like it deserves a doc, filter with three questions — a page earns its place when the answer to all three is yes:
- Reused? Something several people hit weekly beats a one-off nobody repeats.
- Easy to get wrong? If the steps are obvious, a doc adds little; if there's a sharp edge, capture it.
- Expensive when wrong? A cosmetic slip is cheap; a production incident or a compliance miss is not.
Three yeses is write-it-now. Two is a maybe — do it the next time you touch the process. One or none is usually a skip. It's the same standard the rest of this page argues for, turned into something you can apply in ten seconds while staring at a backlog.
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.