Tribal knowledge is a single point of failure with a salary. If one person is the only one who knows how a process runs, you have concentration risk, not seniority. Reduce it by capturing the work as it happens, starting with the processes that stop the business if that person is out for a week.
We say "she's the only one who knows how that works" like it is a compliment. It is a risk register entry that nobody has filed.
What does tribal knowledge cost?
Nothing, until the day it costs a great deal.
Consider a services firm where one person, Dana, runs the monthly client billing. Nine years in. Nobody else has done it. It involves an Excel workbook, two exports, a set of client-specific rules and a few habits. Dana gives four weeks' notice.
The handover is a calendar invite called "Billing KT." Two sessions get held. Then it is the third week, there is a close to run, and Dana is half gone already. The first invoice run without her goes out with two clients billed on last year's rate card. Nobody notices for a quarter.
The cost has several parts.
Direct errors. Mispriced invoices, missed accruals, late filings. These are measurable and usually small. Usually.
Recovery time. Reconstructing a process from the artifacts it leaves behind takes weeks and costs more than writing it down would have.
Hostage dynamics. Once a person is irreplaceable, you cannot reorganise around them, promote them, or let them take a holiday without a fight. Dana has not had two weeks off in four years. That is not dedication. It is a control failure.
Valuation drag. In a sale, an investor doing operational diligence will ask who runs what. "One person, and she is on the staff list" is a finding. It shows up in the price.
None of this appears on a balance sheet. All of it is real.
Why do knowledge-transfer projects fail?
Because they ask the expert to document their own job in their spare time.
Look at it from Dana's chair. Her day is full. The documentation has no deadline, no reviewer and no immediate benefit to her. Writing it also feels slightly like writing her own replacement notice. So it gets done at the end of the day, in a rush, as the version she would tell a visitor.
This fails in four predictable ways.
The project never starts. "We'll do KT after the quarter." There is always a next quarter.
The document is written but wrong. It reflects how the process was designed, not how it runs. The workarounds, the exceptions and the quiet fixes are not in it, because they do not feel like process. They feel like Tuesday.
It is right on the day and stale in a month. A document in Confluence that nobody owns drifts. Within a year it describes a process that no longer exists.
It becomes a six-month programme. A transformation office, a template with eleven fields, a steering committee. By the time it finishes, the person it was meant to protect against has left, or the process has changed.
The pattern is the same in all four. The plan relies on the expert producing documentation as extra work. They will not, and it is not a character flaw. It is arithmetic.
What should you capture first?
Do not try to capture everything. Rank by consequence and by exposure.
Make a short list, one line each, of the processes where someone leaving would hurt. For each, score two things.
Concentration. How many people can run it today? One is a five. Two is a three. Three or more is a one.
Consequence. If it fails for a week, what happens? Missed payroll, a missed regulatory filing or an unbilled month of revenue scores a five. A delayed internal report scores a one.
Multiply. Start at the top. Expect a short list of processes to sit well above the rest: billing, payroll, month-end close, vendor onboarding, a regulatory submission, anything involving a spreadsheet that only one person opens.
Then capture them in the order of departure risk, not importance. Someone who has just announced retirement jumps the queue. So does anyone about to go on parental leave, or who has gone quiet in a way you recognise.
Capture them by watching the work, not by asking for a write-up. One recorded session of Dana running billing, with a colleague asking questions, yields more than a month of her writing. We wrote about that approach in how to write an SOP from a meeting recording.
For the hardest cases, the spreadsheet-shaped ones, there is a separate method in process documentation when your process lives in Excel.
The expert's job becomes ninety minutes of doing their normal work while somebody listens. That is a request people accept.
A fair objection: nobody has the staff to turn those recordings into procedures. Zipper Blueprint for Operations reads what already exists, including recordings, wiki pages, email threads and the workbooks themselves, then draft a procedure for the expert to correct.
How do you keep it current afterwards?
This is where most of the value is, and where most plans stop.
A procedure is accurate on the day it is confirmed and starts decaying the next morning. Three habits slow that down.
Give each procedure an owner and a confirm-by date. Not the author. The person who runs it. Quarterly for anything tied to a close or a regulated deliverable.
Make a handover the trigger. Whenever someone new runs the process for the first time, they mark up what was wrong. A new person is a free audit. Use it every time.
Generate the first draft, edit the second. Treat documentation like a build, not a project. When the process changes, a changed input, a new entity, a different approval, the draft is regenerated from the new evidence and a person checks the difference. Editing is a fifteen-minute job. Authoring is not.
One more thing, and it is the real fix. Pair every critical process with a named backup who has run it at least once. A document helps. A second person who has actually done it is better. The aim is two people for everything that matters, so that no single holiday is a risk event.
Frequently asked
Isn't this really just a retention problem? No. Retention reduces the chance someone leaves, but people also get sick, take leave, change roles or win the lottery. If the process only works while one named person is available, you have the same risk however well you pay them.
How do we ask a long-serving employee for this without spooking them? Frame it as removing the burden of being the only one who can do it. That is true, and most experts are quietly tired of never being able to switch off. Keep the ask small: one recorded session, not a documentation project.
What is a reasonable timeline? A reasonable target for a first pass on the ten riskiest processes is a quarter, and that is an estimate, not a measured result. The reason we think it is realistic: each process takes one recorded session and a short review. The expert is not writing anything, so there is no documentation project to schedule around their day job.
Related: Automated documentation: what it actually means · Process documentation when your process lives in Excel · Operational due diligence when the target has no documentation