Every business has a Maria. Maria has been there fourteen years. She knows which supplier to call when the Tuesday shipment is short, and why. She knows the quirk of the old labelling machine that makes it misread a particular size. She knows which customer will escalate to the MD if their invoice is late and which one will not.
None of that is written down. It lives in Maria's head. When Maria is on holiday the week is harder. When Maria retires, half of that knowledge leaves with her, and nobody will realise what is missing until the situation comes up and the answer is no longer in the building.
This is tribal knowledge: the knowledge that keeps the business running but has never been externalised. It is the quiet risk in every operations business over about five years old.
Why tribal knowledge is dangerous
The danger is not that tribal knowledge exists. Some amount always will, and trying to eradicate it entirely is a fool's errand. The danger is that critical tribal knowledge is load-bearing, and treated as if it were not.
Four specific risks show up repeatedly.
Single person of failure. When one individual is the only one who knows how to do something, their holiday, illness, or resignation becomes an operational incident. In practice, many businesses discover the extent of their tribal knowledge only when that person walks out the door.
Quality variance.When a task exists only in people's heads, different people do it differently. You get cohort-level variance in the outcome - different error rates, different customer experiences, different costs - and it is hard to pinpoint why.
Slow new-starter ramp-up. A new starter can only learn tribal knowledge by being next to the person who has it. That is expensive, slow, and scales poorly. It also means the new starter is worse at the job for months longer than they would be if the knowledge were written down somewhere they could refer to.
Hard to scale. If you open a second location, a second team, a second shift, you are starting over with the same oral-tradition approach. The business cannot replicate what it has not externalised.
None of these is a crisis until it is. And by then capturing the knowledge is no longer possible, because the person who had it is gone.
A final angle on the risk. Tribal knowledge is not always held consciously. Ask Maria to list what she knows that nobody else does and she will underreport by a large margin - because much of what she knows has become automatic, and automatic knowledge is invisible to the person holding it. You only notice what Maria knew when Maria is not there to do it.
What to prioritise capturing
A full audit of tribal knowledge in a twenty-year-old business is a long project. Most teams do not have the appetite for that, and should not attempt it. Pick the pieces that matter most and capture those first.
Three criteria help:
- Single-holder knowledge. Anything that only one or two people know. If the bus-factor question has an uncomfortable answer, write it down.
- High-frequency tasks. A procedure done fifty times a week costs more in drift and inconsistency than one done twice a year. Capture the common before the exotic.
- High-risk tasks. Anything where a mistake is expensive: safety, compliance, customer-facing money, data handling. The cost of a mistake justifies the cost of the capture.
Score your candidate list against these three. Tasks that hit two or three of them are your first wave. Tasks that hit only one can wait.
One more prioritisation rule worth noting: anything documented will get used during an absence. If a knowledge holder is about to go on a long holiday, parental leave, or a secondment, that is the right moment to prioritise capturing what they know. The forcing function is built in.
Methods that work
You cannot just ask Maria to “write it all down.” She will not, and if she does it will be thin. The trick is to structure the capture so that the knowledge-holder has to do as little writing as possible, and someone else does the structuring.
Shadowing with note-taking
The classic. A less experienced team member follows Maria for a day and writes down what she does, not what she says she does. Those two can differ substantially. What people say they do is a stylised version of what they actually do. The gaps between the two are the knowledge that is hard to articulate and therefore worth capturing.
The shadow keeps a running log with timestamps, the task happening, and - crucially - the questions they wanted to ask. Every “why did she do it that way?” is a candidate procedural branch. At the end of the day, sit down together and walk through the log. The answers to the “why” questions are the SOPs.
Structured interviews
For knowledge that does not happen on any given day - rare but important tasks, failure-mode handling, supplier-specific knowledge - shadowing does not work. You cannot watch something that is not happening.
Instead, run a structured interview. Not a free chat. A scripted set of prompts. “Walk me through the last time we had a shortage from the Tuesday supplier. What did you do first? What did you check? What did you say to them? If you had been on holiday, how would another person have known to do that?” The last question is the most productive one.
Interviews produce transcripts, which are the raw material for SOPs. Thirty minutes of well-structured interview typically yields one or two draft procedures.
Recorded walkthroughs plus AI transcription
This is the newest method and probably the most productive. Have the knowledge-holder record themselves doing the task, narrating as they go. A phone video or a screen recording is enough. Do not ask them to write anything.
An AI can then transcribe the recording and draft an SOP from it: structured steps, plain-language instructions, the relevant video clips embedded at each step. The knowledge-holder reviews the draft, which takes ten minutes instead of the hours it would take to write from scratch. A task that would otherwise have stayed undocumented for another year is documented in an afternoon.
The effort asymmetry is the point. The expert has to do the thing they are already good at (doing the task) and review someone else's first draft. They do not have to do the thing they are usually bad at, which is writing.
Retrospectives after unusual events
Some tribal knowledge is genuinely rare - the kind that appears only when something unusual has happened and someone with deep knowledge handled it. Those moments are gold and they vanish fast.
Make a habit of doing a short retrospective after any unusual event. A stockout, a major customer escalation, a near-miss incident, a regulatory query. Thirty minutes with the people who handled it, a scribe writing down what they did and why. The output is a mini-SOP for the next time that kind of thing happens. Over a year, these retrospectives build up into a quiet library of edge-case knowledge that would otherwise have been forgotten.
You can combine these methods. A common pattern: a recorded walkthrough for the everyday version of the task, a structured interview for the edge cases, and a retrospective line added when something unusual happens. Over six months the three converge into a resilient picture of what the knowledge holder actually does.
A reasonable cadence
Tribal-knowledge capture is not a project with an end date. It is a practice. A team that commits to capturing one high-priority procedure per fortnight - by any of the methods above - is doing better than one that commits to a ninety-day documentation sprint and then stops.
The reason is that tribal knowledge regenerates. Processes change. People retire. New equipment shows up. New compliance requirements land. Last year's captured knowledge is partially out of date already. A slow, continuous cadence keeps up with the decay. A big-bang project does not.
Some teams use the weekly management meeting to nominate one “knowledge debt” item for the coming fortnight. Others put it on the annual objective list of each senior operator: two documented procedures per quarter, from areas where you are the only one who knows. Whichever mechanism you use, make it small, regular, and accountable.
Resistance, and how to handle it
The hardest part of tribal-knowledge capture is often not the mechanics. It is the cultural moment where the expert wonders why they would hand over the thing that makes them indispensable.
This is a legitimate concern and is best addressed directly. A few practical moves typically help. Make clear that documenting the knowledge is part of the senior expectation - not optional, not extra credit. Give the expert credit for the documented procedures (author line, acknowledgment, a note in their appraisal). Frame it as freeing them to do harder work, not replacing them - because an expert who has externalised their routine knowledge is exactly the person you can trust with the next difficult problem.
If the expert genuinely does not want to do this, that is information too. Job roles that depend on private knowledge are fragile for both sides - including the expert, who cannot take a proper holiday.
A final move that helps: make tribal-knowledge capture a two-way exchange. The expert documents what they know. In return, the organisation explicitly frees up their time for higher-value work and publicly acknowledges the contribution. It costs little and changes the conversation from “please hand over your advantage” to “help us build the next thing.”
The long view
Tribal knowledge capture is not glamorous. It does not produce a launch moment or a big KPI swing. Its payoff is quiet and lagged: a holiday that goes smoothly because the person covering had the SOP, a new starter who is productive a month faster than their predecessor, an incident that does not happen because the procedure that prevents it was actually written down.
The businesses that do this consistently end up with a kind of institutional resilience that compounds. The ones that do not end up learning, about once a decade, that a large chunk of how they work had been stored in someone's head and walked out of the building with them.
The barrier has dropped a lot in the last couple of years. Where capturing a procedure used to mean hours of writing, it now starts with a phone recording and an AI-drafted SOP. See how AI-assisted capture works or look at a worked example in video to SOP in ten minutes.