How do you capture what an expert knows before they leave?

Asking a departing expert to write down what they know almost never works. The valuable part is the judgement they've stopped noticing they have, and a forty-page handover note isn't a form anyone reaches for under pressure. Capturing it properly is an interviewing job rather than a documentation job, and it's better done while the expert is still in post, not in their final fortnight.

Most organisations find out where their real knowledge lives at the worst possible moment: when the person who holds it hands in their notice.

I went to a retirement do recently for one of the best detective sergeants I worked with. I learned a great deal from him in my twenties. He was generous with his time and his patience, and he had a depth of expertise you don't get from a course.

None of it was transferred deliberately. I learned by working alongside him: watching how he handled things, being there as he approached a problem, noticing what he did that was different from what I would have done. That worked because I happened to be in the room, for years.

I don't know whether anyone tried to capture what he knew before he left. I hope someone did. I doubt it.

An organisation doesn't record that kind of loss anywhere. There's no line on a chart for it. The work carries on, slightly worse, done by people who have no way of knowing what they're missing.

It's a pattern that repeats well beyond policing. A capability an organisation depends on turns out to sit almost entirely with one individual. Not in a system, not in a manual, not spread across a team. Everyone assumed it was written down somewhere. It wasn't.

Why does this keep happening?

The reason isn't negligence.

Genuine expertise becomes invisible to the expert. When you've done something for fifteen years, the hundred small decisions you make every day stop feeling like decisions. They feel like common sense. Ask an expert to write down what they know and they'll hand you the textbook version, because the textbook version is the part they can see. The part that makes them good sits below the level they can easily describe: the pattern recognition, the shortcuts, the 'I knew that number looked wrong'.

There's also no incentive to share it while they're still in post. Being the only person who understands something is a form of job security, even when it's held without any cynicism. And organisations rarely reward the work of writing things down. It's unglamorous, it's time away from the actual job, and the value only becomes obvious once the person who could have done it has gone.

Why doesn't 'just write it all down' work?

The standard response is to ask the departing expert to document their work before they go. It almost never produces anything useful.

They can't see the valuable part, so they document the visible part. You get a long file that restates the official process and misses the operational reality.

Even when someone captures the right things, they usually capture them in the wrong form. 'Write it all down' produces a shelf document: large, dense, technically complete, practically useless. Nobody used to read a forty-page handover note under pressure. Now a copilot might, which helps only if the right things were written down in the first place.

The gap isn't between documented and undocumented. It's between a document that exists and a resource someone can reach for when a decision has to be made: written from the reader's point of view rather than the writer's, and explicit about the knowledge it assumes you already have.

What does capturing it actually involve?

Getting real expertise out of one person's head is closer to investigation than to transcription. It isn't sitting the expert down and asking them to talk. It's asking the right questions, in the right order, and following the answers to the specifics.

The method draws on interviewing for detail, a discipline I learned as a detective in the Metropolitan Police, where I spent twelve years, five of them as a Detective Inspector. The core skill is the same: people generalise, and generalisations are where the useful information disappears. Someone will tell you 'I just check whether it looks right'. The job is to keep going until you have the actual decision:

• Right compared to what?
• What are you looking at first?
• What has made you wrong before?
• What did you check the last time you had a bad feeling about a submission?

That turns 'I use my judgement' into a set of describable decisions. It surfaces the checks the expert runs without noticing, the warning signs they've learned to spot, and the exceptions to the written rule along with the reasons for them.

The second half of the work is shaping it into something usable. Not one long document, but resources matched to how the knowledge is needed: a workflow for the routine path, a job aid for the decision points that trip people up, a short recorded explanation for reasoning that's hard to put in writing, a worked example of a real case handled well. The test isn't whether it's comprehensive. It's whether someone who isn't the expert can pick it up and make a sound decision with it.

Capture surfaces work you didn't know you had

The part organisations don't expect is that this isn't purely a preservation exercise.

In a recent engagement, the edge cases came out of working through specific live examples rather than asking general questions. What surfaced were combinations of factors that only mattered in combination. No single one of them would have looked significant written down on its own, which is precisely why nobody had written them down.

None of that would have come out of a passive 'write down what you think we should tell people' request. It needed active attempts at transfer, against real current cases, with someone pushing on the detail. Each one pointed at a dependency or a consideration the existing framework hadn't made explicit, and each generated work the organisation hadn't known it needed.

That's worth knowing before you commission this kind of work. Capture tends to expand the picture rather than close a gap, and what it uncovers is usually work that needed doing anyway.

Why this matters more now than it used to

Two things have changed.

The first is demographic. A large cohort of experienced people across the public sector and regulated industries is at or approaching retirement, and much of what they know has never been captured. Organisations discover the depth of their dependence on individuals only as those individuals leave, and replacements don't arrive already knowing what took a career to learn.

The second is AI. There's a lot of enthusiasm about using it to support expert work: answer the questions, guide the decisions, carry some of the load that currently sits with a handful of people. That's a reasonable ambition. But AI can only work with knowledge that's been made explicit. It can't reach into an expert's head any more than a colleague can. If the knowledge was never captured, there's nothing for the tool to draw on, and the output will be confident and wrong. Capture is the prerequisite.

What to do before the expert leaves

Start by finding the single points of failure. For each capability that matters, ask: if this one person left tomorrow, could we carry on? Where the honest answer is no, you've found the knowledge worth capturing. Do it while the expert is still in post and still engaged, not in their final fortnight when their attention has already moved on.

Treat the capture as skilled work, not an administrative task handed to the departing person as homework. It needs someone who can ask the questions that get past the textbook answer, and the output shaped into resources people will use rather than a document that will sit unread.

And do it before you reach for the technology, not after.

If you're working out where your own single points of failure are, that's the conversation we have most often.