Knowledge transfer session: recording what only one person knows

Aug 22
3 min read

Updated: 3 days ago

Introduction

Every business has knowledge that exists in one person's head. Why the pricing is structured that way, which supplier to call, what happened the last time they tried the obvious thing.

When that person leaves, or simply goes on holiday, the business rediscovers it the expensive way. A transfer session is the deliberate alternative, and it works considerably better than shadowing.

1. A knowledge transfer session captures reasoning, not clicks

The instinct is to demonstrate the steps. Steps are the least valuable part, because they are visible in the tool and they change when the interface does.

What cannot be recovered is the reasoning: why this channel and not that one, why the price sits where it does, why we stopped doing the thing that looks obviously worth doing, which customers get exceptions and why.

Structure the session around decisions and their justifications. The procedure can be written separately and by anyone.

2. Scope it to one topic per session

Sessions that attempt to cover everything transfer very little.

One topic, sixty to ninety minutes: how pricing works, how the enquiry process runs, how reporting is produced, how the supplier relationships are managed.

Trying to hand over a whole role in an afternoon produces a recipient who nods at everything and retains the last twenty minutes. Four separate sessions across two weeks transfer far more.

3. Let the recipient drive

The most effective format is the one that feels least efficient: the person receiving the knowledge does the work while the expert watches and comments.

They hold the keyboard, they make the decisions, they get stuck. The expert intervenes only when asked or when something is about to go wrong.

Watching someone else do a task produces recognition, not capability. Recognition feels like learning and disappears within a week.

4. Ask about exceptions and failures explicitly

Standard processes get documented. Exceptions do not, and exceptions are where the real knowledge lives.

Ask directly: what do you do when it does not work, which customers are handled differently, what breaks most often, what did you try that failed, what would you warn your successor about.

That last question frequently produces the most valuable content of the whole session, and it is almost never asked.

5. Record it, and treat the recording as raw material

Record the session with agreement from everyone present. It costs nothing and captures detail nobody thought to write down.

But a recording is not documentation — nobody watches ninety minutes to answer one question. Its role is as a source for the written version.

The recipient writes that written version, from the recording, in their own words. That act of writing is where the transfer actually completes.

6. Have the recipient produce the procedure, then test it

The output of the session is a document written by the person who received the knowledge, not by the expert.

The expert's version skips what has become obvious to them. The recipient's version records exactly what was unclear, which is what the next person needs.

Then test it: the recipient performs the task from their own document with the expert unavailable. Every point where they get stuck is a genuine gap, and fixing those gaps is the real deliverable.

7. Do it before there is a deadline

Transfer sessions held during someone's notice period are rushed, incomplete and often resentful.

The right time is while nothing is changing: a rolling programme where one topic gets transferred each month, as ordinary practice rather than a response to a departure.

It also has an immediate benefit — a second person who can cover holidays and illness — which makes it easier to justify than an abstract argument about continuity.

8. Store it where the next person will look

A well-written procedure in someone's personal files has not been transferred.

Put it where the work happens: with the shared documents, linked from the routine that uses it, findable by searching for the obvious term. Add a date and the name of whoever owns it now.

Then review it when the process changes. Documentation that describes a previous version of reality teaches people to distrust all of it, which undoes the whole exercise.

Conclusion

Structure the session around reasoning and exceptions rather than steps, scope it to one topic, and have the recipient do the work while the expert observes.

Ask explicitly about failures and warnings, record it as raw material, require the recipient to write the procedure and then test it without help, run these routinely rather than during notice periods, and store the result where the work actually happens.