Tribal Knowledge and Key-Person Risk After an Acquisition: How to Capture It

Updated: October 26, 2026

Tribal knowledge is the know-how that lives in people's heads rather than in systems or documents. Key-person risk is the exposure when that knowledge sits with one or two people. After an acquisition, capture it early: interview the people who do the work, validate what they say, and turn it into SOPs with named owners.

What tribal knowledge and key-person risk mean

Tribal knowledge is how work really gets done: which customer needs a manual check, which supplier invoices always arrive wrong, which report has to be adjusted before the board sees it. It is rarely written down because the people who hold it have never needed to write it down. They just do it.

Key-person risk is what happens when too much of that knowledge sits with too few people. If one person is the only one who can run the month-end reconciliation, release a stuck order or explain a pricing exception, the business depends on that person's availability.

The scale is larger than most leaders assume. Panopto's Workplace Knowledge and Productivity Report (2018) found that 42% of institutional knowledge is unique to the individual, and that U.S. knowledge workers spend 5.3 hours a week waiting for information from colleagues.

An acquisition raises the stakes. People may leave, get pulled into integration work, or take on new roles, and the knowledge goes with them unless someone has captured it.

Where it hides

Tribal knowledge rarely sits in one obvious place. It hides in the gaps between systems, policies and roles. When you look for it, look here first:

• Workarounds. Steps people add because the system doesn't handle a case, such as re-keying data, holding orders in a spreadsheet, or emailing a colleague to release something.
• Approvals. Who actually approves what, as opposed to what the policy says. Thresholds that changed years ago and were never updated in the documentation.
• Exceptions. The customers, products, sites or suppliers that get special treatment, and the reasons nobody remembers.
• Spreadsheets on one desktop. Trackers, reconciliations and pricing models that a single person built and maintains.
• Relationships. The contact at a key customer or supplier who knows who to call when something goes wrong.
• Timing. What happens at month end, quarter end or peak season that doesn't happen the rest of the year.

None of this shows up in an org chart or a system configuration. It shows up when you ask the people doing the work to walk through a real case.

Here's an illustrative example, not a real company. A newly acquired distributor documents its order process in six steps. Interviews with the order desk show a seventh: for a handful of large accounts, one coordinator checks stock across two warehouses by phone before confirming delivery dates, because the system's availability figure is unreliable for split shipments. She has done it for years. Nobody else knows the accounts, the warehouse contacts or the rule she uses to decide. If she leaves, those customers start receiving dates the business can't meet, and nobody knows why.

How to spot key-person risk

Use this checklist in the first weeks after a deal, or before an add-on is integrated. Each "yes" is a candidate for capture.

• ☐ Only one person can complete a recurring process end to end.
• ☐ A process stops or slows when a specific person is on vacation.
• ☐ Colleagues regularly say "ask Sam" instead of pointing to a document.
• ☐ A critical spreadsheet, macro or report has a single owner and no documentation.
• ☐ Customer or supplier relationships run through one person.
• ☐ Approvals or exceptions are decided by judgment that isn't written anywhere.
• ☐ Documented procedures are more than a year old or describe a system that has changed.
• ☐ A key person is close to retirement, has a changed role, or is likely to be stretched by integration work.

Rank what you find by impact: how much revenue, cash, compliance or customer experience depends on the process, and how hard it would be to recover if that person were unavailable for a month.

How to capture it without unsettling people

After a deal, people are already uncertain. A knowledge-capture effort that feels like an exit interview or an audit will get guarded answers and damage trust. Frame it, and run it, as making their work easier and protecting the business, not replacing anyone.

A few practices help:

• Explain the purpose first. Tell people why you're doing it: to understand how the work runs, to reduce the load on the few people everyone depends on, and to make sure nothing gets lost during integration.
• Ask everyone, not only the key people. Interviewing a whole team spreads the attention and gives you the handoffs on either side, so no one feels singled out.
• Keep it short and on their time. Short interviews people can do when it suits them get better answers than a two-hour workshop.
• Ask about real cases. "Walk me through the last time this happened" surfaces the exceptions that a general description skips.
• Let people review what was captured. When people confirm or correct their own account before it's used, they see it as theirs, and accuracy improves.
• Share it back. Show the team the result and what will change because of it.

Timing matters too. Start in the first weeks after the deal, before integration decisions are made and before anyone's role changes. Knowledge captured while people are still in their current roles is more complete, and capturing it early tells the team that the new owner wants to understand how the business works before changing it. Waiting until someone resigns turns a planned exercise into a rushed handover.

Turning captured knowledge into SOPs and owners

Captured knowledge is only useful if people can find and use it. Turn it into a small set of working documents:

• A current-state process map for each process, with exceptions shown as branches, not footnotes.
• SOPs for the steps that depend on one person, written from their account, with the decision rules spelled out.
• A key-person register listing each critical process, its current holder, a named backup, and the status of documentation and cross-training.
• Open questions and conflicts, where two people describe the same step differently, for the process owner to decide.

A simple key-person register might look like this (illustrative):

Every item should trace back to who described it, and each process should have an owner who signs it off. The owner decides what's standard, what's an exception worth keeping, and what should stop. Then pair each key person with a backup who uses the SOP for real, which is the fastest way to find what's still missing.

Keeping it current as people change roles

Knowledge capture isn't a one-time project. After an acquisition, roles change, systems are consolidated, and new workarounds appear as the business adapts. A document captured in month two can be wrong by month nine.

Build three habits:

• Re-validate on change. When a person changes roles, a system changes, or a policy is updated, re-check the affected processes with the people now doing the work.
• Review the key-person register quarterly. Confirm each critical process still has a backup who has done the work recently.
• Repeat for each add-on. Run the same capture on every business you acquire, before integration decisions are made. It's how you avoid inheriting a new set of single points of failure.

Our guide to merger and integration programs covers how this fits into the wider integration plan.

Where ClearWork fits

ClearWork is an AI discovery platform for processes and requirements. Its agent, Clarity, runs async AI interviews, by voice or chat and about 20 minutes each, with the people who do the work, on their own time. It also ingests existing documents such as SOPs, policies and system exports. Each person reviews what was captured, process owners sign off the result, and every line traces back to its source.

Outputs include process maps, SOPs, requirements, traceability matrices, fit-gap, and improvement and AI opportunities by role, along with the conflicts and single points of knowledge that need attention. Discovery typically takes one to four weeks, depending on scope and complexity, and most teams start with a 30-day sprint on one focus area. See how the interviews and validation work, or how operations and transformation teams use it. All data is hosted in the US, encrypted in transit and at rest, and no data is used to train AI models.

Tribal knowledge and key-person risk FAQs

How do you identify key-person risk?

Look for processes only one person can complete, work that stalls when someone is away, and spreadsheets or relationships with a single owner. Interview the whole team: the dependencies show up when several people describe the same process and keep naming the same colleague.

Won't people resist sharing what they know?

Some will if it feels like an audit or a step toward replacing them. Explain the purpose, interview the whole team rather than singling people out, keep it short, and let people review their own account. Most people are glad to have the load spread more evenly.

How long does knowledge capture take?

It depends on scope. Capturing one focus area with interviews running in parallel typically takes one to four weeks, including validation and sign-off. Turning the result into SOPs and cross-training backups takes longer, and should continue as roles change.

Who should own the documentation?

The process owner for each area, not HR or the integration team. They sign off the captured current state, decide open conflicts, and make sure it's re-validated when people, systems or policies change.

Is tribal knowledge always a problem?

No. Experience and judgment are valuable. The risk is when critical knowledge exists in only one place. The goal isn't to remove judgment from the work but to make sure the business can keep running if one person is unavailable.

Want to see how tribal knowledge gets captured, validated and traced to source? Book a demo.

‍