Tribal Knowledge Is a Liability: How to Capture It

Somewhere on your team there is a person who is the only one who knows how the billing reconciliation actually works. Not how the docs say it works — how it works, including the manual step on the last Friday of the month, the vendor contact who fixes stuck payouts, and the reason you must never run the sync job before 6 a.m. None of this is written down. It doesn't need to be, day to day, because you can always ask Marta.

Until Marta resigns, or wins the lottery, or simply goes on a three-week honeymoon during quarter close. Then the team discovers that "ask Marta" was not a knowledge management strategy — it was an unhedged position, and it just got called.

That's tribal knowledge: operationally critical information that lives only in people's heads and travels only through conversation. Every team has it; small amounts are normal and even healthy. But unmanaged, it concentrates until your company's continuity depends on specific individuals not leaving, not burning out, and not being on a plane at the wrong moment. This post is about measuring that exposure and systematically reducing it — using capture techniques that actually work, because they respect one hard truth: experts are busy, experts underestimate what they know, and "please document everything you know" has never once produced a useful document.

The bus factor: measuring your exposure

The classic framing comes from software: the bus factor is the number of people who would have to be hit by a bus before a project stalls. A bus factor of one means a single person's absence stops the work. The morbid name is doing useful rhetorical work — it makes vivid that this is a when, not an if. People leave. In a normal year, expect meaningful turnover on any team; add parental leaves, illnesses, vacations, and internal transfers, and the "bus" arrives, in some form, constantly.

Before capturing anything, map where your exposure actually is. This takes one hour with the team and produces the most clarifying artifact in this whole post: the knowledge risk register.

Running the mapping exercise

Get the team in a room (or a shared doc, async). List every system, process, and domain the team is responsible for — aim for 20–40 rows; too coarse hides risk, too fine drowns you. For each row, answer two questions:

1. Who can handle this competently today, without help? Count the people, not the people who "sort of know it."
2. How bad is a two-week stall? Score criticality 1–3: (1) annoying, (2) damaging, (3) existential — revenue stops, customers churn, compliance breaks.

Then sort into a grid:

	1 person knows it	2 people know it	3+ people know it
Criticality 3	ON FIRE — act this month	High — act this quarter	Fine — monitor
Criticality 2	High — act this quarter	Medium — next quarter	Fine
Criticality 1	Medium — capture opportunistically	Low	Ignore

Two findings surprise almost every team that does this. First, the top-left cell is never empty — most teams of ten find three to six critical single-points-of-failure they had never consciously acknowledged. Second, the at-risk knowledge is rarely the glamorous stuff. It's the cron job someone set up in 2021, the relationship with the payment provider's support team, the reason the pricing spreadsheet has that weird tab. Expertise everyone discusses gets naturally shared; expertise nobody discusses is where the bodies are buried.

Give every red and high cell an owner and a capture deadline, and revisit the register quarterly — it's a living document, because knowledge risk regenerates every time you build something new or someone becomes "the person who handles X."

One more use for the register: it tells you what not to capture. Documenting everything is a fantasy that kills capture programs through exhaustion. The register gives you permission to ignore the bottom-right of the grid entirely and spend your limited capture budget where a departure would actually hurt.

Why experts can't "just write it down"

The obvious solution — ask Marta to document what she knows — fails so reliably that it's worth understanding why before spending techniques on it.

The curse of knowledge. Once you know something, you cannot accurately simulate not knowing it. Marta's honest attempt at documentation produces "run the reconciliation script, then verify the totals" — because to her, the eleven judgment calls inside those two steps are not knowledge, they're just obvious. Expertise compresses; documentation requires decompression, and the expert is the person least equipped to do it alone.

Tacit versus explicit knowledge. Knowledge management research going back to Polanyi's line that "we know more than we can tell" distinguishes explicit knowledge (facts and procedures you can state) from tacit knowledge (pattern recognition, judgment, feel). Tribal knowledge is disproportionately tacit — "the sync is slow today, something's wrong upstream" is a diagnosis Marta makes from a feeling she couldn't write down if she tried. Tacit knowledge transfers through demonstration and supervised practice, not prose. This is why your capture toolkit needs pairing, not just interviews.

The incentive problem. Being the only person who knows is status, job security, and a steady stream of people needing you. Few experts consciously hoard, but fewer still burn weekends eliminating their own indispensability. Any capture program that ignores this — that treats capture as a favor experts owe the org — will get polite agreement and no output. The fix is making capture high-status, low-effort work extracted from experts by others, rather than homework assigned to them. Every technique below is designed around that principle: someone else does the writing.

Technique 1: The knowledge interview

The workhorse. One hour, three roles: the expert, an interviewer (crucially, someone who does not know the domain — their ignorance is the decompression tool), and the resulting doc. The interviewer asks, probes the gaps the expert can't see, and writes it up afterward. The expert's total cost: 60 minutes of talking plus 15 minutes reviewing a draft. That price, experts pay.

Questions that reliably surface what generic "tell me about X" misses:

• The 2 a.m. question: "It's 2 a.m., X is broken, you're unreachable. Walk me through exactly what I do, from the first thing I open." Forces sequence, tools, access, and decision points into the open.
• The apprentice question: "If I had to run this myself next month, what would I get wrong first?" Experts are bad at listing what they know and surprisingly good at predicting others' mistakes — it's the same knowledge, accessed through a door that isn't blocked by the curse of knowledge.
• The history question: "What's the weirdest thing about how this works, and why is it like that?" This captures rationale — the most valuable and most perishable layer. Systems get rebuilt; the reasons they were built that way vanish with the builder, and their absence is why the next team repeats the original mistakes.
• The fear question: "What could go wrong here that would be really bad, and what do you quietly do to prevent it?" This surfaces the protective rituals — the pre-checks, the never-on-Fridays rules — that appear in no procedure because they're habits, not steps.
• The people question: "Who do you call when this breaks beyond you, and what's the magic phrase that gets them to act?" Relationships are tribal knowledge too, and they're completely invisible in system diagrams.

Here's what the decompression actually sounds like in the room. Interviewer: "Walk me through the reconciliation run." Marta: "You run the script, check the totals, done — honestly it's simple." Interviewer: "It's 2 a.m. and I've never done this. What do I open first?" Marta: "The finance dashboard — oh, but you need the service account, the personal ones can't see the payout tab." Interviewer: "Is that written anywhere?" Marta: "...no. And actually, don't run it before 6 a.m., the upstream feed isn't final until then. It looks final, that's the trap — the totals reconcile and then Friday's chargebacks land and everything's off by a few hundred dollars and you spend a day finding it." In ninety seconds, the "simple" two-step process has produced three pieces of critical undocumented knowledge — an access requirement, a timing constraint, and a failure mode with a known symptom — none of which Marta would ever have thought to write down, because to her none of them are knowledge. They're just how it is. That's the curse of knowledge dissolving under a naive question, and it's why the interviewer must be a novice.

Record the session (with consent) so the interviewer can write instead of transcribe during the hour. The write-up goes to the expert for correction — experts who won't write a doc will happily bleed red ink over someone else's draft, which is exactly the reaction you want. Then the doc gets tested: the interviewer or another novice executes it while the expert watches silently, and every place the novice stalls is a gap the interview missed. One interview-plus-test cycle per red cell on your risk register is a realistic quarterly cadence.

Technique 2: Pairing and shadowing — for what prose can't hold

Some of the risk register won't yield to interviews, because the knowledge is tacit: debugging intuition, client-handling judgment, the feel for when numbers look wrong. For those rows, the capture mechanism is a second brain, not a document.

• Deliberate pairing on the risky domain: the expert and an apprentice do the real work together on a schedule — every reconciliation run, every deploy, every quarterly close, for two or three cycles. The first cycle, the apprentice watches and asks. The second, the apprentice drives and the expert supervises. The third, the apprentice runs it alone with the expert on call. This is slower than the expert doing it solo — that's the investment, budget it consciously — and it's the only method that reliably transfers judgment.
• Shadowing with narration: for interrupt-driven expertise (support escalations, incident response), the apprentice sits in for a week while the expert thinks out loud. The narration is the point — "I'm checking the queue depth first because that rules out the usual suspect" externalizes reasoning that would never appear in a runbook.
• Rotation as policy: the structural version. Rotate ownership of critical operations (on-call, release management, the monthly close) so no one person accumulates sole tenure over anything critical. Rotation is unpopular precisely because it's inefficient in the short term — each rotation pays a competence dip — but it's the only technique that prevents tribal knowledge from re-concentrating rather than repeatedly capturing it after the fact.

A worthwhile hybrid: have the apprentice write or update the runbook during the pairing cycles. Documentation written by the learner while learning beats documentation written by the expert from memory on every axis that matters — it includes the stumbling points, defines the jargon, and states the "obvious." (For operational domains, that document should take runbook form specifically; the anatomy is in Runbooks: Documentation That Works at 3 AM.)

Technique 3: Incremental capture — the ambient methods

Interviews and pairing are campaigns. You also need a peacetime economy: habits that capture knowledge continuously, in small pieces, at the moment it surfaces, without anyone scheduling anything. Three habits cover most of it:

Answer twice, write once. The second time anyone answers the same question, the answer becomes a searchable artifact — a doc, a wiki page, a Q&A post — and the asker gets a link. The knowledge was just decompressed for free (the expert already typed the explanation); capture is a paste and a title. Teams that install this one norm find their knowledge base grows precisely along the contours of what people actually need to know, which no top-down documentation plan ever predicts correctly.

Decisions get records. Most tribal knowledge starts life as an undocumented decision — why we chose this vendor, why the retry limit is 3, why enterprise contracts skip the standard flow. A lightweight decision-record habit (one page: context, options, choice, reasoning) intercepts tribal knowledge at its moment of creation, when writing it down costs five minutes instead of a forensic interview three years later.

Narrate work in public. Progress updates, incident threads, and "TIL" posts in shared channels leave a searchable exhaust trail. It's low-grade ore compared to a proper doc, but it's free, and six months later a search for "payout stuck" that surfaces the thread where Marta fixed it is often the difference between a ten-minute fix and a day of rediscovery. This is one more reason work communication belongs in public, searchable spaces rather than DMs — the case we make more broadly in Building a Documentation Culture (Without Nagging).

Technique 4: Q&A mining — your question log is a treasure map

There's a systematic version of answer-twice-write-once: treat your team's question flow as data about where tribal knowledge lives. Every question asked in a channel, at a standup, or in a hallway is a probe reporting "this knowledge is in a head, not a doc." Most teams discard this data. Mining it is the cheapest targeting system a capture program can have.

The practical setup is an internal Q&A space — a private Stack Overflow — where questions get asked publicly, answered once, voted on, and marked accepted. The format has three properties that make it the ideal tribal-knowledge trap. First, capture is a side effect of work people already do: nobody "writes documentation," they just answer questions, and the archive accretes. Second, the accepted-answer mechanic gives future readers a trust signal that a chat scroll never provides. Third — this is the mining part — the archive is analyzable:

• Sort by views: the most-viewed questions are your highest-value missing docs. A question viewed forty times isn't a question anymore; it's a page that should exist, and probably a gap in your onboarding.
• Group by answerer: if one person has answered 60% of the questions in a domain, you've found a bus-factor-of-one cell your risk register may have missed. The Q&A data is a knowledge map, updated continuously.
• Watch for re-asks: the same question recurring every few months means the answer is findable but not being found — a titles-and-search problem, not a capture problem.

Seed the space by having the team post their own last ten answered questions from memory (with answers) so it's born useful rather than empty. Teams running on Openbook get this pattern as a native Q&A room — markdown questions, voting, accepted answers, and an analytics view for exactly this kind of mining — sitting next to the Docs and Wiki rooms where the mined questions graduate into proper pages, all under the same global search. The full argument for the format is in Why Your Team Needs an Internal Stack Overflow.

The offboarding sprint: capture under deadline

Sometimes the mapping comes too late: Marta just gave notice, and you have two or four weeks. Triage mode, in priority order:

1. Day 1: risk-register pass on everything she owns. You are not capturing everything; you are capturing the criticality-3 column. Accept the losses now, deliberately, rather than discovering them later.
2. Schedule knowledge interviews immediately — two or three one-hour sessions per critical domain, interviewer-led as above. Calendar them all in week one; notice periods evaporate.
3. Pair her final runs. Whatever critical operations occur during the notice period — the close, the deploy, the renewal call — a successor shadows or drives every one of them. A real run with the expert watching is worth five interviews.
4. Capture the relationship map: every external and internal contact, what they're for, and warm handoff intros for the critical ones.
5. The "call list" doc: for each critical system, the one-pager of what breaks, what to try, and who to call — written by the successor, corrected by Marta.
6. Negotiate a grace channel if you can: a paid, bounded consulting arrangement for 60–90 days post-departure ("up to two hours a week") converts a cliff into a slope. Not always possible; always worth asking.

And then do the part almost everyone skips: add a line to the offboarding checklist that triggers the risk-register review, so the next departure starts from a map instead of a scramble.

Making it stick: capture as a system, not a project

A one-time capture push decays back to baseline within a year, because the forces that concentrate knowledge — specialization, convenience, status — never stop operating. The durable version is a small set of standing mechanisms:

• The risk register reviewed quarterly, with red cells assigned like any other work — on the board, with owners and dates, not as a virtuous aspiration.
• Capture wired into rituals you already run: postmortems update runbooks; decision meetings produce records; onboarding assigns new hires to test-execute the docs for the riskiest domains (novice-proofing and knowledge-spreading in one move).
• Rotation for the critical operations, accepted as an insurance premium paid in efficiency.
• The Q&A space mined quarterly for the next capture targets.
• A bus-factor question in planning: when new systems or processes are born, ask "who's the second person?" at creation time, when the answer costs a code review or a shadow session instead of a forensic reconstruction.

None of this requires a knowledge-management department. It requires about one team-hour a quarter for the register, an interviewer's afternoon per red cell, and a handful of norms enforced with the same seriousness as code review. Measured against the alternative — the quarter your team loses when the wrong person resigns — it is the cheapest insurance your team can buy. (For how capture fits into the broader discipline of structuring, retrieving, and maintaining what you've captured, see the pillar guide: Knowledge Management for Teams.)

Start this week with the hour that matters most: run the mapping exercise and look at your top-left cell. If you want the whole capture system — Q&A, docs, wiki, decision records, and the search that ties them together — in one workspace instead of five tools, Openbook includes all of it on the free plan.