Tribal Knowledge: What It Is and Why It Never Gets Written Down

Tribal knowledge is the working knowledge a company holds in people's heads rather than in its documents — the reasons behind decisions, the workarounds that keep a process running, the fact that the client in question does not read attachments and needs it in the email body.

It is not documented, and the standard explanation for that is that people are too busy or too careless.

That explanation is wrong, and it is why every documentation initiative in history has produced a burst of pages and then stopped.

What counts as tribal knowledge

The term covers four distinct things, which is part of why it is hard to address.

Procedural shortcuts

The official process takes eleven steps; everyone who has done it twice knows that steps four through seven can be done in one if you have the right access.

New joiners follow the eleven.

Decision rationale

The architecture is unusual because of a vendor constraint in 2023 that no longer applies.

The document records what was decided, not why.

Two years later someone proposes the obvious alternative and gets told "we tried that", without being told what happened.

Relationship knowledge

This customer's procurement lead approves anything under a threshold and escalates everything above it.

Nobody wrote that down; the account manager just knows.

Failure memory

The things that have already been tried and did not work.

This is the most valuable category and the least recorded, because failures are documented far less often than successes and the people who remember them leave.

Why it never gets written down

Four structural reasons.

None of them is laziness, which matters because the fixes aimed at laziness never work.

The knower does not know they know it

This is the largest single cause.

Expertise becomes invisible to the expert. Once something is obvious to you, it stops registering as information.

Ask someone to document their job and they will write the org-chart version, because the tacit parts do not surface as things worth saying.

Writing it down pays someone else

Documentation is a contribution to a shared resource with no individual return.

The person who writes the definitive onboarding guide is measured on something else entirely.

It is a gift, and gifts are given once, in a moment of enthusiasm, and not revised eighteen months later when the process changes.

It is only visible at the moment of use

You do not know the client needs it in the email body until you are writing the email.

That is exactly the moment you are least able to stop and document.

By the time there is time, the knowledge has gone back under.

Documenting it can reduce your standing

Rarely stated and often true.

Being the person who knows how the billing export works is a form of security.

Few people sabotage documentation deliberately, but almost nobody prioritises writing themselves out of relevance.

What it costs

The cost is real and diffuse, which is why it takes years to act on.

It shows up as onboarding that takes five months instead of three, because the written material covers the org-chart version of the job and the rest is learned by interruption.

As the same question answered four times in four channels.

As a customer commitment made in a call last March that nobody carries into the renewal.

As two teams building the same integration six weeks apart.

As a departure that removes a capability nobody knew was concentrated in one person until the week after they left.

None of it is a line item.

It presents as a general sense that the company is slower than it should be for its size.

For organisations trying to solve this systematically, the problem is closely related to internal knowledge management: the challenge isn't simply storing information, but making the knowledge people actually need available when they need it.

Why the usual fixes fail

Documentation mandates

Produce a burst of pages written to satisfy the mandate rather than to be read, then decay.

The mandate addresses the incentive problem by adding an obligation, which is not the same thing.

Wikis and knowledge bases

Solve storage.

Storage was never the constraint — authorship was.

An empty wiki and a full-but-stale wiki both fail for the same reason.

A traditional knowledge base can still be useful, particularly for information that is stable and deliberately maintained. But it cannot solve the capture problem by itself.

Exit interviews and handover docs

Too late by construction.

The knowledge you want is the knowledge nobody knew to ask for, and a leaving employee has neither the time nor the incentive to surface it.

Pairing and shadowing

Genuinely work, and do not scale.

They transfer tacit knowledge one person at a time, at the cost of two salaries.

What actually helps

Four things, roughly in order of how much they return.

Capture at the moment of use, not after

The only reliable time to record why something was done is while it is being done.

That means capturing where work happens — the thread where the decision was argued, the call where the constraint was explained, the ticket where the workaround was described — rather than asking for a summary afterwards.

This is particularly important for meetings.

A decision made verbally can disappear from the organisational record unless someone turns it into documentation. Tools such as Libra Meeting Assistant are built around capturing decisions, actions, owners, and the surrounding context rather than treating the meeting transcript as the end product.

Write down failures, deliberately

Most organisations record what was decided.

Very few record what was rejected and why.

A one-paragraph note on each discarded option is the highest-value documentation a team can produce, and it takes minutes.

Make the rationale a required field

Not a document — a field.

Any decision record that captures what without why will be re-litigated within two years.

The difference between:

"We chose vendor A."

and:

"We chose vendor A because it was the only option that supported our deployment requirement at the time."

is enormous.

The first records an outcome.

The second preserves the reasoning that makes the outcome useful.

Reward the answer, not the article

The person who answers the same question four times is doing the work.

If the fourth answer becomes the durable one automatically, you have solved the incentive problem without asking anyone to volunteer.

Where this connects to AI

The reason tribal knowledge is worth revisiting now is that the capture problem is the one that has actually changed.

Systems that read from where work already happens - documents, threads, tickets, recorded calls — can answer from material nobody was asked to write.

That does not make tacit knowledge explicit.

The thing in someone's head is still in their head.

But a great deal of what gets called tribal knowledge was in fact written down somewhere, once, in a channel nobody thinks to search.

Retrieval reaches that.

It does not reach the rest, and any vendor claiming otherwise is overselling.

This is the broader shift from a traditional knowledge base to an AI knowledge base: instead of relying entirely on people to create and maintain another repository, the system can work from information already produced through everyday work.

From tribal knowledge to company context

There is another important distinction.

Not everything useful needs to become a permanent document.

A Slack conversation might contain the answer to a question today and become irrelevant six months from now.

A meeting might explain why a decision was made without needing to become a 2,000-word article.

A customer email might contain relationship context that is valuable for the next renewal but not worth turning into formal documentation.

The goal is therefore not to turn every conversation into a document.

The goal is to make useful context retrievable when the work requires it.

That is increasingly the role of a company-wide context layer: connect the systems where knowledge actually lives and make that context available to the people and AI systems that need it.

Libra's Knowledge Base takes this approach by connecting the documents, conversations, and information teams already rely on. People can ask questions in plain language and get answers from those sources, with the underlying source attached.

The important distinction is that Libra is not claiming to extract everything from people's heads.

It is making the existing organisational record easier to access.

That is a much more defensible problem to solve.

And once that context is available, it can also be used by Libra AI Agents when they research, answer questions, and carry out work.