Tribal knowledge is the part of a software system that exists only in conversation and memory.
It's why one engineer knows not to change a harmless-looking timeout. It's the abandoned implementation that isn't mentioned in the README. It's the production failure everyone remembers but nobody wrote down. It's the answer to “why does this work this way?” when the repository can only tell you what is there.
That knowledge isn't unusual. Even disciplined engineering organizations create information faster than they can formally document it. The problem starts when important context remains concentrated in a few people and the rest of the team has no reliable way to recover it.
Google's SRE organization has described documentation partly in these terms: operational documents help capture tribal knowledge so it becomes discoverable, searchable and maintainable rather than remaining dependent on individual memory. ACM Queue's Why SRE Documents Matter explains the role of documentation in preserving that knowledge.
The goal, though, isn't to write everything down.
It's to identify which knowledge becomes dangerous when it stays conversational and give it somewhere better to live.
What tribal knowledge looks like from inside a team
The signals are social before they're technical.
There's one person everyone messages before touching billing. A two-line PR objection turns into a history lesson because the reviewer has to explain a decision made four years ago. New engineers reach a point where the remaining questions are all versions of:
“Why does this work this way?”
and none of the answers are written anywhere.
The person at the center usually doesn't experience this as prestige.
They experience interruptions.
A developer asks about a queue. Someone else wants a review. An AI assistant produced a plausible explanation of a legacy module and somebody needs to confirm if it's true. Then an incident starts and three people need the same person's context at once.
They have become the team's living FAQ.
That creates a strange incentive.
Their knowledge is part of what makes them valuable. At the same time, the concentration of that knowledge prevents them from spending their time on higher-leverage work.
So the goal can't be:
“Make the expert less important.”
It should be:
“Stop making the expert the default interface for information that doesn't require their judgment.”
Why the wiki didn't fix it
Documentation isn't useless.
The problem is that different kinds of knowledge decay at different speeds.
A page describing the current architecture might become inaccurate after the next sprint. A decision explaining that the team introduced asynchronous processing after a specific synchronous failure can remain useful for years.
Knowledge that survives in writing tends to be the knowledge that changes least, especially decisions and reasoning, while documentation that attempts to mirror the current implementation can drift quickly.
That suggests a better split.
Don't manually document what the code can answer
Examples:
- where a service lives
- which files implement a feature
- what calls an endpoint
- where a type is used
- which repository contains similar logic
Those facts change with the code.
If people have to update a wiki after every structural change, the wiki is competing with the development process.
Eventually it loses.
Do record what the code can't infer
Examples:
- why a design was chosen
- which alternatives were rejected
- what production failure changed the architecture
- which business constraint shaped the implementation
- what trade-off the team knowingly accepted
Martin Fowler's 2026 description of an Architecture Decision Record makes the same distinction. An ADR captures one significant decision, its context and its consequences rather than trying to duplicate the implementation itself. See Fowler's ADR overview.
This gives us a practical rule:
Let code describe structure. Let decision records preserve intent.
AI made tribal knowledge more visible, not less important
It's tempting to assume that AI assistants solve tribal knowledge because engineers can ask questions instead of asking colleagues.
They can help.
But only if the assistant has a reliable source for the answer.
Understanding an unfamiliar codebase remains difficult even with LLM support. A 2025 human-AI codebase-comprehension study notes that developers still struggle to achieve adequate understanding of large unfamiliar systems under time pressure, including when using LLMs. The research focuses specifically on codebase understanding with human-AI collaboration.
Recent onboarding research makes the same problem visible from another direction. A 2026 paper on expert mentoring describes expert walkthroughs as valuable for transferring tacit knowledge and helping newcomers navigate codebases, while also noting that this form of support is expensive and repetitive. Its proposed system captures expert mentoring into reusable code tours rather than requiring the same expert explanation every time. See the LACY research.
AI therefore creates two possible outcomes.
Outcome 1: expertise becomes reusable
An assistant retrieves grounded information, points engineers to relevant source and allows routine questions to stop interrupting the expert.
Outcome 2: missing knowledge gets filled with plausible text
The system owner isn't available.
Someone asks why the module behaves a certain way.
The assistant produces a convincing explanation.
Nobody knows enough to correct it.
That is more dangerous than simply getting “I don't know”.
Concentration of knowledge used to make organizations slow; when AI can answer confidently without the missing owner, it can also make missing knowledge unverified.
The goal isn't to capture everything
A “document everything before it walks out the door” program will fail.
There is too much information.
Most of it isn't equally valuable.
Start with knowledge carrying one of three forms of risk.
1. Decisions
Ask:
- Why is the system shaped this way?
- Which alternative looked attractive but failed?
- Which constraint made the current design necessary?
- What would you reconsider if that constraint disappeared?
2. Failure history
Ask:
- What has broken here before?
- Which failure isn't obvious from the tests?
- What looked safe and wasn't?
- Which “temporary” workaround became permanent?
3. Hidden dependencies
Ask:
- What looks local but affects another system?
- Which third-party dependency surprises new engineers?
- Which change requires coordination outside this repository?
- Where are the operational assumptions that aren't visible in the call path?
Those three categories are more useful than asking:
“Can you document the billing system?”
The first produces decisions.
The second usually produces a document nobody can finish.
TRIBAL KNOWLEDGE INTERVIEW KIT
Don't ask the expert to “walk you through the system”.
Use these questions instead.
Decisions
- What are the three decisions a new owner is most likely to misunderstand?
- What alternative did the team seriously consider?
- Why did you reject it?
- Which constraint shaped the current implementation?
- Is that constraint still true today?
Failures
- What has failed in a way the tests wouldn't have predicted?
- What looks strange because of a past incident?
- Which component would you be nervous about changing without context?
- What workaround became part of normal production behavior?
Dependencies
- What looks independent but isn't?
- Which downstream consumer is easiest to forget?
- Which external service has unusual behavior?
- What breaks outside this repository when this changes?
Human routing
- What questions do people ask you every week?
- Which of them could be answered from code?
- Which require historical context?
- Which genuinely require your judgment?
Final question
If you disappeared tomorrow, what would the team confidently get wrong?
Record the interview, but don't stop at the transcript
Structured expert interviews are better than broad subsystem monologues.
A transcript preserves more detail than someone's summary written afterward.
But a two-hour transcript isn't a knowledge system.
Nobody wants to search 19 pages of conversation during an incident.
After the interview, you or AI can extract only the durable pieces.
Decision
What did we decide?
Context
What problem or constraint existed?
Alternatives
What else did we consider?
Reason
Why did the current option win?
Consequence
What becomes risky if someone changes it casually?
Evidence
Where can the next engineer verify this?
That last field matters.
The more knowledge can point back toward code, incident reports, issues or PRs, the less it depends on somebody trusting another piece of prose.
Write decisions where engineers will find them
An ADR doesn't need a heavyweight governance process.
Fowler recommends keeping ADRs short, focused on one decision and linked rather than rewriting old decisions when circumstances change.
Location matters as much as format.
If a decision concerns the code, keeping the record close to engineering artifacts has several advantages:
- it can be reviewed with the work
- links survive team changes
- engineers don't need to know which wiki space contains the answer
- future tooling can retrieve the decision alongside the implementation
Broader work on infrastructure platforms also describes ADRs as a lightweight mechanism for leaving future teams clues about why a system became what it is. See Building Infrastructure Platforms.
The important thing isn't .md versus Notion versus an ADR tool.
It's that the answer survives the person who originally knew it.
Extract structure from the source instead of interviewing people about it
There's a second category of knowledge we shouldn't ask senior engineers to document manually at all.
“What calls this?”
“Where is this pattern used?”
“Which repository owns this behavior?”
“What depends on this interface?”
Those are repository questions.
The code should answer them.
This is the split behind Tentaro's role in the workflow. The existing product boundary is context extraction rather than code generation: Tentaro indexes code and delivers grounded context to engineers and compatible AI assistants, so structural questions can point back to source instead of depending on a person's availability.
Tentaro's internal product materials likewise define shipped capabilities around code-context extraction, MCP delivery and grounded source context rather than automatic reconstruction of undocumented rationale.
The distinction matters enough to repeat:
Structure can be extracted. Intent has to survive somewhere.
If nobody ever recorded why the team rejected an alternative architecture, no retrieval system should pretend it knows.
A 30-day tribal knowledge capture plan
You don't need to launch a company-wide program.
Pick the two systems with the highest concentration risk.
Identify concentration, interview the bottlenecks, make structural code knowledge answerable and then test the result on someone else.
Here's the expanded version.
Week 1: find the human APIs
Look for:
- repeated questions to one person
- repeated review requests
- systems with one credible explainer
- dependencies only one person knows
- new engineers repeatedly blocked in the same places
Don't duplicate the entire bus-factor audit.
If you already ran it, use the highest-risk systems from that work.
Week 2: interview two bottlenecks
Schedule 90 minutes per person.
Don't ask for completeness.
Pick decisions, failures and dependencies.
Record the session.
Produce 5–10 knowledge cards, not a 40-page handbook.
Week 3: stop sending structural questions to humans
Identify the questions that can be recovered from repositories:
- usages
- implementations
- dependencies
- relevant files
- similar patterns
Make those queryable.
Keep human escalation for the things source code genuinely doesn't contain.
Week 4: test the system on someone who wasn't in the room
Give a newer engineer a real task.
Count:
- questions answered independently
- questions answered from code/context
- questions requiring senior judgment
- questions nobody can answer
Don't ask if the new system “feels useful”.
Measure how many expert interruptions remain.
The metric worth keeping is interruptions avoided
Tribal knowledge is difficult to measure because its cost appears as other things.
Slow onboarding.
Review queues.
Senior-engineer overload.
Systems nobody wants to change.
Repeated Slack questions.
The original draft therefore proposes a refreshingly simple measurement: after capture work, give someone a real task and count how often they still need the expert.
We'd make that the primary metric.
Senior interruptions per system per week
Don't optimize the number toward zero.
Some questions should reach senior engineers.
Instead classify them.
RETRIEVAL → “Where is this implemented?”
HISTORY → “Why did we make this decision?”
JUDGMENT → “Given today's constraints, what should we do?”
The target isn't “no interruptions”.
It's:
Stop paying senior-engineer attention for retrieval. Preserve it for history and judgment.
How AI should change the pattern
Research into onboarding is increasingly exploring AI as a way to augment expert mentoring rather than simply replace it.
A 2024 systematic literature review of 32 studies on software onboarding found that tooling can reduce onboarding barriers and pressure on senior team members, but also concluded that many onboarding barriers remain insufficiently addressed. Read the systematic review.
A 2026 research roadmap for software-engineering agents similarly identifies code, documentation and requirements as sources from which AI systems may extract and deliver context for onboarding, collaboration and knowledge sharing. See the research roadmap.
The useful model isn't:
AI replaces the knowledgeable senior.
It's:
AI and retrieval absorb repeatable context delivery so the knowledgeable senior spends more time on the knowledge that hasn't been captured yet.
That is a much more realistic target.
What can't be automated
Some knowledge isn't in the repository.
It isn't in Jira.
It isn't in the wiki.
The only existing copy is in someone's head.
Until that person explains it, software can't extract it.
That is why a tribal-knowledge program needs both sides:
MACHINE-RECOVERABLE
- current structure
- file relationships
- implementations
- dependencies
- source history that still exists
HUMAN-CAPTURED
- intent
- rejected alternatives
- historical constraints
- failure lessons not recorded elsewhere
- judgment
Pretending one side replaces the other is how teams end up with either a giant stale wiki or an AI assistant confidently explaining history it never observed.
Start with the system that interrupts the same person every week
Don't inventory all organizational knowledge.
Pick one subsystem where engineers repeatedly ask the same senior for help.
For 30 days:
- capture its high-risk decisions
- make structural code knowledge queryable
- give someone else a real task
- count the remaining interruptions
Tentaro can handle the repository-grounded part of that workflow: extracting structural context and making it available to engineers and compatible AI assistants through MCP. Historical reasoning still needs to be recorded by the humans who know it.
