How to Document Tribal Knowledge

What Tribal Knowledge Is and Why It's a Problem

Tribal knowledge is the informal, unwritten knowledge that exists within a group — the way things are actually done, as opposed to the way they're officially documented; the implicit assumptions that experienced members share without ever discussing; the context behind decisions that only the people who were present understand.

The term comes from anthropology: knowledge passed within a tribe through direct participation and oral tradition rather than through formal documentation. In organizational contexts, it's the knowledge that exists in the informal network of experienced employees and isn't findable in any document.

Tribal knowledge is valuable — it represents accumulated learning, refined practices, and contextual judgment that formal documentation rarely captures. The problem is its distribution: it's accessible to people within the tribe (the experienced team members who were present for the accumulation) and invisible to people outside it (new employees, adjacent teams, people who were hired after the knowledge was formed).

This creates organizational inequality: experienced members can do things that newer members can't — not because they're more capable, but because they have context that isn't available. It creates vulnerability: when experienced members leave, they take the tribal knowledge with them. And it creates inefficiency: the same implicit knowledge has to be re-transmitted to every new person through informal socialization — a slow, inconsistent, and lossy process.

Documenting tribal knowledge converts it from informal to formal — accessible to everyone, not just to the tribe's members.

---

The Challenge: Expert Blind Spot

The fundamental challenge in documenting tribal knowledge is what cognitive scientists call the "curse of knowledge" — the difficulty experts have in understanding what it's like not to know what they know (Camerer, Loewenstein, Weber, 1989, Journal of Political Economy).

Experts filter unconsciously. They've internalized the implicit knowledge so thoroughly that it doesn't register as knowledge — it registers as obvious. When asked to explain how they do something, they explain the parts that feel non-obvious to them, not the parts that are obvious to them but non-obvious to a beginner.

The result: documentation written by experts alone systematically omits the tribal knowledge that makes the difference between a functional explanation and a usable one. The expert writes "negotiate the contract terms" without noting that you always give the legal team 10 business days for review, that the finance director has approval authority up to $50,000 but anything over requires the CFO, and that the vendor's standard payment terms are 30 days but they'll extend to 60 if you ask. These facts feel too obvious to mention. To a new employee, they're invisible walls.

This is why documenting tribal knowledge requires a process specifically designed to surface the implicit — not just asking experts to write documentation, but actively mining the knowledge that they don't know they have.

---

The Interview Method: Questions That Surface Implicit Knowledge

The most reliable method for extracting tribal knowledge is the structured interview: a non-expert asks questions designed to surface what the expert takes for granted.

Setup: The interviewer is ideally a new employee or someone unfamiliar with the domain — someone who genuinely doesn't know the implicit knowledge. The interviewer asks questions; the expert answers. The exchange is recorded or transcribed. The documentation is built from the answers.

The question framework:

Process questions (to surface the unofficial how):

• "Walk me through exactly what you do when [common scenario X]. Don't skip any steps even if they seem obvious."
• "What's the first thing you do when [this situation] comes up? And then what?"
• "What would you do if [step Y] didn't work? What's your fallback?"

Heuristic questions (to surface the rules of thumb):

• "How do you know when it's time to do X vs. Y?"
• "What's your rule of thumb for [decision type]?"
• "When would you not follow the standard process? What would make you handle this differently?"

Warning questions (to surface the things that go wrong):

• "What's the most common mistake someone new to this area makes?"
• "What's the thing that looks fine but causes problems later?"
• "What do you wish someone had told you about this when you started?"

Network questions (to surface relationship knowledge):

• "Who do you contact first when [problem type] comes up?"
• "Who has the real decision authority here? Is that the same as the official authority?"
• "Who do you go to for X, even if that's not their official role?"

History questions (to surface context):

• "Why does this process work the way it does?"
• "Has this ever been done differently? Why did it change?"
• "What's the backstory on [policy/decision X]?"

The interviewer should ask "why?" and "then what?" repeatedly. The expert's first answer is usually the official version; the follow-up questions surface the implicit.

---

The Shadowing Method

Some tribal knowledge is procedural and tacit — it's embedded in how a task is performed, not in what can be articulated about it. For this kind of knowledge, an interview doesn't fully work. Shadowing does.

Setup: The non-expert (documenter) observes the expert performing a real task. The documenter's job is to ask "what are you doing?" and "why?" at every step that isn't immediately obvious.

What to capture:

• Every micro-decision the expert makes without explicitly deliberating ("I always check this field first because...")
• Every workaround the expert uses without mentioning it as a workaround ("The system gives you the wrong total here, so I always recalculate it manually")
• Every informal contact the expert reaches out to during the process
• Every place the expert uses a different tool, shortcut, or approach than what the documentation says

The non-expert's advantage: The non-expert sees what the expert is blind to. The expert navigates around a system bug without noticing; the non-expert asks "why did you do that?" The expert consults a spreadsheet that isn't in any documentation; the non-expert asks "what's that?"

Recording the session: Permission-allowing, recording the shadowing session (screen capture or video) produces raw material that can be reviewed for implicit steps. Watching the recording, a documenter can often identify implicit steps that weren't noticed during the session itself.

---

The "What I Wish I'd Known" Document

A specific documentation artifact that captures tribal knowledge efficiently: ask experienced team members to write, from memory, what they wish they'd known when they were new.

This prompt is more effective than "document your process" because it reactivates the experience of not knowing — it invites the expert to empathize with the beginner rather than describing from the expert's current vantage point.

Prompt: "Write 500-1000 words about what you know now that you wish you'd known in your first 90 days. Include: the non-obvious things, the mistakes you made, the relationships that matter, the shortcuts that work, the things that look right but aren't."

Aggregate and edit: Collect "what I wish I'd known" documents from several team members. The themes that appear across multiple documents are the highest-value tribal knowledge — the things that consistently trip up newcomers. Synthesize these into a team knowledge document that makes the collective tribal wisdom explicit.

---

Structuring the Documentation

Tribal knowledge documentation serves a different purpose than procedural documentation. The goal is not step-by-step instructions — it's context and insight that helps someone navigate situations the official documentation doesn't cover.

Effective structure:

The unofficial how-to: The actual way the task is done, distinct from the documented way. "The official process says to submit via the portal, but in practice, you'll get a faster response if you email [name] directly and CC the portal submission."

The exceptions map: When does the standard process not apply? What are the edge cases that experienced members handle differently? "This process is for orders under $10,000. For larger orders, see [name] before starting — there are different approval requirements that aren't documented anywhere."

The who-to-know map: The informal network that gets things done. "For anything urgent related to inventory, call [name] directly — she has the authority to expedite even if her title doesn't suggest it. The official contact list has her manager but she's the one who actually knows what's in stock."

The context archive: The history and reasoning behind current practices. "We don't use automatic email reminders for overdue invoices — we tried it in 2023 and two customers escalated it as harassment. Check in manually instead."

The common mistakes glossary: The errors that newcomers consistently make and that experienced members recognize immediately. "New people almost always misread the 'net amount' field as the total due — it's actually the pre-tax amount. The 'total due' is two rows down."

---

Prioritizing What to Document First

Not all tribal knowledge is equally valuable to document. Prioritize by:

Risk of loss: Tribal knowledge held by one or two people who are likely to leave in the near term is the highest priority. "What would break if [specific person] left tomorrow?"

Frequency of relevance: Knowledge that's needed every week is higher priority than knowledge that's needed once a year. Track what questions get asked repeatedly — those questions are the highest-value documentation targets.

Cost of being wrong: Tribal knowledge where incorrect assumptions lead to costly errors (compliance violations, customer damage, financial loss) is higher priority than knowledge where errors are easily corrected.

New employee friction: Tribal knowledge that consistently creates friction for new employees — the things that come up repeatedly in the first 90 days — is high priority because its documentation has immediate ROI in every subsequent hire.

---

Worked Example: A Sales Operations Team's Tribal Knowledge Sprint

Setup: A 10-person sales operations team. They've been together for 4+ years, have lost 3 members in the last year, and are about to hire 4 new members. The team lead recognizes that what makes their veterans effective is largely undocumented — it lives in their heads and in informal conversations.

What they do:

Week 1 — Identification: Each team member writes their "what I wish I'd known" document. The team lead reviews all 10 documents and identifies 23 distinct themes that appear in multiple documents. The highest-frequency themes: understanding which customer segments get different pricing approaches; how to navigate the CRM's non-obvious fields; when to escalate vs. resolve independently; the 4 vendors who require special handling.

Week 2 — Documentation sprint: Four experienced team members pair with two new employees (who just joined). The new employees interview the experienced members for 90 minutes each. The interviews are transcribed. The transcriptions produce 12 draft documentation pages.

Week 3 — Review and polish: The draft pages are reviewed by the experienced members for accuracy and by a new employee for comprehensibility. Where the new employee still has questions after reading a page, the page is clarified.

Result: 12 pages of tribal knowledge documentation. The new members who helped create it have absorbed the knowledge more deeply than they would have from reading documentation alone. The team lead estimates 3 fewer weeks of onboarding friction per new hire going forward.

---

Keeping Tribal Knowledge Documentation Alive

Tribal knowledge documentation has the same maintenance risk as all documentation: it drifts from reality as the team's practices evolve.

The mechanism that keeps it current: the same contribution norm that creates it. When a tribal knowledge gap is discovered — a new employee asks "why do we do it this way?" and the answer is "just how it's always been done" — documenting the answer is the next step. When a process changes and the tribal knowledge that used to be right is now wrong, the documentation is updated.

The quarterly review (see the team wiki maintenance practice) catches drift: a team member reads each tribal knowledge page and asks "is this still how we actually do it?" Changes to the answer update the page.

---

Key Takeaways

1. Tribal knowledge documentation requires deliberately surfacing the implicit: asking experts to write documentation produces the explicit knowledge they're aware of; the structured interview, shadowing, and "what I wish I'd known" prompt surface the implicit knowledge they've forgotten they have.
2. The non-expert is the key to the documentation: the curse of knowledge makes experts blind to what they know; a non-expert who asks "why?" and "then what?" surfaces knowledge the expert doesn't know to share.
3. Prioritize by risk of loss and new employee friction: knowledge held by one person likely to leave, and knowledge that consistently trips up newcomers, are the highest-value documentation targets.
4. The "what I wish I'd known" prompt reactivates beginner perspective: it's more effective than "document your process" because it invites empathy with the newcomer rather than description from the expert's vantage point.
5. The process produces both the document and the knowledge transfer: the interview and shadowing sessions are themselves knowledge transfer — the new employees who participate in creating the documentation learn more deeply than those who only read it.

---

Conclusion

Tribal knowledge is the accumulated intelligence of an experienced team — valuable, hard to replace, and invisible to anyone outside the inner circle. Documenting it is not a one-time project; it's an ongoing practice of making the implicit explicit, one interview, one shadowing session, and one "what I wish I'd known" document at a time. Teams that develop this practice build an organizational intelligence that doesn't walk out the door with any individual, that reduces the gap between experienced and new members, and that makes the institutional wisdom of long-tenured employees available to everyone who joins after them.

For more on this, see Building a Personal Knowledge Base.