Tribal knowledge: why the people who know most can tell you least

What is tribal knowledge?

Every workplace runs on things nobody wrote down. Which supplier sends short pallets. Which of the two ovens runs hot. What the night shift does when a delivery is late. Who to call when the card reader freezes.

None of it is secret. It simply stays in people's heads — usually the people who have been there longest.

Most managers think the reason is that people are busy, or that they are protecting their jobs. Both happen. Neither is the main reason, and getting this wrong is why most attempts to write things down fail.

Why can't your best people explain their own work?

The clearest evidence comes from surgery rather than from office work. Researchers asked experts to describe a task they do every day. Then they watched them do it, and compared the two.

The experts left out about 70% of the decisions they made.

That is a measured number. One study counted 71% of the knowledge and 73% of the decisions missing. Another found about 70%. Each used a small group of experts, so treat the range as the finding rather than any single number.

Note what was missing. Not the physical steps — you can watch someone do those, and they describe them well enough. What disappeared was the thinking. Why they chose this rather than that. When they decide to stop. The exception they handle without noticing it is an exception.

The reason is simple. When you do something often enough, you stop noticing the choices you make. The expert is not hiding the moment when they glance at the colour of the seal before deciding. They truly do not feel themselves deciding. Ask them to write the procedure and they write the steps they still notice — which are the ones a beginner needs least.

Three things follow from this:

• "Just write it down" asks for something people cannot give. It is not that they refuse. The instruction assumes they can see their own thinking, and expertise is what removes that.
• One expert is not enough. You need three or four people describing the same job, because each one leaves out something different.
• Asking well gets you much more. In the same small study, prompting raised what people described from 44% to 66%. The method is what changed, rather than how willing anyone was.

Why is some of it tied to one place?

There is a second finding, and it is well supported. People get better with experience at a particular workplace. When they leave, that improvement stays behind.

This was studied in surgery. Surgeons got better as they did more work at one hospital. The work they did at other hospitals made no difference to their results at this one.

If you run several sites, this matters. Some of what your best site knows is knowledge about that site — its equipment, its layout, its customers, its neighbours. A single group-wide document will always miss it. That is exactly why site managers put group documents aside.

Local knowledge needs a home that belongs to the place where it is true.

How does knowledge move around today?

It already travels between locations with nobody managing it.

Researchers studied 36 franchise pizza stores. Knowledge moved between stores owned by the same person, and stopped at the boundary between owners. It travelled through managers who talked to each other.

That is worth sitting with. Your knowledge flows wherever people talk, and stops where they stop. Anyone with a small network — a new starter, a night-shift worker, someone who shares no first language with the group — sits outside it. Being on the org chart changes nothing.

Which numbers can you trust?

You will see it claimed that employees spend two and a half hours a day, or a fifth of the working week, looking for information.

Leave those alone. The first comes from a 2001 paper paid for by a search-engine company, where the number was an assumption fed into a cost model rather than something anyone measured. It got quoted back later as a finding. The second is a 2012 consultancy estimate with no stated method, about office workers rather than frontline staff. Nobody has properly measured how long frontline people spend searching. A board paper quoting one of these invites somebody to check.

Here are three things you can say honestly instead. All of them are more concrete:

Why do documentation efforts stall?

Most organisations have tried this before. Knowing what went wrong last time is the first step to it working this time.

Why do written procedures gather dust?

A library of lessons learned usually becomes a place where things are put rather than a place where things are found. Writing is an event with a deadline. Reading is a habit nobody puts in the diary.

Why does search fail when people use their own words?

A document gets its title from the organisation. A person searches in their own words.

"Incident Handling Timelines" sits in the library while somebody types "when will my issue be fixed?". The two never meet.

This is nobody's fault, and it is entirely predictable. Expecting the reader to guess the author's words is the part you can design away.

Why does writing things down feel risky?

If being the only person who knows something keeps you safe, writing it down gives that away. The research here is thinner than the feeling — mostly people reporting on themselves, mostly in office jobs — so treat it as likely rather than proven. A poster about sharing knowledge will not shift it.

What does shift it: making it quick, and asking at a moment when the person is already thinking about the problem.

Does a written procedure change what people do?

This is the most sobering evidence here.

Surgical safety checklists produced large improvements in one well-known study across eight hospitals. When the same thing was measured across 101 hospitals and roughly 216,000 operations, the effect was gone.

The lesson travels. A procedure that exists and a practice that changed are two different things. Judge your work on whether the problem got smaller, rather than on how much you wrote.

What actually works?

Ranked by how strong the evidence is, which is different from how often these appear on a checklist.

Capture it while the problem is being solved

This is the most important idea here. People can reach their own knowledge while they are using it — while finding the fault, handling the complaint, deciding to stop the line. An hour later it has sunk again. A week later, in a workshop, they will give you the steps and leave out the thinking.

Everything below is a way of getting the writing to happen close to the doing.

Run short reviews after things happen

A short review after an event — what should have happened, what did happen, why the difference, what we do next time — has real evidence behind it. A review of 46 studies found teams that did this performed meaningfully better than teams that skipped it.

The average session lasted about eighteen minutes. Longer sessions did no better than short ones.

Eighteen minutes. This is a habit rather than a programme, and it gives you more than anything else on this list.

Use three or four people, and prompt them

When you do sit down to capture something, ask specific questions rather than open ones, and use three or four people rather than the one who knows most.

Ask about decisions and signs. What made you choose that? What would have made you do something else? What does it look like just before it goes wrong? Those questions reach the thinking. Asking for steps gets you steps.

Write in answer to a real question

A document written to answer a question somebody actually asked gets found and gets used. A document written in advance to cover a topic is a guess about what people will ask, written in the author's words.

This also solves the risk problem quietly. Answering a colleague's question is already a normal part of the job.

Match the words people search with

Since people search in their own words, the system has to bridge that gap rather than the reader. Matching on the question rather than on words in the title is what follows from that.

One honest note: nobody has run the direct comparison. The reasoning rests on the evidence about vocabulary rather than on a trial.

How software closes the loop

Two different things solve two halves of the problem. The value shows up when they run together.

Half one: documents that belong to a place

Documents placed in the part of the organisation they belong to, readable by the people who work there. Three things matter for tribal knowledge:

They belong to a place. Local knowledge gets a home. A document connected to your Oslo site is the Oslo answer, and it stands on its own. Connect one document to several sites and it stays one document, kept up to date once.

They are found by the question. Published documents are indexed by the questions they answer, so the system bridges the vocabulary gap rather than the reader. When a good document goes unfound, editing that list of questions is the fastest fix there is.

Answers come back written out, with sources. Somebody asks in their own words and gets a written answer built from your own documents, with links to them. That is what turns a library into something people use.

Documents can also point at each other, and the assistant follows those links both ways. A local procedure linked to the group policy behind it usually produces an answer containing both — so the why travels with the how.

Half two: briefings that show what nobody saw

On a schedule, for a chosen group and a chosen part of the organisation, the platform reads what people actually recorded — reports filed, checklists completed, tasks assigned — and writes a briefing in prose. Sections with names, rather than a dashboard.

It names patterns and counts them. "This happened eleven times, mostly on Fridays, mostly at two sites" is something nobody in the organisation knew. It was spread across eleven separate reports filed by people who never spoke to each other.

Part of it is arithmetic. Counts, comparisons with last period and unusual cases are worked out in code before anything is written. The words sit around those numbers. That is what makes a briefing something you can quote in a meeting.

It suggests what to do next. Suggestions for a person to accept or reject. The judgement stays with the manager.

What each half is for

Each half leaves a gap. Documents only capture what someone already knew to write down, which leaves out most of the thinking. Briefings show what was happening across people who never compared notes, though they describe the problem rather than the answer.

The loop, in six steps

This is where the two halves add up to more than the sum.

1. A pattern shows up. The briefing names something that keeps happening — the same problem at two sites, the same checklist step failing on the same shift.
2. Somebody who knows the answer gets asked. Usually a supervisor, and usually they do know. This is the moment that matters: they are thinking about the problem right now, because the briefing just put it in front of them.
3. The answer gets written once, as a short document, for the place it applies to, in reply to a question that really did get asked.
4. It gets linked to the policy behind it, so the why travels with the how.
5. The next person who asks gets it — in their own words, from the assistant, with the source attached. They never need to know it exists.
6. The next briefing shows whether the problem got smaller. Which is the only honest test of whether the document changed anything.

Then round again next period.

Why the loop beats either half alone

That last row is the one to understand. The briefing is the prompt that research says recovers missing knowledge.

Ask an expert to document their expertise and you get steps. Ask them "this happened eleven times last month, mostly on Fridays — why?" and you get the part that matters, because the question does the remembering for them.

Making it a routine

• One standing item on a meeting you already hold: "Which pattern this month deserves a document?"
• One document per period. Twelve short documents a year, each answering something that really happened, beats a two-hundred-page manual.
• Name the writer in the meeting and give them twenty minutes. A short document by the person who knows beats a long one by whoever had time.
• Read the unanswered questions. The list of questions the assistant found nothing for is a writing queue in your people's own words.
• Check what is going unread before you write more. A document that should be in daily use and never gets opened has a finding problem rather than a coverage problem. Fix the questions it is indexed against.
• Say out loud when it works. When a problem gets smaller, mention it in the same meeting. That is what makes the fifth person willing to write the sixth document.

What this changes for new starters

Tribal knowledge and the cost of onboarding are the same problem from two ends.

A new starter spends their first weeks finding out what everyone else already knows. Every question they ask a colleague costs twice — their time and the colleague's. The people with the smallest networks get the worst of it. In frontline work that usually means the young, the newly arrived, and part-time staff.

• They have somewhere to ask when nobody is around. In their own words, in their own language, at three in the morning on a night shift.
• They get your answer, for their own site, from your own documents, with sources so they can check.
• The avoidable interruptions stop. The tenth person asking where the spare filters live can find out without a colleague.
• Documents get written for the questions new people really ask, because those questions show up on the unanswered list rather than disappearing.

Honest boundaries

• Software can tell you a document is being read. It cannot tell you it is correct. An out-of-date procedure gets quoted with full confidence. Keeping documents current stays a human job.
• It only knows what people recorded. Briefings read what was filed. Work nobody recorded stays invisible.
• A briefing describes rather than diagnoses. The counts are worked out in code. The reading of them is words, and the suggestions are suggestions. The judgement stays with the manager.
• People still write the documents. This takes away the guessing about what to write, rather than the writing.
• The 70% applies to your writers too. Expect the first draft of any procedure to be missing most of the thinking. Have a second person who does the job read it before it goes out.
• Writing it down and changing what people do are two different achievements. Judge the work on whether the problem got smaller.
• Every number in your case should be your own. There are no trustworthy outside benchmarks for search time or documentation in frontline work.