How do I capture a key employee's knowledge before they leave?

The conversation takes ten minutes and your week looks different afterwards. Someone who has been there for years, who knows customers by name, who knows why you run that one process exactly the way you do, has resigned. The first reflex is usually to list everything that person knows. The list gets long, everyone is put off by it, and three weeks later none of it has been done.

This post is about what does fit in the time you have. For the broader question of why capturing knowledge so often stalls, even without anyone leaving, we wrote What happens when Tom goes on holiday earlier.

You have less time than the notice period suggests

The notice period looks generous until you subtract what actually comes off it. Leftover holiday. Open cases that have to be finished first. The last week, which always goes half to goodbyes and handing over access. And in some cases someone stops working straight away, after which there is nothing left to hand over at all.

The advice you read everywhere assumes time you do not have. Planning six months ahead is fine advice for a retirement you can see coming. For a resignation you hear about on a Monday morning, it is not advice.

So turn the order around. Put the handover conversation in the diary in the first week, before the onboarding plan, before the vacancy, before the exit interview about culture and salary. Whatever you capture in week one, you have for certain. What you plan for later is at risk.

Decide first what you will drop

The biggest mistake is trying to capture everything. It does not work, and the result is worse than nothing: a folder of half-finished documents nobody falls back on, because nobody knows which parts are right.

Make a short list instead of the tasks where a standstill genuinely hurts. Usually you land on five to ten things. The month-end close only they can run. The three customers with an arrangement that is written down nowhere. The system where one person manages the permissions. The supplier who only calls them back.

Work down that list with one question: if this goes wrong tomorrow, what does it cost us? Whatever comes out on top, you do first. The rest you drop deliberately, and you are allowed to say so out loud. Dropping something deliberately is a different thing from not getting to it.

Talking is faster than writing

Ask someone to write two paragraphs about how they approach something, and you get nothing or three lines. Ask that same person to explain it while you sit next to them, and you get ten minutes of clear explanation with the reasoning included. That difference is enormous and it has nothing to do with willingness. Writing asks you to invent a structure, and that is work. Explaining to someone who is listening happens by itself.

Use that. Set up one conversation per topic on your list, rather than a single long session about everything. Have a colleague ask questions instead of taking minutes, because a good question surfaces more than a blank page does. Record it, or have something take notes, so nobody is typing during the conversation.

For anything that happens on a screen, a five minute screen recording is finished faster and more usable than a written procedure with screenshots that will be wrong again next year. Do give that recording a name someone would actually type.

Capture the why as well

Documentation almost always captures the what and the how. What has to happen, in which order. The why falls away, and that is precisely the part that lives in the head of the person leaving.

Why that customer has a different delivery time. Why you keep that one step in the process even though it looks redundant. What you tried three years ago and why it went wrong. Without that why, your successor will try it again, because the step does indeed look redundant.

So ask the question explicitly, because it rarely comes up on its own. "Why do we do it this way?" is the most valuable question of the whole conversation.

Test it while they are still there

Having written something down is not a handover. You only know it worked when someone else does it without help, while the person who always did it is still reachable.

So plan that test in the second to last week, not the last one. Let the successor run the task themselves and keep the person leaving nearby as a safety net. Whatever goes wrong then is exactly what was missing from your documentation. That is the cheapest correction round you will ever get.

What if there is no successor yet

This is the situation most SMEs are in. The vacancy is open, there is nobody to shadow the person leaving, and in eight weeks the knowledge is gone. It is the plainest version of a bus factor of one, and hiring will not fix it in time.

Two things work then. Run the sessions with the team instead of with one person, so the knowledge spreads across everyone who is there now. And capture all of it somewhere your future successor can look it up without asking anyone. If it ends up with whichever colleague happened to sit in, you have moved your problem one person along.

Where Sarrai helps

That principle of letting people talk sits inside our product. With Knowledge KickStart, Sarrai runs a guided conversation with your expert. They simply explain how something works, in their own words, and Sarrai writes the articles afterwards. You read them over and approve. Existing documents, old manuals and wiki exports go in the same way, after which they are organised by topic rather than by file.

Whatever comes in as questions after that keeps adding to the knowledge base. Every question Sarrai cannot answer becomes a proposal for a new article as soon as someone answers it. So what you captured in those last weeks keeps growing, even once your expert has left.

And for as long as there is knowledge that genuinely sits with one person, Sarrai can reach that person in the background through the expert channel. Your expert answers in two words, Sarrai turns it into a full answer for the customer, and that knowledge is recorded from then on.

The real lesson arrives too late

Anyone who goes through this once tends to draw the same conclusion: the moment to arrange this was well before the resignation. Starting a documentation project rarely helps there, because projects like that die a quiet death. What keeps working is that answers get captured at the moment they are given anyway.

A departure is still inconvenient after that. It is simply no longer an emergency.