What Is Tribal Knowledge?
The unwritten part of an engineering system: why it works this way, which constraint still bites, and who to ask. Plus how to stop losing it when people leave.
Tribal knowledge is the part of a system that is not in the code. Why a migration was abandoned. Which default will page you. The provider you tried, dropped after a compliance review, and still cannot go back to. The person who knows that the billing job must not run twice.
Some of that has been written down. A lot of it lives in a Slack thread, a closed ticket, or one engineer's head. It works fine until that person is on leave, or gone, and someone else has to change the system.
A practical test
Ask a new teammate to explain why a particular service still exists, or why a change that looks simple is not. If the answer is "ask Sam," you have tribal knowledge. If the answer is a page that also says who to ask when the page is wrong, you have started to make it institutional.
| Term | What it actually is |
|---|---|
| Documentation | What someone wrote on purpose, usually after the fact. Often incomplete, and it goes stale. |
| Tribal knowledge | What the team knows and has not put anywhere a stranger can find it. |
| Institutional knowledge | That same material, captured and attached to the system, the decision, or the incident it belongs to. |
About the phrase
People do search whether "tribal knowledge" is an offensive way to put it. The word can sound like it is borrowing something it does not own. In engineering it usually means the unwritten part, nothing more. If it bothers your team, drop it. The gap does not go away with the vocabulary. Institutional knowledge is the name for the same material once another person can find it.
How it disappears
- Someone leaves, and the oral history leaves with them. Exit interviews are too late. The context was specific, and by then they are already thinking about the next job.
- The decision happened in a thread. The thread scrolled. Three months later the team proposes the same approach and nobody remembers the failure.
- The incident writeup exists, in a folder nobody opens while they are designing the next change.
- The wiki has a page. The page says what the service does. It does not say why the obvious alternative was rejected.
How to stop losing it when people leave
While they are still here
- 1
Capture the durable sentence at the moment
The decision, the constraint, the "we tried this." Write it when the thread converges, not at the end of the quarter.
- 2
Attach it to something real
A service, a pull request, an incident. A note that is not attached to the thing it explains will not come up when someone is changing that thing.
- 3
Name the person as well as the fact
Ownership is part of the knowledge. "Billing owns this, and Priya has the context" is useful after Priya moves teams, because you know which history to recover.
- 4
Start from the next question, not a backfill
Documenting every decision the team has ever made is how the effort dies in week two. Write the next one. Write an old one when someone asks why.
Make the unwritten part findable
Prodigent keeps the why attached to the system it belongs to, so a new engineer is not reconstructing it from whoever is still around.
Try Prodigent free