Tribal knowledge is the operational know-how a team carries in its head rather than in its documents. The sequence that actually matters. The judgment calls. The traps. The reasons behind rules that look arbitrary from outside.
It is not a documentation failure. It is what remains after documentation has been done properly — and it is usually the part that decides whether the work goes well.
What does tribal knowledge look like in practice?
It looks like a sentence starting with “oh, you also have to”.
Five kinds show up in almost every team, and it helps to name them separately, because people volunteer the first and forget the rest.
- Sequence and dependencies. Not the list of tasks but the order they must run in, and what breaks when one runs early. Written procedures are lists. Real work is a chain.
- Judgment calls. Where someone chooses between options by reading signals rather than applying a rule. When to escalate. Which exception is safe. What is worth chasing.
- Traps. What looks right, goes wrong, and is known only to people who have been caught by it. A system that reports success before the work finishes. A report that is wrong until a nightly job completes.
- Reasons. Why a rule exists. Without it, the next person “improves” the process into a failure that took someone years to learn about.
- People and places. Who actually approves things. Which of the four documents is current. Who to call when a vendor goes quiet.
Those five are also the nugget types Nuggetz uses, because they turn out to be the categories that matter when you go looking.
Why does tribal knowledge never get written down?
Because writing it is a different job from doing it, and nobody is assigned that job.
Three forces keep it unwritten, and none of them are laziness. The first is that describing work you have internalised is hard. Ask an expert to document their process and you get the sanitised version — the interesting parts stopped feeling noteworthy to them years ago. The second is invisibility: nobody writes down the thing they assume everyone knows, and by definition they cannot tell which things those are. The third is incentive. Documentation is never the most urgent task on anyone’s list, and the person who would benefit has not been hired yet.
This is why “please write it all down before you go” produces a folder nobody opens. The request is reasonable and the output is thin, every time.
Where does tribal knowledge actually cost you?
In four places, and only one of them is the obvious one.
Onboarding runs long. A new joiner learns the documented process in a week and the real one over months, mostly by getting things wrong in front of someone patient.
Escalations go sideways. When the person who knows is on leave, the fallback is guesswork or a delay, and both are expensive at the wrong moment.
The same work runs differently by person. Two experienced colleagues apply different thresholds, each certain they follow the same policy. Nobody notices until the results diverge.
Key-person risk stays invisible. It looks like nothing at all until the day the person is unavailable, which is also the day it is too late to do anything about it.
How do you capture tribal knowledge?
Ask for it. Do not request documentation.
The mechanics matter more than the intent, so three rules do most of the work.
Interview rather than assign. A conversation can ask for the last real example, probe the exception and keep the reason. A document request produces whatever the author thought to include. Question phrasing does the heavy lifting — “walk me through the last time this went wrong” beats “describe the process” every time.
Ask more than one person. One account is one account. Ask two colleagues the same question and you learn what they agree on, what rests on a single person, and where they quietly disagree. A disagreement found deliberately is worth more than either answer alone.
Keep the evidence attached. Write down who said what, so a reader can weigh a claim rather than take it on faith. Anything two people described differently is not settled enough to instruct a third.
That is the whole method, and it works in a meeting with a notepad. Doing it with knowledge interviews removes the scheduling and the writing-up, which is usually what stops it happening at all.
What should you capture first?
Whatever rests on one person, not whatever matters most.
The instinct is to start with the critical work. That is usually the work several people already understand, precisely because it matters enough to be shared. Start where the concentration is: one head, no backup. A knowledge transfer plan is how you rank a list of these and put dates against them.
A second, cheaper signal is repetition. Whatever new joiners ask about twice is tribal knowledge that has already announced itself.
Can you stop tribal knowledge forming?
No, and trying is the wrong goal.
New informal knowledge forms constantly, because the work keeps changing and people keep learning things the documents do not say. A team with no tribal knowledge would be a team that has stopped adapting. The realistic aim is narrower: notice where it has concentrated in one person, and capture that part on a schedule rather than in an emergency.