What is tribal knowledge? The hidden cost to growing teams

A new account manager joins on Monday. By Wednesday she has asked in Slack why one of your biggest customers gets a custom renewal date. Three people see the question. Two shrug. The third, who agreed to the terms a year ago, is out for the week. So she waits, the renewal call slips, and the answer that existed the whole time stays locked in one person's head.

That is tribal knowledge, and most growing companies run on more of it than they realize. This post covers what tribal knowledge is, what it costs once you pass ten or fifteen people, why the company wiki rarely fixes it, and what does.

What is tribal knowledge?

Tribal knowledge is undocumented company information that exists only in employees' heads, not in any system, wiki, or policy doc.

It moves by word of mouth, and it walks out the door when someone takes a new job. It shows up in every team:

• Sales: the verbal discount a founder promised a key account, with no record of the terms.
• Engineering: why the staging deploy needs a manual approval step that one person added eight months ago.
• Support: the unwritten exception to the refund policy that only the longest-tenured rep knows.

A five-person team barely notices. Everyone sits in the same conversations, so everyone knows roughly the same things. The trouble starts as you grow. Past fifteen people, no one sits in every conversation anymore, and "just ask around" becomes a daily tax on everyone's time.

Where does the term "tribal knowledge" come from?

The term tribal knowledge comes out of manufacturing, where quality engineers used it for the process steps that lived in operators' heads instead of in the work instructions. Six Sigma programs treated it as a source of defects: if the night shift runs the machine differently because "that's how Dave does it," the output varies with the shift. The software and knowledge-work version is the same problem with different furniture. The undocumented step is a deploy quirk or a customer agreement instead of a machine setting.

Some teams prefer a different name for it. Institutional knowledge, undocumented knowledge, and tacit knowledge all describe close cousins of the same thing, and "undocumented institutional knowledge" is the most neutral label if tribal knowledge reads as dated to you. The vocabulary matters less than the pattern: knowledge your team depends on that exists only in people's heads.

What are examples of tribal knowledge?

Tribal knowledge shows up as the small, undocumented facts each team relies on every day. A few that will look familiar:

• Sales: why your biggest account has a custom renewal date, and which discounts the CFO will actually approve without a meeting.
• Engineering: the deploy step that has to be run by hand, and why one service stays pinned to an old library version that nobody dares upgrade.
• Support: the workaround for the bug that has been open since spring, and which two customers get escalated straight to a founder.
• Ops and finance: how to fix the invoice that fails every month, and which contact at the vendor answers within a day.

None of these appear in a handbook. Each one costs somebody a question, a wait, or a mistake when the person who knows is unavailable.

What does tribal knowledge cost your team?

The cost is larger than it looks, because most of it hides inside normal-looking workdays.

Start with time. A 2012 McKinsey study found that employees spend an average of 1.8 hours every day, around 9.3 hours a week, searching for and gathering information. That is close to a full day each week per person spent hunting for things other people already know. Part of the reason is fragmentation: in one 2024 survey, 60% of employees said they search across four or more separate tools to find what they need. Each of those tools is its own knowledge silo, holding a slice of the answer the others cannot see.

Onboarding takes the first hit. A new hire spends weeks rebuilding context that already exists, one Slack question at a time, and every answer they get is an answer someone else stopped working to give.

The same questions come back over and over. How do I get access to the analytics dashboard? What is our refund policy for annual plans? Who signs off on a new vendor? Your team answers these dozens of times a month, and the answers never collect anywhere. (For the full playbook on breaking that loop, see our guide on how to stop answering the same questions.)

Knowledge turns into a single point of failure. When one person holds the only copy of how something works, their vacation becomes a bottleneck and their resignation becomes a crisis. You end up one departure away from losing how a core part of the business runs.

There is a morale cost too. In that same 2024 survey, 31% of people said failing to find information left them burned out, and 16% said it made them want to leave. The hunt does not just waste time. It wears people down.

Tribal knowledge vs. institutional knowledge

People use the two terms interchangeably, but they are not the same. Institutional knowledge is everything a company has learned over time, including the parts written down in docs, processes, and systems. Tribal knowledge is the slice of institutional knowledge that never got captured and lives only in people's heads. All tribal knowledge is institutional knowledge. The reverse is not true, and the gap between them is exactly the risk you are trying to close.

Is tribal knowledge always bad?

No. Tribal knowledge is a byproduct of people getting good at their jobs, and much of it never needs writing down. The judgment a senior engineer applies in a code review does not belong in a wiki.

It turns into a risk at three specific moments: when someone leaves, when someone joins, and when the team grows past the point where everyone can ask everyone. A 2018 Panopto and YouGov study put a number on the first of those: 42% of institutional knowledge is unique to the individual who holds it, meaning nearly half of what your team knows walks out with the person who knows it. The goal is never to document everything. It is to capture the part other people repeatedly need.

Why doesn't the company wiki fix it?

The standard answer is "write it down." Spin up Notion, ask everyone to document their area, and the problem solves itself.

It rarely does. Documentation competes with the real job, so it loses every time. Someone writes a page once, the process changes, and no one goes back to update it. Six months later you have a wiki full of pages that are half right, and half right is worse than empty, because a reader cannot tell which half they are looking at. So they stop trusting the wiki and go back to asking a human.

Notion, Confluence, and Google Drive are good at storing what someone took the time to write. They do nothing about the knowledge no one wrote down, and they cannot tell you when a page has gone stale. The gap between what your team knows and what your tools hold stays exactly as wide as it was.

So the real challenge is capturing the knowledge in people's heads without turning everyone into a part-time technical writer.

How do you capture tribal knowledge?

The fix has three parts, and they have to work together. (For a step-by-step process, see our guide to documenting tribal knowledge.)

1. Answer from what is already written. Most questions have an answer sitting in a Slack thread, a Notion page, or a doc in Drive. The work is finding it across all of those places, the job of workplace search, and returning it in plain language with a link to the source, so the asker can check it. Done well, that gives your team one search bar for all your work tools instead of five, and it alone clears out a large share of the repeat questions.
2. Ask the person who knows when the answer is not written down. This is the part wikis miss. When the new account manager asks about that custom renewal date and no document covers it, route the question to the person who set it up, capture their answer, and save it into your internal knowledge base. The question gets answered once by a human and never needs a human again.
3. Keep the knowledge honest over time. Information goes stale. Whatever holds your knowledge should flag when two sources contradict each other and send the conflict to the right person to settle, so the renewal terms do not rot the way the old wiki did. Our knowledge base audit workflow runs exactly this check on a schedule: it flags outdated and contradictory pages and routes each fix to the person who knows.

Captured knowledge only pays off if people can query it, and that is the job of an AI knowledge base. This is the model Agentwork is built on: it answers from the tools you already use, asks the person who knows when something is undocumented, and keeps the answer for the next person.

How to start capturing tribal knowledge

You do not need a documentation overhaul to make progress this quarter.

1. Map your most expensive knowledge. Pick the role where lost context hurts most, usually a new hire or a support rep, and write down the ten questions they ask in their first month. That short list is your map.
2. Answer those ten where people can find them. Put the answers somewhere the team actually looks, then watch how many repeat questions disappear. (For a deeper version of this, see our guide to onboarding documentation.)
3. Find your single points of failure. Notice which questions still route to one person every time. Those make the strongest case for a system that captures an expert's answer the first time rather than the fifth.

Tribal knowledge builds up in every team that grows faster than it can write things down. The teams that stay fast are the ones that stop depending on who happens to be online and give the company a way to answer for itself.

How do you prevent tribal knowledge from building up?

You prevent tribal knowledge by making documentation a byproduct of normal work. Three habits do most of it:

• Answer in public channels, and not in DMs. A question answered in a searchable thread helps the next person who has it. The same answer in a private message helps one person once.
• Write decisions down when you make them. Two lines on why you chose a vendor or pinned a version costs a minute now. Reconstructing the reasoning a year later costs an afternoon, and the answer is usually a guess.
• Treat every absence as a test. When someone is on holiday, keep a list of the questions that had to wait for them. That list is your capture backlog, ranked by how often the team actually needed each answer.

You will never prevent all of it, and as covered above, you should not try. The aim is that what your team repeatedly needs gets written the first time it comes up, and everything else stays comfortably in people's heads.

Frequently asked questions

What is an example of tribal knowledge?

A salesperson knowing a key account was verbally promised a discount that appears in no contract. Other common examples: the engineer who is the only one who knows why a deploy needs manual approval, or the support rep who knows an unwritten exception to the refund policy. In each case the information is real, the company depends on it, and it exists only in one person's memory.

What is the difference between tribal knowledge and institutional knowledge?

Institutional knowledge is everything an organization has learned, including what is documented. Tribal knowledge is the undocumented part that lives only in people's heads. All tribal knowledge is institutional knowledge, but most institutional knowledge has been written down somewhere. Tribal knowledge is the slice that has not.

What is tacit knowledge vs. tribal knowledge?

Tacit knowledge is know-how that is hard to write down at all, like judgment or a learned skill. Tribal knowledge is information that could be documented but never was. The fix differs: tacit knowledge usually needs mentoring and practice, while tribal knowledge mostly needs a reliable way to capture answers the first time someone asks.

Why is tribal knowledge a problem for growing companies?

Small teams share context by default because everyone is in the same conversations. Past roughly fifteen people that breaks down, so work stalls while people hunt for answers others already have, onboarding drags, and any one person's absence can block the team. The cost scales with headcount.

How do you capture tribal knowledge?

Answer questions from what is already written across your tools, ask the person who knows when something is undocumented and save their answer, and flag contradictions so knowledge stays current. The goal is to capture each answer once, the first time it is asked, rather than relying on people to document everything up front.

Who usually holds tribal knowledge?

The longest-tenured people: founders, early employees, and whoever everyone tags in Slack when something breaks. If one name comes to mind for your team, that person is a single point of failure for everything only they know.

What is a better word for tribal knowledge?

Institutional knowledge and undocumented knowledge are the common alternatives, and tacit knowledge is the academic term for know-how that resists writing down. They overlap heavily; pick the one your team finds clearest.

---

If your team is still answering the same questions week after week, Agentwork connects the tools you already use and captures answers the first time, so you stop losing knowledge every time someone is out of office.