When a key employee gives notice, the panic is real and usually misdirected. Teams scramble to get "everything documented" in the last two weeks — as if the problem were a missing folder of files. But most of what made that person valuable was never in a file, and couldn't be captured in a fortnight. To actually stop the knowledge drain, you have to understand what kinds of knowledge exist, because they're lost differently and captured differently. There are four, and only one of them is what most companies think of as "documentation."
1. Explicit knowledge — the part you already have
Explicit knowledge is the documented, articulable stuff: the runbook, the spec, the wiki page, the recorded process. It's the knowledge that can be written down and, in a healthy organization, largely is.
This is the only type most companies actively manage, and it's the least at risk when someone leaves — because it's already external to the person. The catch isn't capture; it's findability. Explicit knowledge that exists but can't be located is functionally lost anyway, which is why the retrieval layer over your documentation matters as much as the documentation itself. If explicit knowledge is your only concern when an employee departs, you're worried about the smallest and most recoverable slice.
2. Tacit knowledge — the expertise that resists writing
Tacit knowledge is what someone knows how to do but struggles to explain. The senior engineer's intuition for where a bug probably lives. The support lead's sense of which customers are about to churn. The judgment that comes from years of pattern recognition, held in someone's head in a form that doesn't reduce to a checklist.
This is the hardest to capture and often the most valuable, and it's exactly what a two-week documentation sprint cannot extract — the person themselves can't fully articulate it. The realistic approach isn't to demand they write it all down; it's to capture the traces of it continuously while they're there: the decisions they make and why, the Slack threads where they explain their reasoning, the reviews where they correct others. Tacit knowledge leaks into communication constantly; the question is whether you're preserving that record or letting it scroll away.
3. Procedural knowledge — how work actually gets done
Procedural knowledge is the real, working version of a process — not the official documented procedure, but how things actually happen. The undocumented steps everyone knows. The workaround for the system that half-works. The order of operations that isn't written anywhere because "everyone just knows."
The danger here is the gap between the documented process and the real one. When the person who knew the real process leaves, the team is left with the official version, which is often incomplete or subtly wrong. Capturing procedural knowledge means documenting reality, including the workarounds and exceptions — the messy truth, not the idealized flowchart. This is knowledge that can be captured, but only if you're honest about how work is really done.
4. Institutional and relational knowledge — the context and connections
The fourth type is the deep context: why decisions were made the way they were, the history behind the architecture, who to talk to for what, the relationships and informal networks that make things happen. Why is the billing system built this oddly? Because of a decision three years ago that made sense at the time. Who actually gets things unblocked in the partner org? Not who the org chart says.
This walks out the door almost entirely, and its loss is invisible until you hit it — the team re-litigates a settled decision because nobody remembers why it was settled, or a project stalls because the person who knew the right people is gone. Capturing it means preserving decision context (architecture decision records, the why behind choices) and the relational map, not just the technical facts.
What this means for capturing knowledge
The reason the four-type framing matters: the two-week documentation sprint fails because it only targets type 1, and even then only the writing-down, not the finding. The knowledge that actually walks out — tacit, procedural, institutional — was never going to be captured by asking someone to "document everything" on their way out.
The alternative is continuous, ambient capture rather than a departure-triggered scramble:
- Make explicit knowledge findable, so the documentation you do have is actually usable — a searchable knowledge base over your real content, not a wiki nobody can navigate.
- Preserve the traces of tacit and procedural knowledge as they're generated — the Slack threads, the decision discussions, the reviews — and make those searchable too, so the reasoning survives the person.
- Record the "why," not just the "what" — decision context is institutional knowledge, and it's cheap to capture at the moment of the decision and nearly impossible to reconstruct later.
The through-line is that knowledge loss isn't an event that happens when someone quits — it's a slow leak that happens continuously as context scrolls out of Slack, decisions fade from memory, and expertise stays locked in heads. A knowledge system's job is to catch that leak while people are still here, turning the ambient stream of documented work and communication into an institutional memory that doesn't depend on any individual staying. The best time to capture what an employee knows is not their last two weeks. It's all the time before them.