How to capture tribal knowledge before it walks out the door

There is a moment every operations leader knows.

The head of a team walks into your office and says: "Before Maria retires next quarter, we need to make sure her knowledge gets transferred." Everyone in the room nods. Someone volunteers to "sit with her and document everything." A shared drive folder is created. A calendar invite goes out. A two-week shadowing plan is drafted.

Six months after Maria leaves, the folder is still there. Nobody opens it. The person who inherited her work has quietly rebuilt half of what she knew, badly, and is still learning the other half by breaking things.

This happens in every serious enterprise. Not because the people involved are lazy, they are usually the most conscientious operators in the building. It happens because the way most companies try to capture tribal knowledge is fundamentally wrong for the kind of knowledge they are trying to capture.

This guide is how to do it right. It is written for the people who own the risk, CHROs, heads of L&D, COOs, and it lays out a methodology we developed over two years of sitting inside real enterprises, extracting the operating logic of their best people, and turning it into something the next person, or an AI agent, can actually use.

We call it expertise mining. What follows is how to run it.

Why "just document it" does not work

Start with the honest diagnosis, because the wrong diagnosis leads to the wrong plan.

The reason most tribal knowledge capture projects fail is not that people are unwilling to share what they know. In our experience, senior operators are usually happy to talk. The failure is upstream of that. It is in the assumption that the knowledge lives in a form that can be written down by asking the person to write it down.

It does not.

A senior underwriter at a large multi-brand insurance group we work with told us, in her own words: "I do not know what I do. I just do it." She could not describe her renewal decision process on a blank page. But when we sat with her, one real case at a time, and asked why this file gets approved and that one does not, she could talk for an hour on every decision she made. Every single reason came out. None of them were in her team's SOPs.

Tacit knowledge behaves like this by nature. It is stored in the situations where it gets used, not in a form the expert can dictate abstractly. Ask a great chef to write down "how to cook." You will get a bad cookbook. Ask them why they added the salt at that moment, and you will get the real answer. This is also the reason your documents alone do not contain operating knowledge, the substrate is different.

This is why the industry statistic that gets thrown around, roughly 80% of processes are undocumented, according to Tallyfy, undersells the problem. The 20% that is documented is usually the wrong 20%. It is the official process, not the real one. Documentation captures the workflow diagram. Tribal knowledge is the judgment that gets applied to the workflow. Those are different substrates.

If your capture method assumes the expert can narrate their own expertise cold, you are going to end up with the folder nobody opens.

The frame: ask why, not what

The first move in real tribal knowledge capture is a language shift.

Almost every "document your process" conversation runs on what questions. What do you do first? What is the next step? What system do you use? These questions produce workflow diagrams. They do not produce operating knowledge.

The questions that actually surface tacit expertise are why questions, and they are usually anchored to a specific real case.

• Why did you approve this one and reject the nearly identical one?
• Why did you pick up the phone here instead of just sending the email?
• Why did you ignore what the system was telling you at this step?
• Why did you check that field first, and not the one on the top of the screen?
• Why did you escalate this case and not the last three?

Every why question, asked against a concrete case the expert can remember, pulls out one small piece of operating logic. Do it a hundred times and you have the real process.

This is the single most important discipline of an expertise mining interview: never let the conversation float up into the abstract. The moment the expert starts saying "well, in general, I...", pull them back down to a real case. "In general" is where tacit knowledge disappears. The specific case is where it stays visible.

The interview structure that works

We run a captured-expertise session in four rough phases. It is not rigid, but the order matters.

Phase 1: Frame the workspace. Ten to fifteen minutes. Ask the expert to walk you through the systems they touch, the queues they watch, the documents they read, the people they talk to in a normal week. You are not documenting anything yet. You are building a map of the terrain so that later, when the expert says "I check the SAP field," you already know which field, which screen, which context.

Phase 2: Live cases, why questions. This is the heart of the session, and by far the longest phase. Pull up real cases the expert has recently handled. Not simulated. Not "walk me through a typical case." Real ones. Ask them why every decision was made. When they answer, follow up: how would you know? What would tell you the opposite? What would make you change your mind? What is the version of this case where you would call someone?

Phase 3: Exception hunting. Every real process has an official version and an exception library that lives only in the expert's head. Ask directly: what breaks this process? What is the case that comes in maybe once a month that most of your team gets wrong? What is the version of this case where the system is lying to you? Some of the most valuable operating knowledge in the entire session comes out here.

Phase 4: Trust and escalation. Ask which data sources they trust and which they do not. Ask when they stop and ask a human. Ask who they call, and why that specific person. Ask what would make them refuse to touch a case and hand it to someone senior. This is not a soft-skills phase, it is where you capture the operating policy of the role.

Done well, this takes about one to two hours of the expert's time. Not weeks. Not a "sit next to them for a month" shadowing plan. One to two hours of focused conversation, structured to hit the specific layers of knowledge that never come out of asking someone to "write it down."

Separate personal habit from operating logic

Now the important warning.

The transcript of an expertise mining interview is not the deliverable. It is the raw material. Between the raw transcript and the usable knowledge sits a step that most projects skip entirely, and it is the reason most captured-knowledge programs produce output that does not survive the expert's departure.

That step is separating personal habit from operating logic.

A senior expert does many things. Some of them are the essence of the job, the operating logic that any competent person in that role needs to inherit. Some of them are personal habits, workarounds specific to how that individual likes to work, or artifacts of a particular software configuration they were trained on ten years ago. If you keep everything, you build a "how Maria works" manual. What you actually want is a "how the role works" manual, with the specific reasoning intact and the personal quirks stripped out.

Distinguishing the two is genuinely hard, and it is where experience with this discipline pays off. A rough guide:

• Operating logic: the reason for the action is grounded in the case, the customer, the risk, the data. It would still be a reason if a different person were doing the job. Keep it.
• Personal habit: the reason for the action is grounded in the expert's preference, muscle memory, or historical accident. A competent replacement doing the same job could reasonably do it differently. Flag it, do not enshrine it.

An example. In the interview, the expert says: "I always check the customer's payment history first before I read the case notes." Why? Two very different answers.

Answer A: "Because in this business, if payment history is red, nothing else matters, the case gets a different treatment path." That is operating logic. Encode it.

Answer B: "Because that is where I got trained to look first, and I have just always done it that way." That is personal habit. It might still make sense to check payment history early, but not because "always do this first." The operating logic is not "look here first." It is "in this case type, this signal dominates."

The difference sounds small on the page. In practice, it is the difference between capturing knowledge that any capable operator (or agent) can inherit, versus building a shrine to how one specific person happened to work.

Validate across more than one expert

This is the second discipline most projects skip.

A single expert has blind spots. They have habits they think are universal that are actually theirs alone. They have opinions on how things should be done that a peer would disagree with. And critically, they have areas of the work where they are genuinely wrong, or where their approach was correct five years ago but the environment has since changed.

If you mine expertise from a single expert and freeze it as the operating logic of the role, you will freeze all of that in with it.

The fix is validation. Take the captured operating logic from Expert A and put it in front of Expert B. Not as a document to review, as a set of specific decisions to react to. Show B the case, show B what A said the reason was, and ask: is that how you would have decided it? If not, why not?

Three things will happen.

Agreement. B agrees with A's reasoning. This is the strongest possible signal. That piece of operating logic is real, held by more than one expert, and safe to encode as the operating standard for the role.

Refinement. B agrees with the direction but adds a nuance A did not mention. This is the second-most-valuable output. The knowledge gets sharper each time it passes through another expert.

Disagreement. B decides the case differently and has a different reason. Now you have a real discovery. Either A is holding an outdated view, or B is, or there is a legitimate policy question the organization has never made explicit. This is where expertise mining finds decisions the leadership team did not know were happening two different ways in two parts of the operation.

You do not need many experts to make this real. Two to three per critical role, at most, is enough to catch the majority of blind spots and produce operating knowledge that reflects the role, not the individual. This validation loop is also how you begin to measure and reduce expert dependency risk across the operation.

Package it as a machine-readable expert profile

The final step, and the one that determines whether the whole effort survives, is how the captured knowledge is stored.

If you store it as a Word document, it will be out of date before anyone reads it, and it will not connect to a single system your operators actually use.

If you store it as a wiki page, it will end up next to the other wiki pages nobody visits.

If you store it as a transcript, it is unusable.

The output you actually want is a structured expert profile, a machine-readable representation of the role that a person can read, a training program can be built on, and, when the organization is ready, an AI agent can execute against under human supervision.

What goes into it:

• Cases the expert handles, grouped by type, with the operating logic that determines which type a new case belongs to.
• Decision reasoning, encoded per case type, not a single number, but the actual factors that push a decision one way or the other, with worked examples.
• The exception library: the specific cases where the standard process breaks, what tells you it is one of these cases, and what to do instead.
• Trusted sources, per case type. Which system field, which report, which colleague, which external data.
• Escalation triggers: the specific signals that tell the expert to stop and hand the case to a human with more authority.
• The workspace map: every system the role touches, every field that matters, and the freshness/trust rating of each one.

That last point is what turns a knowledge document into an operating asset. A machine-readable expert profile is not just a description of the role. It is a description of the role tied to the systems the role runs on. That is what lets it survive, and that is what lets it eventually be executed under governed agent operations with a human in the loop, not just read by a new hire.

Once you have this, the departure of the person the knowledge came from no longer resets the clock. What she knew belongs to the company, in a form the company can act on.

Why this is now urgent, not later

We could always have made this case on general principles. What changed is that two forces have converged and made the calendar for it much shorter than most CHROs think.

Force one: the workforce is turning over faster. The Bureau of Labor Statistics puts US median employee tenure at 3.5 years [BLS, 2024]. Deloitte and the Manufacturing Institute project 2.1 million unfilled US manufacturing jobs by 2030 [Deloitte / Manufacturing Institute]. Whole cohorts of senior operators are heading for the door, some retiring, some just moving on to the next thing, and the operators arriving behind them are arriving into roles whose real logic was never written down. This is what we mean when we talk about the expert dependency problem.

Force two: enterprise AI is coming for these same roles, and it is failing. MIT NANDA found that 95% of enterprise AI investments show no measurable business impact. From two years of building agentic systems inside real companies, we know why. The models are fine. The integrations are hard but doable. What breaks every project is that the company cannot tell the AI how the work actually gets done, because that knowledge lived in the person who is now leaving, and it lived in her head.

These two forces stack. The people who hold your operating knowledge are leaving. The AI systems you are being asked to deploy cannot replace what those people knew, because that knowledge was never mined, which is why 95% of enterprise AI pilots fail in the first place. Whichever way you approach the risk, through the HR lens or through the AI lens, the underlying gap is the same. Tribal knowledge has to be captured, or the operation gets thinner every quarter.

That is what makes now different from the last twenty years of "we should really document things." The window between the expert's departure and the arrival of a system that could have used what she knew has closed. Both are happening at the same time. If you are not capturing operating knowledge now, you are losing it in both directions.

What success looks like in practice

To make this concrete, here are two anonymized cases from our own work.

At a large multi-brand insurance group, we mined the operating knowledge of the risk team's most senior analysts, the ones handling insurance renewal decisions that used to take six minutes each. After the operating logic was captured, validated across the team, and encoded into a structured expert profile that plugged into their systems, the same renewal now takes one minute. That is not a demo statistic. That is the anonymized production reality of a workflow the operation runs many thousands of times a month. And crucially, when one of the senior analysts moved on, the operating logic did not move with her.

At a supplements manufacturer, we ran the same process against the HR candidate screening role. Screening one hundred candidates used to take a senior recruiter eight hours. After the operating logic behind "who is worth interviewing" was mined, validated, and encoded, the same one hundred candidates get screened in about thirty minutes, with a human still approving the shortlist. What the recruiter knew about "who is worth an interview" no longer lives only in her head.

Neither of these was a replacement of the expert. Both were a capture of what the expert knew, so that the work would continue to happen well without depending on any single person being at their desk on any given day.

That is the outcome. Not a folder of notes. Not a wiki. A living, structured expert profile that the operation actually runs on.

The choice on the table

If you take one thing from this guide, take this. Tribal knowledge capture is not a documentation project. Documentation projects fail, you have watched them fail, because the substrate they read from is the wrong one. The knowledge you need to preserve is not in the SOPs. It is in the people who work around the SOPs to make the operation function.

The alternative is not a bigger wiki. It is a different discipline: ask why, not what; anchor every question to a real case; separate personal habit from operating logic; validate across more than one expert; and package the output as a structured, machine-readable profile that lives close to the systems the role runs on.

This is what expertise mining is, and this is why we built the platform we did. But even without a platform, the discipline itself is available to any serious CHRO, COO, or L&D leader who is willing to reject the folder-nobody-opens approach and run the interviews properly.

If you have one person in your organization whose departure would create a real operational gap, and you almost certainly do, the time to start is now, not during their notice period. Read what actually happens when the expert everyone calls leaves, pick the highest-risk role, and put the first two hours of interview time on the calendar this month.

Mine the expertise. Then operate differently.