How to Stop Your Documentation Going Stale

Code that goes stale breaks loudly. A test fails, a build errors, something visibly stops working.

Documentation goes stale silently. Nobody gets an alert. Someone just follows an out-of-date process and gets a slightly worse result, and nobody connects the two. Six months later people have quietly concluded the documentation can't be trusted — which is expensive, because now they ask you instead.

The trust problem

The important asymmetry: a missing document is honest, a stale one lies.

If someone can't find documentation, they ask, and you know there's a gap. If they find documentation that's wrong, they follow it. And once someone has been burned by one stale document, they start double-checking all of them, which removes most of the value of having any.

That's why maintenance matters more than coverage. Fifteen documents you trust beat sixty you don't.

The person who runs it, edits it

The single highest-leverage rule.

Whoever runs the process can change the documentation, immediately, without asking. No review queue, no approval, no ticket.

Requiring sign-off to fix a step guarantees staleness — the person notices the discrepancy at the moment they're busy doing the task, and the friction of raising it means they don't. They work around it and the document stays wrong.

The objection is that someone will make it worse. In practice that's rare, and it's cheap to fix because version history exists. The cost of a slightly imperfect edit is far lower than the cost of a document nobody trusts.

What you do want is a note of what changed:

Last reviewed: 2026-08-29 by Sam
Changed: step 4 — the export moved to the Reports tab in the July update

One line. It tells the next reader whether to trust it and gives you a record of drift.

Review on a cadence, not annually

An annual sweep is theatre. By month eight everything is stale and nobody looked.

Tie the cadence to how fast the underlying thing actually changes:

| What it documents | Review | |---|---| | A process built on a third-party tool that ships updates | Quarterly | | Anything with regulatory or tax content | Quarterly, and on any rule change | | Client-facing process | Twice a year | | Internal process using stable tools | Annually | | A policy | Annually, or when someone finds an edge case |

Put the review date in the document header and let it be visible. A reader who can see "last reviewed eleven months ago" knows how much to trust it, which is useful information even before anyone fixes it.

Three triggers that beat the calendar

Scheduled reviews catch drift late. These catch it at the moment it happens:

When a tool changes. If a vendor ships an interface update, anything documenting that interface is now suspect. One person checks, same week.

When someone new runs it. A new person following an SOP is the best test you'll get — they hit every gap, because they have no context to fill it in with. Their questions are the revision list. This is the same reason having a new hire document as they learn works so well.

When something goes wrong. After any incident, ask whether documentation contributed. If someone followed the document and got a bad result, that's a defect, and fixing it while the detail is fresh is far easier than reconstructing it later.

Delete more than you think

The most underused maintenance action, and the one people resist because writing it felt like work.

Every quarter, ask of each document:

• Does this process still happen? If not, delete it.
• Has anyone opened this in six months? If your tool shows views, use them.
• Would we write this again today? If no, it's probably describing a process that has moved on.
• Is this duplicated elsewhere? Delete one now, not later.

A library full of dead documents makes people distrust the live ones, because they can't tell which is which. Pruning is not lost work; it's what makes the remainder credible.

If deleting feels risky, archive rather than delete — but move it somewhere that doesn't appear in search, or you haven't solved anything.

Make staleness visible

Whatever tool you use, surface two things:

• Documents past their review date. A list, checked monthly. This is the queue.
• Documents with no owner. These are the ones that will rot, because nobody's job includes noticing.

Both belong in the weekly or monthly review alongside everything else that quietly drifts. A number you look at regularly gets acted on; a principle you agreed once does not.

What good maintenance looks like

Not a big cleanup project. A small, continuous habit:

• Anyone who runs a process and finds it wrong fixes it that day
• New people's questions become edits, not just answers
• Once a quarter, someone spends an hour on the review queue and the delete list
• Nothing sits without an owner

That's perhaps two hours a quarter for a small business, and it's the difference between a system people rely on and a folder they've learned to ignore.

The mistakes

1. Approval required to edit. Guarantees staleness at the exact moment someone noticed.
2. Annual review only. Everything is stale by month eight.
3. No owner. Nobody's job to notice.
4. Never deleting. Dead documents make the live ones untrustworthy.
5. No visible review date. Readers can't judge what to trust.
6. Treating a stale document as better than none. It's worse — it lies.

What to do next

Open your three most important process documents and check two things: is there a named owner, and when were they last reviewed. If either answer is missing, add it now — those two lines are the entire mechanism by which documentation stays alive.

Then find one document describing a process you no longer run, and delete it.