How to Build a Knowledge Base That Doesn't Rot

What a knowledge base is for in a small team

In a team of two to ten, a knowledge base is not a corporate intranet — it's the written memory of the business that lets someone answer a common question without interrupting you. Its entire value comes from being trusted: if people believe a page might be out of date, they'll ask a person instead, and the knowledge base quietly becomes decorative rather than functional.

This means the test of a good knowledge base is not how comprehensive it looks, but how often someone actually finds the right answer in it without needing to double-check with a colleague. A sparse but accurate ten-page knowledge base clears that bar far more reliably than an ambitious hundred-page one where a third of the content is out of date.

Structuring around questions, not departments

The most common structural mistake is organising a knowledge base the way you'd organise an org chart — folders for 'Operations', 'Finance', 'HR' — which makes perfect sense to the founder and almost none to a new starter trying to find the answer to 'how do I book annual leave'. People search for the question they have, not the department that owns the answer.

A more durable structure groups content by the situation someone is in: starting a new role, doing a specific recurring task, handling a specific type of customer issue, or dealing with something unusual and rare. Within each group, use plain-language page titles that match how someone would actually phrase the question in their head, rather than internal jargon.

Keep the top-level structure shallow — two or three levels of folders at most. A knowledge base that requires six clicks to reach an answer will be abandoned in favour of asking a colleague, however accurate the content is once you get there.

• Group by situation or task, not by internal department
• Use plain-language titles matching how someone would actually ask the question
• Keep the structure to two or three levels deep, maximum
• Put the most frequently needed pages one click from the homepage, not buried
• Maintain one visible index page listing everything, even if the underlying structure is more complex

Ownership is what actually prevents rot

Structure and search functionality get most of the attention when people talk about knowledge bases, but the single factor that most reliably prevents content going stale is a named owner for every page. An owned page has someone who feels a twinge of responsibility when it's wrong; an unowned page is nobody's job to fix, and nobody notices it drifting out of date until it causes a mistake.

Ownership does not mean the owner has to be the only person who can edit the page — it means they're the person accountable for its accuracy, the person who gets asked first if something on the page turns out to be wrong, and the person responsible for actioning the review when the review date comes round.

In a very small team, one person may reasonably own most of the knowledge base to start with, but as the team grows past four or five people, distribute ownership by area of expertise rather than leaving it all with the founder — the person doing a task day to day is usually better placed to notice when a page about it drifts out of date than the founder is.

Building review dates into the habit, not a separate task

The single biggest cause of knowledge-base rot is treating updates as a separate task that competes for attention against everything else, rather than as an automatic part of the work that changed the process in the first place. When a supplier changes, a tool gets replaced, or a policy is updated, the documentation update should happen in the same sitting as the change itself, not get added to a to-do list for 'later'.

Alongside that discipline, give every page a review date regardless of whether you expect it to have changed — three months for frequently used pages, six to twelve months for rarely used reference material. A scheduled review catches the quiet drift that nobody explicitly triggered: a step that stopped being necessary, a contact who left, a policy that was superseded without anyone updating the page that described it.

Make review dates visible on the page itself, not just in a separate tracking spreadsheet. Seeing 'last reviewed: March, next review: September' at the top of a page builds trust in the content and gives anyone reading it a way to judge how much to rely on it if the review date has clearly passed.

What actually belongs in a knowledge base

Not everything worth writing down belongs in the same place. Standard operating procedures — step-by-step instructions for a specific recurring task — are usually better kept as their own short single-screen documents, linked from the knowledge base rather than embedded in it, because they need a different format entirely. The knowledge base is the right home for reference information, context, policies and answers to recurring questions that don't reduce neatly to a numbered list of steps.

Genuinely sensitive information — passwords, banking credentials, anything that would cause real harm if it leaked — should never live in a general knowledge base, however convenient that feels. Use a dedicated password manager and a separate access register for who holds which permissions, and keep the knowledge base for information that's safe for the whole team to see.

• Company policies and how they're actually applied in practice, not just the formal wording
• Answers to the questions you get asked most often — this is the highest-value content by far
• Context that helps someone use good judgement, not just follow a checklist
• Contact details for suppliers, advisers and key external relationships
• Onboarding material for new starters, kept separate from day-to-day operational content

Never store passwords, banking logins or personal data about staff or customers in a general knowledge base. Use a dedicated password manager and keep access records in a proper register.

Choosing a tool without overthinking it

At this size, the tool matters far less than the discipline of ownership and review dates. A well-organised shared drive with a clear folder structure and an index page will outperform an expensive dedicated wiki tool that nobody maintains. If you already use a project management or team communication tool with a documentation feature, start there rather than adding another subscription and another place people have to remember to check.

The one feature genuinely worth paying attention to when choosing a tool is search quality — being able to find a page by typing a rough version of the question, rather than needing to know exactly where it's filed. Beyond that, resist the urge to evaluate tools on features you won't use in a team this size.

Signs your knowledge base has already failed

A knowledge base has functionally failed, even if it still technically exists, when people routinely ask a colleague a question that a page already answers rather than checking the page first. That behaviour tells you the team has stopped trusting the content, usually because they've been burned by an out-of-date page before.

If you notice this pattern, the fix is rarely 'remind people to check the wiki' — it's usually to audit a sample of pages for accuracy, fix or delete anything wrong, and rebuild trust by being visibly rigorous about ownership and review dates going forward. Trust, once lost in a shared document, takes a genuine and visible effort to rebuild.