Teams oscillate between two failures: no documentation at all, or a wiki full of confidently wrong pages that nobody trusts. The second is worse, because incorrect documentation costs more than absent documentation — it is believed first and disproved later.
The fix is not more discipline. It is writing down a different category of thing.
Document decisions, not mechanics
How a function works is visible in the function, and any prose describing it starts decaying immediately. Why the approach was chosen, what alternatives were rejected, and what constraint forced the shape — none of that is recoverable from the code, and none of it goes stale in the same way.
A short architecture decision record per significant choice, written at the time, is the highest-yield documentation most teams can produce.
Put it where the change happens
Documentation in the repository, reviewed alongside the code, has a chance of being updated. Documentation in a separate system has none, because nobody is reminded of it while making the change that invalidates it.
Proximity does more for accuracy than any process.
Prefer executable documentation
A test describing intended behaviour cannot silently become wrong. Nor can a typed interface, a schema, or a script that runs in CI. Wherever a fact can be expressed in something that breaks when it stops being true, express it there instead of in prose.
Write the things people actually ask
The genuinely valuable pages are the ones answering questions repeatedly asked in chat: how to run this locally, how to get access, what to do when this alert fires, why this service exists. Keep a note of what new joiners ask in their first fortnight and write exactly that.
Everything else is usually written for an imagined reader who does not exist.
Aim for a small amount of documentation that is reliably true rather than a comprehensive set that is probably not. The first gets trusted, and trust is what makes documentation useful at all.