Documentation Goes Stale Because Nobody Owns It

Someone spends an afternoon writing up how price reductions get handled. It is good. It covers the awkward cases, the ones that only come up twice a year and catch everyone out. It gets shared, a few people say thanks, and it goes into the shared drive.

Eighteen months later a new starter hits the same awkward case and works it out from scratch. Badly, and over two days.

The document was there the whole time.

That is the failure worth understanding, because it is not the one people prepare for. Teams worry about documentation not existing. The more common and more expensive version is documentation that exists, is roughly correct, and is functionally invisible.

Two things have to be true, and only one gets attention

For a document to be useful, someone has to find it at the moment they need it, and what they find has to still be true.

Writing it down does neither of those on its own. Finding it requires knowing it exists and knowing roughly what it is called, which means the person who most needs it, the newest person, is the one least able to get it. And staying true requires someone noticing when reality moved, which nothing in the system does automatically. A process changes in a meeting. The document does not attend the meeting.

So documentation decays quietly, in a way that produces no error message. It just sits there being wrong at people, occasionally, and nobody connects the two-day workaround to the page nobody opened.

Put it where the work already is

The principle that holds up is that documentation should sit in the path of the work rather than in a place people have to remember to visit.

This is why a note attached to the thing it describes survives and a policy folder does not. Nobody navigates to the folder. But if the process note for a price reduction is attached to the listing record, it is in front of whoever is doing the reduction, at the moment they are doing it. They did not have to know it existed.

The same logic explains a rule worth stating plainly: anything that changes quickly should live next to the thing it describes, not in the team-wide documentation. Team docs are for what stays put. The fast-moving stuff needs to move when its subject moves, which only happens if the two are in the same place.

We run a version of this ourselves. Our reference material sits in one place that gets pulled onto every machine and pointed at by every project, so it arrives rather than being searched for. That is developer plumbing and the specifics will not transfer, but the shape is the same: put it in the path, and nobody has to remember anything.

The problem is that most teams do not have a path

Here is where the advice runs out, and it is worth being honest about it rather than repeating the principle louder.

"Put it in the path of the work" assumes there is a path. A typical setup is a CRM, a separate tool for whatever the CRM handles badly, a website platform, and a shared drive where the actual process knowledge lives because it was the only place that would hold a paragraph. Four systems, no shared centre. There is no single location a document can occupy that puts it in front of everyone at the moment they need it, because there is no moment everyone shares.

And these tools do not talk. A change made in a document has no route into the tool where the work happens. A decision made in the tool has no route back into the document. Both drift, in opposite directions, with nothing watching the gap.

Why your tools are not going to fix this

Most of these products now have some form of AI in them, and most will happily read your context in. Connect the drive, point it at your files, let it answer questions about your processes.

Far fewer will let that knowledge back out.

That is not an oversight. Your process knowledge living inside their product is precisely what makes leaving expensive. The longer you use it, the more of how-you-work is in there, and the more a migration costs. Interoperability is the feature least aligned with their interests, which is why it tends to arrive last, partially, and with an enterprise price on it.

Worth saying plainly, because it changes what you should ask for. When you are evaluating a tool, the question is not only whether it does the job. It is whether knowledge about how you do the job can live in it, stay current, and get out again. That last part is the one nobody asks in a demo, and the one that costs the most later.

What would actually be required

For context to travel between tools, you would need each one to surface the relevant knowledge while you work, let you update it in place, and expose it over an API or similar so another tool can read the same thing.

Even then it is not clean. Two tools can read the same document and still disagree about what is true, because nothing arbitrates between them. Interfaces move data. They do not settle questions.

One arrangement that works now

Here is what we would do, offered as an example rather than an answer, because we do not know your tools.

Keep the knowledge in a shared store that sits outside all of them, a drive or similar. Nothing has to cooperate with anything else; each tool only has to reach the same folder.

The prerequisite, and it is the thing to check first, is whether your tools can write to that store and not only read from it. Read access is common. Write access is the rarer half, and without it the whole arrangement is one-directional and drifts like everything else.

Then close the loop with a notification. When something updates the shared document, a message goes into the channel the team is already in, and someone looks at it. Not a folder they would have to visit. The thing already open on their second monitor.

Two details make the difference between this working and this being noise:

• The message has to say what changed. A summary or a diff. "Document updated" gets ignored by the second week, and then you have a notification system rather than a review.
• It should carry the reason. Knowing someone was asking about refund handling explains an edit that would otherwise look arbitrary six weeks later.

The review here happens after the fact. The document is already live when the message lands, so this is someone catching a bad edit rather than preventing one. For process documentation that is usually the right trade: a wrong sentence sitting in a document for an hour is embarrassing, not dangerous, and the alternative is a gate that nobody maintains.

One thing this arrangement does not survive without: a named person. Not a channel everyone is in, which is the same as nobody. If no one is accountable for looking, the notifications become weather, and you have built the appearance of review.

We have not solved this

It is worth being straight about that. We do this for a living, on a small team, with tooling we chose ourselves, and keeping documentation aligned across projects is still a constant battle. Not an occasional lapse. Ongoing work that has to be done deliberately, because nothing about it happens on its own.

So we would be suspicious of anyone selling you a clean answer to this, including us.

What we would offer instead is a better set of questions for the next time you are choosing a tool:

• Can knowledge about our processes live inside this, or only alongside it?
• Can it write to somewhere we control, or only read from it?
• If we left in two years, what would come with us?
• When something changes in here, who finds out?

None of those appear on a feature comparison. They are the ones that determine whether, eighteen months from now, someone spends two days solving a problem you already solved.

If you have not documented much yet, start lighter than you think you should. The formats that survive are the ones that are easy to update. This piece is about the part that comes after, which is making sure anyone ever reads them.

If your documentation exists and nobody opens it, tell us where it lives and we'll look at what would put it in the path of the work.