Somebody spent three weeks writing it. There was a push, a template, a shared push to get everything captured before the quarter ended. For a while the workspace looked genuinely good.
Now people ask each other questions the documentation answers. Not because they are lazy, and not because they cannot find it. They ask because asking a person returns an answer they can trust, and reading a page returns an answer they have to verify, and verification costs more than the question did.
That is the whole problem in one sentence. Documentation goes unused when reading it is not cheaper than asking.
The trust problem, not the findability problem
Most attempts to fix unused documentation treat it as a search and navigation issue. Better structure, better tags, a better search box, a clearer homepage.
These help at the margin and they do not address the cause, which is that people have learned they cannot rely on what they find. Once a person has been misled twice by an out-of-date page, they will ask a colleague for the rest of their time at the organisation, and no amount of information architecture will bring them back.
You can test this directly. Ask someone why they asked rather than looked. The answer is almost never "I could not find it". It is usually a version of "I did not know if it was still right".
Four things that destroy trust in a knowledge base
Nothing indicates whether a page is current
The single largest cause. A page with no owner and no date of last confirmation is indistinguishable from an abandoned one. The reader has no way to tell the difference between a policy that was reviewed last month and one that has been quietly wrong since 2023.
Note that "last edited" does not solve this, because it conflates two very different things: someone fixing a typo, and someone confirming the content is still true. A page edited last week might still describe a process that changed a year ago.
What is needed is an explicit review signal: who owns this, and when did they last confirm it is accurate. That is a different field from last modified, and it is the one readers actually want.
The reasoning is missing, so exceptions cannot be judged
Documentation describes what to do. It rarely describes why, and the why is what a reader needs when their situation differs slightly from the documented one, which is most of the time.
Faced with a rule and no rationale, a reader has two options: follow it into a situation it was not designed for, or ignore it. Both are bad, and both lead to asking a person, because a person can explain the reasoning and a page cannot.
This is why decisions and documentation belong together. A policy attached to the decision that produced it, including the alternatives and the assumption, is usable in edge cases. A policy floating free is only usable in the exact case it anticipated.
It was written for the writer
Documentation written at the end of a project, by the person who did the work, tends to describe the work rather than answer the question a reader will arrive with. It is organised by how the thing is built rather than by what someone needs to do.
The tell is a document that makes complete sense to anyone who already knows the subject and is impenetrable to anyone who does not. Which is exactly backwards, since the second group is the audience.
There is more of it than anyone can assess
Volume itself destroys trust, because a reader encountering four hundred pages has no way to judge which fraction is current. Their reasonable inference is that most of it is not, and they are usually right.
This is why internal documentation drives tend to make things worse. A push to capture everything produces a large volume of pages written in one burst, none of which will be maintained, and the resulting mass makes the genuinely useful pages harder to trust rather than easier to find.
The counterintuitive fix. Deleting is usually more valuable than writing. An organisation with forty pages that are all current has functioning documentation. One with four hundred pages of which forty are current has none, because the reader cannot tell which forty. Archiving aggressively is the fastest way to make the remainder trustworthy.
What working internal documentation looks like
Four properties, and they are all about trust rather than completeness.
Property | What it means in practice |
|---|---|
Owned | Every page names a person or role accountable for its accuracy |
Dated by confirmation | A visible "last confirmed accurate" date, separate from last edited |
Reasoned | Links to the decision that produced it, with the thinking intact |
Small | Aggressively pruned, so that what remains can be trusted by default |
None of these require more writing. Three of them require less.
The maintenance question nobody answers
Every internal documentation initiative has a plan for creation and no plan for maintenance, which is why the pattern repeats every eighteen months in most organisations.
The reason maintenance does not happen is that it is nobody's task. It is a responsibility, which is a different shape of commitment, and organisations that manage it as a series of tasks will always let it lapse because a task that is not done merely disappears.
The version that works is that each page's owner holds a standing responsibility for its accuracy, and there is a light review trigger: a date, or an event such as a related decision being made. When a decision changes a process, the pages that describe that process should be visibly implicated, rather than relying on someone remembering that they exist.
This is the practical argument for keeping internal documentation and decisions in the same system rather than in a wiki and a meeting note. The decision is what makes the page out of date, so the decision should be what flags it.
Where to start if yours is unused
Do not start by writing. Start by finding out what people actually ask.
Collect the questions asked in chat over a fortnight. You will find they cluster tightly, usually around fifteen to twenty things, and the list will not match your documentation's structure at all. That list is your table of contents, and it is worth more than any planning exercise.
Then check each existing page for the two trust signals. Anything without an owner gets one or gets archived. Anything nobody will confirm as accurate gets archived, and archiving is reversible so this needs no argument.
You will end up with far less internal documentation than you started with, and people will begin to use it, because for the first time what they find can be trusted without verification.
Autono's Repo is built around that principle. Policies, processes and contracts carry owners and confirmation dates, they link to the decisions that produced and changed them, and enterprise search runs across the whole organisational record rather than a folder structure someone designed two years ago. You find an answer by asking the question you actually have, not by remembering which folder someone filed it in. The point is not to store more, it is to make what is stored reliable enough that reading beats asking.
If your organisation has a lot of internal documentation and a lot of questions, those two facts are related. Get started with Autono, or request a demo if you would rather be shown the version where they are not.
For the structural version of the fix, see how to structure a governance handbook people read, and self-serve employee onboarding for the case where the reader is brand new and has nobody to ask.
