.svg){kind=logo}
On this page
Measure the work, not the signal.
See productive time and utilization by team, not just what looks active.
Key takeaways
- The people a company depends on most often sit well below the top of the org chart, and their absence shows when work stalls.
- A knowledge silo is an access problem: the know-how exists, but only one person or group can use it.
- Undocumented knowledge, once called tribal knowledge, covers the exceptions and judgment calls that written procedures leave out.
- Leaders can find key person dependencies by following one critical workflow and noting where it waits and who gets asked about it.
- Reducing the dependency means changing how work moves, with shared decision rules, practice runs for a backup, and automation when a person only relays information.
It's month end, and three teams are waiting for an export that's harder to run than it looks. Someone finds last month's file, and someone else tries the instructions, but both end up with questions only Marko can answer.
Marko is an operations analyst who runs the month-end export three teams need, including the undocumented checks that make the numbers usable.
And he's on leave for two weeks on his honeymoon.
Marko's absence revealed the dependency only after work stalled. The org chart shows where he sits, but not how the work runs through him.
In this example the dependency is easy to spot, but still costly. Most knowledge silos are harder to see and triage.
When delivery slows, another hire can look like the obvious answer, but adding people around a step doesn't address the core problem: the step is built around a single point of failure. The first question to resolve is how to spread that knowledge so the work can move flexibly.
Answering it starts with finding the dependencies, making the flow of work visible, and redesigning it before an absence forces the issue.
The person everyone waits on
"Run the export" sounds like a task you could hand over in an afternoon, but Marko also knows which records need correcting and who needs which version. The instructions cover the general routine, but not how the work happens.
Dependencies like this often grow out of good intentions. Someone solves a problem, becomes the person colleagues ask, and keeps absorbing exceptions when they pop up. Eventually, their judgment becomes a required step in several teams' work.
You see the same pattern when an approval waits for one manager, or an improvement project stalls until an experienced colleague can explain the existing process.
That person may be at full capacity while everyone is sitting idle waiting for the bottleneck to resolve. Asking the teams around it to produce more only builds up the queue. The fix is to change how work passes through that point.
Why the org chart can't show it
An org chart describes authority and accountability. It shows who manages each team, but it says nothing about who resolves the exceptions that keep the team's work moving.
Work rarely follows clean reporting lines, so several teams can depend on one person without anyone seeing it. An analyst two levels below the executive team might be the one who connects finance, operations, and customer service.
A lot of everyday work still depends on asking the right person. In Atlassian’s State of Teams 2025 survey of 12,000 knowledge workers, 56% said the only way to get the information they need is to ask someone or schedule a meeting. When work hinges on a single colleague, the questions queue up behind them. They carry crucial load that blocks anything downstream whenever they’re busy, on leave, or gone.
These key people often mask the dependency by making difficult deliveries work, unbeknownst to anyone above them on the org chart. They step in and adapt the process. They employ workarounds from years of know-how. The expected output arrives, so the arrangement looks like it works.
The test is whether this essential work has another route when that person is out.
What is a knowledge silo?
A knowledge silo exists when information or expertise needed for work stays within one person or group and isn't readily available to others who need it. Colleagues then have to keep going back to that person or group, or carry on without what they need.
Documentation alone doesn't prevent a silo. A shared folder can contain every procedure while leaving the practical decisions unexplained.
An export can serve three teams, but only one person can produce it. Each team gets the result without the knowledge behind it.
This holds in any handoff: a document's existence says little about whether someone else can use it.
What is tribal knowledge, and what do we call it now?
In a workplace context, tribal knowledge means unwritten know-how acquired through experience. It may be held by an individual or shared informally within a group. It includes the exceptions, context, and practical steps people learn by doing work and that don't appear in the formal written process.
Some inclusive-language guides recommend replacing "tribal knowledge" because it borrows language associated with Indigenous peoples and communities. The University of Washington's IT Inclusive Language Guide recommends using "institutional knowledge" or "organizational knowledge" as alternatives.
We'll call it undocumented knowledge. Undocumented knowledge is what people hold. A silo is what happens when others can't get to it.
The cost of work with no backup
Key person risk is the disruption an organization faces when critical work depends on a particular person's knowledge, relationships, skills, or authority. It becomes a problem when they're away and no one else has the skills or authority to keep the work moving.
The cost starts long before an absence makes it visible. The work waits, context switching interrupts the expert, and colleagues sit idle when they could be shifting to higher value work.
In the same Atlassian State of Teams survey, leaders and teams spent a quarter of their time just searching for answers. A smaller 2026 survey by Slite, which sells knowledge management software, found that 34% of workers spend 30 to 60 minutes a day waiting for responses, and 81% have to interrupt colleagues for help.
During an absence, a team can spend days rebuilding a process it used to run as routine. At scale, the cost shows up in operating results.
In the mid-1990s, Delta Air Lines lost many experienced mechanics, according to the same MIT Sloan Management Review article. The departures cut compensation costs at first, but less experienced staff took longer to diagnose and repair aircraft. That contributed to flight delays and cancellations and raised cost per seat mile.
Replacing someone the work depends on is also expensive. Gallup estimates that replacing a leader or manager costs around 200% of their salary, a technical professional 80%, and a frontline employee 40%.
It's already an alarming estimate without figuring in knowledge loss. When critical business processes depend on one person, filling the vacancy restores only the position. Restoring the workflow takes the context and capability that made it run.
How to find the dependency before an absence forces the issue
Start with one workflow the business can't afford to have delayed. Follow it from the first request to the finished result, including every handoff between departments.
These steps help identify key person dependencies:
- Find where work waits. When something is ready but can't advance, ask what's missing: information, a decision, access, or someone's action. If what's missing is one person's knowledge, you haven't diagnosed the problem. Find out what he or she supplies.
- Find who people turn to. Ask colleagues who helps when instructions run out or an exception appears. When the same name keeps coming up, you've found a likely silo.
- Check whether backups can do the work. Confirm that anyone named as a backup has the permissions, judgment, and experience to complete their designated tasks.
- Review recent absences. What waited during someone's leave? Which tasks were postponed until they returned? Where did colleagues need to interrupt a holiday to keep things moving?
- Involve the person carrying the dependency. Ask them what they repeatedly resolve, which decisions others struggle with, and what someone else would need to take over successfully.
- Record and prioritize the gaps. Note the critical step, why it waits, the available backup, and the consequence of delay. Prioritize essential work with no viable alternative, and assign someone to address each gap.
- Match the fix to the cause. Train a backup when knowledge is missing, delegate when approvals depend on one person, and redistribute work when someone is overloaded.
Redesign the flow so it doesn't depend on attendance
A workflow that doesn't depend on one person is usable at the point of work. Instructions, decision rules, and common exceptions sit beside the task or system, ready at hand. Someone owns keeping them current.
Once you understand what's holding work up, these changes reduce key person dependencies:
- Document the decisions as well as the steps. Undocumented knowledge doesn't have to stay undocumented. Explain how to handle exceptions and recognize a successful result, and keep that guidance current. For the export example, that means recording when inputs are ready and how to resolve discrepancies. "Open the report and select export" leaves the consequential work unexplained.
- Build capability through doing. Have a colleague complete the workflow with support, then perform a run independently, including ordinary exceptions. The dependency is reduced when someone else can finish without repeatedly returning to the original expert.
- Examine whether each handoff still needs a person. Identify steps where a person mainly transfers information or routes a result. Automate predictable transfers where you can. Where judgment or approval remains necessary, establish clear decision boundaries and an alternative approver.
- Use AI to capture and share the process. Include knowledge transfer in your AI adoption strategy. AI can help assemble explanations and observed steps into human-readable guidance while the work happens. Practitioners can then explain the reasoning behind key decisions and validate the AI's output. A sequence of actions won't capture the crucial context that AI often misses, so the human layer is crucial.
- Check whether delivery improves. Compare waiting time, completed work, and quality before and after the change. Confirm that a backup can carry the workflow through routine exceptions and a normal absence.
Knowledge sharing then becomes an efficiency lever, doing more with the same resources. It helps the team you have deliver more reliably, so a new hire isn't the first answer.
What is the bus factor?
The bus factor is a term software teams use to describe the smallest number of people whose sudden absence would stall a project because essential knowledge or capability is missing. A bus factor of one means a single person's absence could stop the work.
It's a measure of key person risk based on a blunt hypothetical: How many essential team members would have to be hit by a bus for the project to stall?
An early example appeared in a 1994 Python mailing-list discussion titled "If Guido was hit by a bus?", which asked whether Python could survive without its creator, Guido van Rossum.
The idea applies well beyond software. A finance workflow can have a bus factor of one, even with a large team. Raising it means making sure someone else can carry the critical work.
Seeing the flow before you redesign it
Hidden dependencies are difficult to spot while the people carrying them keep work moving. You see the completed work, but miss the interventions that made it possible.
Insightful's People Intelligence shows how people work and suggests opportunities to improve their output. Key Person Risk, one of the opportunities for improvement People Intelligence offers, shows whose work your company depends on and suggests how to reduce that dependency, so you can plan cover before an absence disrupts delivery.
Insightful sees the apps, sites and AI tools your people use, and how they use them. It doesn't log content or capture keystrokes, messages, or documents. Just how work happens. Skip the consultants and go straight to the facts.
Request a Work Audit. We show your first opportunities in 14 days, from your own data.
Frequently asked questions
What is the difference between tribal knowledge and a knowledge silo?
In work environments, tribal knowledge refers to undocumented know-how held by an individual or group. A knowledge silo exists when knowledge isn't readily accessible to others who need it. Undocumented knowledge can contribute to a silo, but documented information can also remain siloed if people cannot find, access, or use it.
What is a better word for tribal knowledge?
"Undocumented knowledge" and "institutional knowledge" are better alternatives for tribal knowledge. Both describe the same thing without using a word that many people now find insensitive.
Is tacit knowledge the same as tribal knowledge?
Tacit knowledge and tribal knowledge overlap, but they describe different characteristics. Tacit knowledge is experience-based understanding that's difficult to articulate, and tribal knowledge refers to unwritten know-how held by an individual or shared within a team or workplace. That unwritten knowledge can include both tacit knowledge and straightforward process steps that haven't been documented.
How do you capture tribal knowledge?
Capture tribal knowledge by documenting how work happens, including the decisions, exceptions, and relationships that make the process function. Combine interviews and shared practice with tools that help capture software-based steps, then make the guidance accessible where people need it.
What is key person risk?
Key person risk is the possibility of business disruption when essential knowledge, relationships, or decision-making authority depend on one person. When that person is unavailable, delivery can stall if no capable backup is in place. This risk can arise at any level of the organization.
What is key person dependency?
Key person dependency is when a critical workflow or decision relies on a particular individual and has no effective alternative. The dependency may come from specialized knowledge, exclusive access, approval authority, or relationships that haven't been shared.
What does a low bus factor mean?
A low bus factor means a project depends on a small number of people whose sudden absence could stop progress because essential knowledge or capability would be missing. A bus factor of one means a single person's absence could stall the project.
Can you give an example of a knowledge silo?
A customer support team could become a knowledge silo by recording recurring problems in a ticketing system the product team doesn't use. Individual issues might get escalated, but the accumulated feedback would remain "siloed" within support, making it harder for product colleagues to recognize patterns and prioritize improvements.
