When knowledge resigns: securing know-how before it walks out

Your most experienced colleague resigns. Four weeks left, a full project inbox and a head full of processes that exist nowhere in writing. What happens now decides whether the team keeps running smoothly in three months or stumbles over the same open questions every week.

Knowledge loss is rarely a dramatic event. It happens gradually: a resignation here, parental leave there, a move to another department. The damage only becomes visible once nobody remembers why a process works the way it does.

Three kinds of knowledge, but only one is in the documentation

Not everything an experienced employee knows can be captured equally well:

• Documented knowledge lives in the handbook, the wiki or the ticket system. It is findable, but often outdated.
• Tacit knowledge is what someone does without thinking about it: the right order when setting up a customer, the exception for supplier X, the person to call for edge cases.
• Relationship knowledge is the contacts: who really decides? Who do you call when it is urgent?

The first two can be secured. That is exactly where most handovers fail, because they focus on what is already written down.

Start with tasks, not with documents

The usual reflex after a resignation: "Please document everything you know." The result is a 40-page document nobody reads.

Turn the question around. Not "what do you know?", but:

Which tasks do you handle that nobody else on the team can?

That list becomes your priority order. Usually five to fifteen tasks are genuinely critical. Everything else is either documented, unimportant, or covered by several people.

Rate every task on two criteria:

1. How often does it occur? Daily, monthly, once a year?
2. What does a mistake cost? A wrongly issued invoice is annoying, a wrongly configured machine is expensive.

Whatever is frequent and expensive gets secured first.

Recording beats writing

For most processes, video is the faster documentation. Fifteen minutes of screen recording with commentary replaces two hours of writing and shows the clicks that never make it into a written guide.

This is especially true for anything that happens on screen: systems, forms, approval flows. For physical work, a short phone video does the same job.

The one thing that matters is that the recordings do not disappear into a folder afterwards. They need structure: someone joining the team has to find the right process in seconds, not search a shared drive. How that comes together in a learning path is shown in the editor.

A handover is done when someone did it themselves

A handover is only complete once the successor has performed the task independently, using the documentation and without prompting. Anything else is an assumption.

Plan the last two weeks accordingly:

• Week 1: the departing colleague does the work, the successor watches and takes notes.
• Week 2: the successor does the work, the departing colleague watches and corrects the documentation.

The questions that come up in week 2 are exactly the gaps that would otherwise have surfaced three months later.

Make it routine, not an emergency measure

The real mistake is not the poor handover, it is that a handover project is needed at all. Teams that capture knowledge continuously face an update, not a project, when someone resigns.

Three habits are enough:

• Whoever explains a task for the second time records it while explaining.
• Every new team member updates the places where they got stuck during onboarding.
• Once a quarter the team reviews the list of critical tasks: can more than one person do this?

That costs a few minutes per week. Without it, an unplanned resignation quickly costs several months of productivity.

If you want to see what this looks like for your team: in a short demo we walk through your critical processes together.