Tribal Knowledge: Find What Only One Developer Knows

Every engineering team runs on knowledge that was never written down. It surfaces the week someone is on leave, when a deploy fails and the only person who understands the rollback is unreachable. This guide covers what tribal knowledge actually is, the four types it comes in, how to find yours in git history, and which parts are worth transferring.

What Is Tribal Knowledge in Software Teams?

Tribal knowledge is what your team knows collectively but has never recorded. It covers the reasoning behind a schema, the sequence a set of services has to start in, the reason a timeout is set to 4 seconds and not 30, and the name of the person who understands the billing reconciliation job.

The usual framing calls this a documentation problem. That framing is why so many attempts to fix it fail. The team writes documents, the documents go stale, and the same person still gets pulled into every incident on that service. The problem is not that the information is unwritten. It is that the understanding sits in one place.

"Tribal knowledge isn't a documentation problem. It's a concentration problem that documentation sometimes solves."

The scale is easy to underestimate. The same Stack Overflow survey found 63% of respondents spend more than 30 minutes a day searching for answers, and 25% spend more than an hour, which the survey puts at 333 to 651 hours a week across a 50-person team. Not all of that is tribal knowledge - plenty is ordinary reference lookup that no amount of internal documentation would remove. The share that is worth attacking is the part where the answer exists in a colleague's head and nowhere else.

What Are the Four Types of Tribal Knowledge?

Treating all undocumented knowledge the same is the reason documentation initiatives stall. These four types have different causes and respond to completely different interventions. Three can be written down. One cannot.

Archaeology is decision history. It answers why the retry limit is 4 and not 40, why an obvious refactor was tried and abandoned, and which constraint that shaped the design no longer exists. This is the type that disappears completely when someone resigns, because nothing in the code records a decision that was never made explicit. It is also the cheapest to capture: a short architecture decision record written at the time costs minutes.

Operational knowledge is how to run and repair the system. Deploy sequence, rollback steps, which dashboard tells you the truth during an incident. Runbooks work here, and they stay accurate if you write them during real incidents instead of in a planning session.

Relational knowledge is the social graph: who owns which service, who reviews what, who to escalate to. Teams underrate this until an org change invalidates all of it at once. Ownership maps and review coverage data keep it current.

Craft is judgment: the sense that a particular abstraction will be painful in six months. This is genuinely tacit, and no document transfers it. It moves through pairing, code review, and time spent working alongside someone. Teams that pour effort into documenting craft produce long documents that read as vague advice, then conclude documentation does not work.

Why Does Tribal Knowledge Form Even on Good Teams?

This is not a discipline failure, and teams that treat it as one make it worse. Tribal knowledge forms because of incentives that are individually correct.

The person who knows a service best is the fastest person to change it. Routing the work to them is the right call on any given day, and it is the wrong call across a year. Every time the fast path wins, the concentration deepens. Nobody decided to hoard anything.

"You don't have a bus factor of one because someone hoarded knowledge. You have it because letting them do it was always faster than teaching anyone else."

Three other forces push the same direction. Deadline pressure removes the slack that pairing needs. Specialization is rewarded, so people deepen rather than broaden. And systems that are genuinely complex resist being explained quickly, which makes the explanation feel expensive every single time.

The DORA research puts a number on what good documentation is worth once it exists. In the 2022 State of DevOps Report, quality internal documentation acted as a multiplier on every technical capability measured. Teams practicing continuous delivery with above-average documentation saw a 656% lift to organizational performance, against 63% for teams whose documentation was below average. For trunk-based development the gap was wider still: 1525% versus 36%. Documentation was not the practice. It was what made the practices pay off.

How Do You Find Tribal Knowledge in Your Codebase?

Asking people what only they know does not work. The knowledge is invisible to its owner precisely because it feels obvious to them. Git history is the better instrument, because every commit records who touched what.

The signal is two dimensions crossed, not either one alone:

You can get a rough version of this from git directly. Run the first two and cross them by hand: a file near the top of the change-count list that also sits at one or two authors is your Critical quadrant.

# 1. Files changed most often in the last year
git log --since="1 year ago" --name-only --format="" \
  | grep -v '^$' \
  | sort | uniq -c | sort -rn | head -40

# 2. Distinct authors per file, fewest first.
# The awk pass tags each filename with the commit's author, so a file
# touched 50 times by one person still counts as one author.
git log --since="1 year ago" --format="@%an" --name-only \
  | awk '/^@/ {a=substr($0,2); next} NF {print a"\t"$0}' \
  | sort -u | cut -f2 \
  | sort | uniq -c | sort -n | head -40

# 3. For one file: who has touched it, and how often?
git log --since="1 year ago" --format="%an" -- path/to/file.py \
  | sort | uniq -c | sort -rn

The shell version gets you started and stops scaling quickly. It reads one repository at a time, treats a rename as a new file, and counts commits rather than weighing how much of the file each person actually wrote.

How Do You Reduce Tribal Knowledge Without Stopping Delivery?

The failure mode is a documentation sprint: two weeks of writing, a burst of pages, and no change to who can safely touch the payment service. Transfer happens through work, not through writing about work.

Four moves, in the order that costs the least delivery time:

The first move does the heaviest lifting and is the one teams skip, because it means deliberately giving a task to the slower person. That is the entire cost of fixing this, and it is paid one ticket at a time rather than in a quarter-long initiative.

"A wiki page is not knowledge transfer. A second person shipping a change to that file is."

Pair the routing change with review rules. If the same person authors and effectively rubber stamps everything in an area, review is not spreading understanding. Our guide on code ownership heatmaps covers reading ownership concentration across a repository, and the engineering enablement guide covers the org-level version of the same problem.

How Do You Know the Transfer Actually Worked?

Documents produced is the wrong measure. It counts effort rather than outcome, and it goes up whether or not anything changed. Three measures that respond to real transfer:

• Single-owner file count, trending down. The direct measure. Track it monthly on your highest-change files rather than across the whole repository, where noise from vendored code swamps the signal.
• Second-author coverage on critical paths. For each file you flagged Critical, has anyone else shipped a substantive change to it this quarter? This is binary and hard to game.
• Review distribution. If one person reviews every change in an area, they are still the single point of understanding even when others write the code.

Watch delivery speed alongside these. If cycle time degrades sharply while single-owner counts fall, you are routing too much work to unfamiliar people at once. Slow it down. The target is a steady decline over two quarters, not a step change. Code churn is a useful companion signal here, since a file being rewritten repeatedly by one person is usually a sign the understanding never spread.

One caution on framing. Every measure above describes files and review patterns, not people. The moment a single-owner count becomes something an individual is graded on, engineers will spread commits thinly to look diversified, and you will have destroyed the signal while making the underlying risk invisible. This is a property of the codebase, and it is a management outcome rather than an individual one.

Where Should You Start This Week?

Rank your highest-change files by contributor count and take the top five. For each one, ask who else has shipped a change to it in the last six months. Where the answer is nobody, route the next change in that file to a second person and have the current owner review it.

That single loop covers more ground than a documentation initiative, because it moves all four types of knowledge at once: the second person reads the archaeology, runs the operational steps, learns who to ask, and absorbs some of the craft through review. Repeat it five times a quarter and the concentration measurably drops.

For the file-level risk model behind this - the matrix, dormant risk, and how to run a quarterly review - see our guide on bus factor and knowledge silos.