Knowledge Management: A Field Guide for Working Teams

TL;DR. Knowledge management is how an organisation captures, organises, shares, and reuses what its people know. Two flavours of knowledge matter — explicit (writable down) and tacit (the kind that walks out the door at 5pm). The discipline is older than most product managers; the tools change every decade. The thing that doesn’t change is whether the team can find the answer in less time than it takes to ask a coworker.

Bandit, our CTO, calls knowledge management “quantum institutional memory”. Quantum because the knowledge can exist in two states simultaneously — written down and forgotten about, or unwritten and remembered by exactly one person who is on holiday. Both states are load-bearing. Neither is operationally useful. This post is about the discipline that collapses the superposition. Sub-second loads. Keyboard-first. Bandit will be happy.

What knowledge management actually is

Knowledge management is the practice of capturing what your organisation knows so other people can use it later. The phrase has been around since the 1990s; the underlying problem is older than the typewriter. Every team that has ever had a person who “just knows how this works” has had a knowledge-management problem the moment that person took a sick day.

In working English, the discipline has four parts:

Capture — write down what’s worth keeping.
Organise — sort it so it can be found.
Share — make sure the people who need it can reach it.
Reuse — encourage the team to look before they ask.

That is the whole job. The acronyms, frameworks, and platform pages exist to dress those four verbs up in suits. We are going to keep this post in business-casual.

The two flavours: tacit and explicit

The most useful distinction in the field comes from Michael Polanyi in 1958: tacit knowledge versus explicit knowledge. The split sounds academic. It’s actually load-bearing.

Type	What it looks like	Example	KM challenge
Explicit	Words. Diagrams. Tables. Things you can paste into a doc.	API contracts, runbooks, postmortems, onboarding checklists.	Writing it down before momentum dies.
Tacit	The thing the senior engineer does in two minutes that the junior couldn’t do in two weeks.	Why we deploy on Tuesdays, why we never email that customer on a Friday, the smell of a memory leak.	Surfacing it without making it formal.

Most KM advice that fails fails because it treats tacit knowledge as a smaller, harder version of explicit knowledge. It isn’t. Tacit knowledge is a different category. You don’t capture it; you create the conditions in which it gets practiced — pair programming, shadowing, working in the open. The wiki is where the explicit half lives. The tacit half lives in the people who keep writing for it.

Ikujiro Nonaka’s SECI model (1995) is the canonical framework for moving knowledge between the two states. Most teams will not need to draw the spiral diagram. They will need to remember the spiral exists.

A short history (Drucker → Nonaka → today)

The phrase knowledge worker is older than most of the people who hold the title. Peter Drucker coined it in his 1954 book The Practice of Management, and the rest of the discipline assembled itself around the idea over the next forty years. The shape of the field, in five beats:

1954: Drucker names the knowledge worker.
1958: Polanyi splits knowledge into tacit and explicit.
1991: Knowledge management becomes the standard term for the discipline.
1995: Nonaka and Takeuchi publish The Knowledge-Creating Company, formalising the SECI model.
2010s onward: Knowledge management mostly stops being a separate department and gets folded into engineering, product, and operations — the team that ships also writes.

Three things are worth carrying from the history. First, the field predates the tools: any tool that claims to be KM is overstating its case. Second, every meaningful framework has been about moving knowledge between people, not between databases. Third, every generation rediscovers that the writing is the work.

The knowledge management cycle, in five steps

Modern KM guides converge on a five-step cycle. The names vary; the shape doesn’t.

Discover. What does the team know that isn’t written down? A 30-minute audit of the last three on-call rotations usually produces a list.
Capture. Write the thing down. The first version is bad. The first version is also the only version that gets revised. The first version that exists beats the perfect version that doesn’t.
Organise. Put it where it can be found. A taxonomy beats a search index for browsing; a search index beats a taxonomy for recall. You need both.
Share. Tell the people who need it that it exists. A new page is invisible until somebody links to it, mentions it in standup, or points at it in code review.
Reuse. Encourage “check the wiki first” before “ask in Slack”. Reuse is the only step that compounds. Every other step pays back once.

The five-step cycle is the discipline. The wiki, the search bar, the labels, the comments — those are the tools. We keep saying it because half the failure mode in this field is talking about tools without talking about the cycle.

Where knowledge management actually lives

This is the slot the SERP universally skips. Every guide describes the cycle. Almost none of them tell you which page in which tool the artifact ends up on.

For most working teams in 2026, the answer is a wiki — a single searchable surface that holds onboarding docs, runbooks, decision records, postmortems, meeting notes, design strategies, and the rest of the long tail. The wiki is the KM system. Calling it anything else is rebranding.

A working KM-as-wiki setup has four properties:

Findable. Search returns the right page in the first three results. Pages load in 50-150ms depending on your network — fast enough that nobody loses their place looking.
Editable in the flow of work. A wiki nobody edits is a graveyard with a .wiki URL. The friction has to be under thirty seconds: click, edit, save, move on.
Linked. Knowledge that doesn’t link to other knowledge is stuck in its own corner. A wiki where every page has at least one internal link from another page is a network; one where pages are islands is a desk drawer.
Dated. Every page tells you when it was last edited. Trust in KM is downstream of can I tell whether this is still true. Stamp the page; the stamp does half the trust work.

Two quarters before our 04:11 origin moment, Lord Circuitrix — VP Infrastructure, one-line ADRs only — signed off on a Postgres container nobody had asked for. The decree read, in full, “In case someone builds something.” That decision lived in a single sentence at the top of a wiki page nobody opened for six months. On the night the rest of the company decided to build something, the container was running. The KM artifact was the one-sentence ADR. The KM payoff was that nobody had to provision a database at 04:11. That is the discipline working: a piece of explicit knowledge captured once, organised somewhere findable, available to a reader who didn’t know they needed it yet.

What a knowledge management system needs to do

A knowledge management system (KMS) is the software half of the discipline. The category has been around long enough that the checklist is settled. A working KMS does these:

Holds the explicit half. Pages, documents, diagrams, attachments. JSONB-shaped content is fine; the format doesn’t matter as long as the round-trip is lossless.
Searches across everything. Typo-tolerant, instant. The user experience of search shapes whether the system gets used.
Tracks change. Version history with a full diff and one-click revert. The trust signal is “I can see what changed.”
Supports comments and review. The page becomes a conversation about itself when somebody questions a claim.
Pushes signals into the work surface. Notifications, an activity feed, slash-command insertion into the editor. The KMS has to come to the team, not the other way around.
Has plan-tier honesty about real-time collaboration. Live cursors and auto-save belong on every paying plan; a wiki that fails on simultaneous edits is a wiki that gets used by one person per page.

That list is the Raccoon Page feature surface, in plain English. We chose it because the alternative — a system that does fewer of those things — fails one of the four cycle steps somewhere.

The benefits, measured honestly

KM marketing pages list six benefits in bullet form. Three of them are tautological (better knowledge sharing, increased efficiency, reduced silos). Two are downstream (innovation, competitive advantage). One is the actual thing the discipline pays back on, and the rest follow from it:

A team can find the answer in less time than it takes to ask a coworker.

Asking a coworker — the way most knowledge moves in an under-disciplined team — costs at minimum a Slack message, a context switch on the answerer’s side, the wait for them to type, a second context switch on the asker’s side, and a third on the follow-up. Even when the conversation is friendly and fast, it takes single-digit minutes. The wiki version takes single-digit seconds. Multiply by ten ask-events per engineer per week, multiply by team size, multiply by the cost of context-switching, and the discipline pays back inside the first month. Every other benefit — faster onboarding, fewer repeated mistakes, calmer on-call rotations, better decisions because somebody actually wrote down why we decided that — is a follow-on of that one mechanism.

The metric to track is not pages created per quarter. It’s search-without-ask events per engineer per week. Hard to measure directly; easy to feel.

When knowledge management is the wrong tool

Honesty section. Not every team needs the discipline written down. There are three patterns where formal KM is overkill or actively wrong:

Teams of three. A three-person team has its KM living in three brains and a shared standup. The first ten pages of a wiki are obvious. The investment in process beyond that is overhead. When the team grows past five, the wiki earns itself. Below five, write less, talk more.
Work that is mostly tickets. A help-desk team’s knowledge often lives in the ticket queue itself — the answer is the previous resolution of a similar ticket. Formal KM tends to duplicate the ticket history and rot. Better: hook your ticket tool to a per-ticket resolution snippet and roll those up quarterly into a wiki page. Raccoon Page is a wiki, not a ticket tracker; if your knowledge is mostly transient state, fix the ticket tool first, then capture the recurring patterns into a wiki.
Knowledge that is genuinely tacit. “How to talk to this customer” and “how to refactor that legacy module” are skills, not pages. KM can host a page that lists who has the skill and a page that lists what we tried so far. It cannot host the skill itself. Pair-programming, shadowing, and apprenticeship do the work no wiki can.

The framework you reach for first should match the decision shape. KM is the right answer when the knowledge is durable, repeatable, and shared by enough people to make capture worthwhile.

Things people actually ask

What is knowledge management in one sentence? The systematic discipline of capturing, organising, sharing, and reusing what an organisation knows so future work pays back on past learning instead of repeating it.

What’s the difference between knowledge management and a knowledge base? A knowledge base is a thing — usually a searchable collection of articles. Knowledge management is the practice of keeping that thing populated, current, and reusable. A knowledge base without KM is a graveyard. KM without a knowledge base is a series of meetings.

What’s the difference between tacit and explicit knowledge? Explicit knowledge can be written down — runbooks, API docs, onboarding checklists. Tacit knowledge is the kind you can only demonstrate — pattern recognition, intuition, the smell of a memory leak. Most teams have both. The wiki captures the explicit half; pair-programming and apprenticeship circulate the tacit half.

What are the steps in the knowledge management process? Discover, capture, organise, share, reuse. The five-step cycle shows up under many names; the shape is universal. Discover is the audit step (what do we know that isn’t written down). Reuse is the compounding step — the only one that pays back more than once.

What is a knowledge management system? The software that holds the explicit half of the discipline. A working KMS does six things: holds content, searches it, tracks change, supports comments, pushes signals, and collaborates in real time. Most modern KMSes are wikis with extra features attached.

What are the benefits of a knowledge management system? Faster onboarding, fewer repeated mistakes, calmer on-call, better decisions, less waste on lookups. All five are downstream of one mechanism: a team can find the answer in less time than it takes to ask a coworker.

How is knowledge management changing with AI? AI agents are now first-class readers of the knowledge base, not just humans. A KMS that exposes its content through a protocol like MCP lets agents create, read, update, and search pages programmatically. Treat AI as another reader on the team — one that reads faster but asks better questions when the page is wrong.

Does my team need formal knowledge management? If you’re under five people and shipping daily, probably not — keep notes in a shared doc and revisit at twenty. Past five people or past one significant person leaving, yes. The earlier the discipline starts the cheaper it is.

Knowledge management is a discipline older than most of its tools. We built Raccoon Page because the discipline pays back proportionally to how fast and how findable the artifact is, and most of the wikis we used had given up on either. The post is the quick tour; the four cluster pages that go deeper are knowledge management best practices for the operating discipline, knowledge management software for the tool roundup, what is a knowledge base for the KB-versus-KM distinction, and ai knowledge base for the agent-as-reader angle. The corporation wiki post covers where the artifact lives. Free for super-lean teams. No credit card required.