Knowledge management best practices, the working version

TL;DR. Most knowledge management best practices read like a brochure for a knowledge management consulting firm — eleven slides about strategy, none about who does the work on a Tuesday. The eight below are habits, not slides: governance, ownership, search, and the discipline to delete things on purpose.

Most lists of knowledge management best practices describe a state. The state is “the wiki is good.” The list is silent on how it gets that way. Knowledge management that survives contact with a team of fifteen is a team of fifteen choosing to keep doing the work, not a slide that gets recited at the next QBR.

The two ways wikis fail are slow and full. Slow: every page loads in a second instead of an instant; nobody opens it; the team uses Slack. Full: nobody ever cleaned up; search returns forty-seven results from 2019; the team uses Slack. Both failure modes are tractable. Eight habits below.

Treat the wiki like a system, not a folder

A folder is what your laptop has. A system is what your team has. The difference is that a system has rules about how content gets in, how it gets reviewed, how it gets retired, and what happens to a page when the person who wrote it leaves. Folders don’t have any of those rules. That’s why every folder eventually turns into “stuff.”

The first practice is the most boring one: write the rules down. Where do new pages go? Who reviews them? When do they get archived? “It depends” is not an answer — it is the absence of one. Most teams need half a page of governance, not a 14-section policy. They just need the rules to exist somewhere a human can point at. The international standard for this — ISO 30401 — is more useful as a checklist than a target.

Assign named owners. Every domain. No exceptions.

A wiki without owners is a wiki nobody updates. The unowned page is the one that’s three releases behind, the one with a dead link to a deprecated runbook, the one your new hire reads on day three and follows into production at 2am.

Pick a person — not a team, not a role, a person — for every knowledge domain. Onboarding has an owner. Runbooks have an owner. The customer FAQ has an owner. The owner does not have to write everything; the owner has to know what’s there, what’s wrong, and what’s missing. When the owner leaves, the first thing their replacement gets is the owner list, with their name newly on it.

Capture knowledge at the source

The best knowledge management capture is the kind already happening. A postmortem written during the incident retro, not three weeks after. A decision logged the day it was made, not when somebody asks why did we do this? six months later. A runbook updated by the engineer who just used it, not by the SRE lead in a Friday afternoon spurt of guilt.

The way to make this happen is to put the wiki in the path of the work. Postmortem template, one click from the on-call channel. Decision-record template, linked from the PR review checklist. Meeting notes, opened by Cmd+N at the top of every standup. Friction is the enemy. If the wiki takes longer to open than a Slack message takes to send, the knowledge is going to Slack.

Search has to be faster than asking a coworker

If your wiki is the slowest thing your team uses that day, your team will use the second-fastest thing they have — usually a coworker, then Slack. Then they will stop writing things down, because what they wrote down can’t be found.

Raccoon Page leads with sub-second loads and keyboard-first navigation — pages render in well under a second, the command palette is Cmd+K, slash commands trigger in the editor, thirty-plus shortcuts cover navigation, search, and editing. The pairing matters more than either half on its own: a fast page that still wants the mouse loses to a fast page the keyboard owns. At 04:11 PST on a Tuesday in January 2026, our backend engineer was reviewing logs from a previous wiki — the company handbook had taken eleven seconds to load again. He started a Postgres container, told our frontend engineer he’d build a faster wiki before his coffee finished brewing, and was wrong about the coffee but right about the wiki. The first page rendered before the spinner had a reason to exist.

That’s the spec, not the brag. Search has to feel like the keyboard.

Stale content is worse than no content

A wiki page that is wrong is worse than a wiki page that doesn’t exist. The empty space tells the engineer to ask; the wrong page tells them to ship. Audit the wiki on a cadence — quarterly works for most teams; monthly for fast-moving spaces. Walk the page tree, flag anything older than your release pace, ask the owner to either update or archive.

The audit is not glamorous. It is a 90-minute ticket on the calendar. It is also the single most important thing you will do for the wiki this quarter.

Templates are scaffolding, not finished work

A template that fills itself in is a lie. A template that gives you four headings, a two-sentence prompt under each, and a way to delete the prompts is honest. The template’s job is to remove the blank-page problem; the team’s job is to do the actual thinking. If your team is filling in a template by deleting nothing and writing nothing under the prompts, the template is the wrong shape.

Postmortems, runbooks, decision records, meeting notes — these have shape because the work has shape. Half the value of a good template is the headings; the other half is the team committing to use it.

The wiki competes with Slack. Slack always wins on speed; the wiki has to win on durability. The way the wiki wins is by being the place a Slack thread ends up, not the place that has to be checked first. Pin a this is in the wiki template to every channel. Auto-link wiki pages from the channels that talk about them. Make it cheaper to copy an answer into the wiki than to retype it in Slack next week.

A read-mostly culture builds itself. A write-mostly culture has to be designed.

Measure what gets used, not what gets written

Pages-created-per-week is a vanity metric. Pages-opened-per-week, divided by team size, is the real one. Search misses — queries that returned nothing — are the gold. Each search miss is a knowledge gap with a name on it; somebody typed those exact words into your wiki and got nothing back. That list is the most valuable artifact in your knowledge management program. Triage it weekly.

Page-update frequency is the freshness metric. Pages last touched more than a year ago are either evergreen (rare) or stale (common). The owner audit, applied to that list, is the cleanup cycle.

When not to use a knowledge management system

A two-person consultancy that uses Notion for everything else does not need a wiki. A solo writer does not need a team plan. A team of five that talks all day in one room can run on a shared doc for a long time. The threshold where a real wiki starts paying back sits somewhere between fifteen and twenty-five people, or three time zones, or one team-wide on-call rotation. Before then, the overhead of governance is more expensive than the search wins.

If you are under that threshold, pick the lightest tool you can. The Free tier of Raccoon Page covers three users, one space, and one hundred pages, no card. If that is enough, that is enough. The migration is the moat — but only after you actually need to migrate.

Things people actually ask

How is knowledge management different from a wiki? A wiki is a place. Knowledge management is a discipline that uses that place. The wiki is the room; knowledge management is the rules about where the books go, who shelves them, and who throws out the encyclopedias from 2008.

How often should the wiki be audited? Quarterly is the floor for most teams. Monthly is appropriate for spaces that change every release. The audit is two passes: an owner walk-through (does this page still reflect reality?) and a freshness sweep (anything older than the team’s release cadence gets a review-or-archive decision).

Should every team get its own knowledge base? Usually yes — separate spaces per team, plus a shared org-wide space for company-wide knowledge. The pattern that fails is a single space with hundreds of folders nobody owns. The pattern that works is a small set of spaces with named owners and clear charters.

How do you measure if knowledge management is working? Pages read per person per week, search-miss rate, time-to-find for new hires, and the percentage of incidents that referenced an existing runbook. The first two are leading indicators; the second two are lagging.

Does AI change knowledge management best practices? It changes the cost curve, not the rules. AI search makes “faster than asking a coworker” cheaper to implement; AI summarisation makes audits faster. The discipline is unchanged: write things down, name an owner, retire what is wrong. AI cannot pick the owner.

What about distributed teams? The practices above matter more for distributed teams, not less. The hallway conversation that solves a question in the office is not available to a team across five time zones; the wiki is the hallway. Search latency, ownership clarity, and the audit cadence all matter more.

If your current knowledge management system is making the team slower instead of faster, the move is the import. Confluence, Notion, and Obsidian all come over in about ten minutes, folders and images intact. The Free plan is real — three users, one space, a hundred pages, no card. The wiki should not be the slow part of the day.