Almost every team has documentation that is out of date, and concludes that documentation does not work. What actually failed is a particular kind of documentation: the kind that describes what the code does. That is guaranteed to rot, because the code changes and the prose does not, and a wrong document is worse than none because someone will trust it.
The documentation that survives explains what the code cannot. Why this approach was chosen and what the alternatives were. What breaks if you change this. What the system deliberately does not do. Which assumptions the design rests on. That information exists nowhere in the source, disappears when people leave, and stays true far longer than any description of implementation.
The highest-value artefact for most teams is the architecture decision record - a short note per significant decision, capturing the context, the choice, and the consequences. Half a page, written when the decision is made, never updated afterwards because it is a record of a moment rather than a description of the present. Six months later, when someone asks why the system uses this queue rather than that one, the answer exists and nobody has to reconstruct it.
The second is the runbook, and it has one test: can someone who did not build the system follow it at three in the morning without calling you. Not a description of the architecture - the specific commands, the dashboards to look at, the escalation path. The way to keep runbooks honest is to have the person on call use them during real incidents and fix them in the moment, which is when the gaps are obvious.
Keep documentation next to the code, in the repository, changed in the same pull request as the change it describes. Documentation in a separate wiki drifts because updating it is a separate act of will that competes with everything else. In the repo, a reviewer can see that a behaviour changed and the document did not, and say so.
Then delete aggressively. A wiki with four hundred pages, of which thirty are current, is worse than a wiki with thirty pages, because nobody can tell which is which and everyone stops trusting all of it. Archive anything not touched in a year unless someone claims it. The measure of a documentation set is not its size, it is whether a new engineer can be productive in a week - which is also the cheapest way to test it.
