Tribal knowledge vs tacit vs institutional knowledge: what plants lose when experts retire

Every plant has a few people everyone calls when something looks wrong. They know why one line runs differently, which customer will accept a borderline result, and what that odd reading in March usually means.

None of that is in the system. When they retire, it retires with them.

Three terms get used for this kind of knowledge: tribal, tacit and institutional. They are often treated as synonyms. They are not, and the difference decides what you can actually capture.

What is tribal knowledge?

Tribal knowledge is know-how that a team shares and relies on but has never written down. It lives in conversations, habits, email threads and the memory of the people who were there.

It is not secret, and it is not always hard to explain. It is simply undocumented: the team knows it, the systems do not.

Tribal knowledge vs tacit knowledge vs institutional knowledge

Tacit knowledge is the older idea. The philosopher Michael Polanyi described it in the 1960s as knowing more than we can tell: the expert who recognises a problem long before they can explain the rule they used.

Institutional knowledge is the opposite end. It is everything the company has already recorded: in the enterprise resource planning (ERP) system, the laboratory information management system (LIMS), the quality management system (QMS) and the standard operating procedures (SOPs). The catch is that records keep the what (the spec, the deviation, the corrective action) and drop the why.

Tribal knowledge sits between them, and it is the part most worth fighting for. It is documentable in principle, it is shared across a team rather than locked in one head, and almost nobody captures it, because it never feels urgent until the person who knows it hands in their notice.

Is “tribal knowledge” an offensive term?

Some people find the phrase uncomfortable because it borrows the word “tribal” from a context that has nothing to do with factories. Alternatives you will hear include undocumented know-how, team knowledge and institutional memory.

We use “tribal knowledge” in this article because it is the term most plant and quality teams use when they search for the problem. Use whichever term your organisation prefers. The problem is the same either way.

What tribal knowledge looks like in a batch plant

In specialty chemicals, coatings and pharma manufacturing, the undocumented layer tends to fall into eight kinds:

1. Formulation nuances: why one plant needs lower spray pressure.
2. Strategic context: the customer and platform priorities that will drive future procurement.
3. Plant-specific quirks: substrate anomalies, HVAC drag-out effects.
4. Seasonal defect patterns: the March HVAC cycle that leads to silicon contamination.
5. Relationship politics: who to call at 9pm, versus who to call 9 to 5.
6. Verbal agreements: deviations approved during a changeover and never documented.
7. Cross-account learning: a defect at one plant that is the same failure another plant solved three years ago.
8. Failure-pattern diagnostics: cratering on the B-pillar in winter is 80% compressed air contamination.

Read that list again and notice how little of it is truly tacit. Almost all of it could be written down. It just lives in the wrong places: an inbox, a notebook, a meeting nobody minuted, and the memory of one or two specialists.

Why it walks out the door when experts retire

The usual answer is to hire. It rarely works.

• The talent does not exist. A PhD-level chemist with a decade of account history is not on the market.
• Ramp-up is slow. New hires take 12 to 24 months to get up to speed.
• Parallel hires create parallel silos. Two people now each hold half the picture.

The cost shows up in specific moments: a customer complaint nobody can trace, an after-hours escalation with the one specialist unreachable, or a supplier visit where the context from the last five visits is gone. And when a competitor keeps its relationship continuity through a personnel change while you lose context, it can knock you off an approved-supplier list that took a decade to win.

Why documentation projects alone do not fix it

Most plants have tried the wiki, the handover template or the exit interview. They help, and then they go stale, for three reasons:

• The knowledge is spread across systems. The real story behind a deviation runs from a batch record in the ERP, to a test failure in the LIMS, to a corrective action in the QMS, to an email, to a document from another plant two years ago, to a verbal agreement made during a customer visit. A wiki page captures one link of that chain.
• Writing it down is a second job. Specialists are the busiest people in the plant. Asking them to re-type what they know competes with the work only they can do.
• Nobody can find it when it matters. Knowledge that exists but cannot be retrieved in the moment of a complaint or an escalation is, in practice, lost.

How to capture tribal knowledge before it leaves

A workable approach starts from exposure and ends with a question someone can actually ask.

1. Map your exposure. Which accounts, which products and which plants depend on one or two people? Which of their knowledge is undocumented today? Start where losing a person would hurt most.
2. Capture it where it already lives. Most tribal knowledge has left a trace: emails, meeting notes, deviation records, lab reports, complaint files. Connect those sources instead of asking people to re-type them.
3. Record the “why”, not just the “what”. In interviews and reviews, ask why a value was accepted, why a deviation was approved, why one plant does it differently. The reasoning is the part institutional records drop.
4. Make it answerable in plain language. The test is whether a newer engineer can ask “We are getting hazy clear coat on a dark metallic. What causes this?” and get an answer drawn from the history, not from a search results page.
5. Keep it inside your boundary. Account knowledge, formulations and plant data are exactly what customer and supplier quality agreements protect. Capturing it into a tool that sends it to a third-party cloud trades one risk for another.
6. Test it against real questions. Collect the questions your specialists answer every week and use them as the acceptance test. If the system cannot answer them, it has not captured the knowledge.

Where a Knowledge Twin fits

A Knowledge Twin is a governed, queryable model of a domain’s knowledge: an account, a plant or a lab. It connects the documents, records, emails and notes where tribal knowledge already lives, maps the entities and relationships between them, and lets anyone with the right access ask questions in plain language.

It runs on a sovereign platform inside infrastructure you choose. The language model behind it is a replaceable component, so the knowledge you capture stays yours when models change. Swap the model, keep the business.

Deployed at a global coatings manufacturer serving automotive OEMs across 70+ plants, the before and after looks like this:

Account knowledge is one starting point, not the limit. The same platform runs analytical lab reports and BOM extraction in production today, and Knowledge Twins can be scoped to whichever domain your own use case needs. See how the Knowledge Twin works.

What happens when your specialist is unreachable? Book a demo and start from your own exposure: which accounts, which people, and which knowledge is undocumented today. Or see where the return sits on the AI ROI Map.