The Single-Person Dependency Problem No One Tracks

The number most teams cannot tell you

Ask an engineering manager how many single-person dependencies exist in their team and you will usually get one of two responses. Either they name three or four they know about off the top of their head, or they pause and say something like "more than I'd like, but I'm not sure of the exact count." Neither response reflects a measured understanding of the actual structural risk sitting in that team's knowledge topology.

This is not a failure of management. It is a consequence of how teams grow. The knowledge of who-knows-what accumulates organically, and the informal model that exists in experienced team members' heads is continuously out of date. Dependencies appear as people deepen in narrow domains. Others evaporate quietly when someone transitions and their replacement doesn't pick up the same knowledge surface area. The map is never accurate for long, and nobody owns the job of keeping it current.

The consequence shows up predictably: when any particular node in that invisible dependency network becomes unavailable, work stops in ways that surprise people who were sure they had adequate coverage.

How single-person dependencies form

Single-person dependencies do not form because teams are careless. They form through several well-understood mechanisms that are common to any team growing faster than its knowledge-sharing practices can keep up with.

The first is specialization drift. As a team grows, individuals naturally move toward the areas where they add the most value. This produces expertise, which is valuable. It also produces a concentration of knowledge in the person who holds that expertise, which is a risk. The two outcomes are inseparable unless the team makes an active and recurring effort to diffuse knowledge as it concentrates.

The second mechanism is legacy accumulation. Systems and processes that have been around for a while tend to be understood only by the people who have worked with them for a while. When the original builders move on and their knowledge is not transferred, the remaining team often has shallower understanding than the documentation suggests. The processes still have listed owners. The owners just no longer have the full context required to operate the process reliably under non-standard conditions.

The third, and in many ways most insidious, mechanism is decision context decay. Modern software systems are built on accumulated decisions, many of which are not documented anywhere. Why is the retry logic implemented the way it is? Why was that third-party vendor chosen for this particular integration? Why does the data pipeline run at that specific time window? If the person who made or remembers those decisions leaves, or simply gets too far removed from the work to be consulted readily, the team is flying blind on a significant portion of the reasoning behind how things work.

Why standard measures miss it

Most teams have some version of a "hit by a bus" conversation where they nominally assess coverage risk. The honest ones will admit that those conversations produce a list of obvious single-person dependencies, acknowledge they are a problem, and then fail to result in any systematic remediation because nobody has a reliable way to actually track the full scope of the problem.

Org charts show reporting relationships, not knowledge dependencies. A team member's position in a chart tells you who they report to, but nothing about which operational processes would grind to a halt if they were unavailable. The two structures are almost entirely orthogonal. A junior engineer who has been maintaining a critical legacy authentication service for 14 months can be a higher knowledge-risk node than their engineering manager, despite occupying a much lower position in the formal hierarchy.

Documentation coverage metrics are not much better. The question is not whether a process is documented. The question is whether the documentation is current, whether it captures the non-obvious parts, and whether there is any other person on the team who has enough recent engagement with the process to actually execute it under pressure. A well-maintained wiki page does not make a process safe from knowledge-dependency risk if only one person has the working context to act on what the page says.

What measurement actually looks like

Building a genuine picture of single-person dependency requires tracking active knowledge engagement rather than nominal ownership. The distinction matters enormously. Nominal ownership tells you who is listed as responsible for a process. Active knowledge engagement tells you who has actually been working with it in a way that maintains their operational understanding of it.

In graph terms, this means measuring the incoming edge concentration on each process node: how many distinct people have touched this process, through documentation contributions, task execution, question answering in communication channels, or code changes, within a relevant time window? A process where that count is one is a single-person dependency regardless of what the wiki ownership field says.

When we build knowledge graphs from activity signals for teams in our early-access program, we consistently find that the number of true single-person dependencies is higher than the team's informal estimate. Not because the team was being careless in their estimate, but because the informal estimate is based on the processes people consciously think of as risky. Activity-signal analysis surfaces the ones that look fine from the outside because someone competent is handling them smoothly, but are actually just as brittle because that single person is the only one with relevant recent context.

The average we see across early-access teams is 23 single-person dependencies per 50-person team. The range is wide. Some teams have fewer because they have invested heavily in pair-ownership practices. Some teams are significantly higher because they have grown quickly without deliberate knowledge-spreading structures. In every case, the actual number was higher than the team's mental model predicted before measurement.

Severity is not uniform

Not all single-person dependencies carry the same risk level. A dependency on one person for a low-frequency process with well-documented steps and a forgiving time horizon is meaningfully different from a dependency on one person for a high-frequency, poorly documented process that sits on the critical path for a revenue-affecting operation.

Effective dependency risk management requires sorting the identified dependencies along at least two dimensions: how critical is this process to operations, and how hard would it be to reconstitute this knowledge if the current holder became unavailable? The combination of high criticality and high reconstitution difficulty is where you should concentrate remediation resources first. A new hire who is the only person who knows how to configure the staging environment for a rarely-used internal tool is a single-person dependency, but it is not the one keeping a team lead awake at night.

We are not suggesting that low-severity dependencies should be ignored indefinitely. Over time, every unaddressed dependency is a liability. The point is that remediation resources are finite, and prioritizing by actual risk level produces better outcomes than treating all dependencies as equally urgent.

The remediation conversation that changes

Once you have a measured picture of your dependency structure, the planning conversations change in a useful way. Instead of reacting to incidents caused by knowledge gaps, you can proactively allocate time for cross-training against the highest-risk dependencies before they manifest. You can incorporate dependency risk into project planning: when assigning someone to a complex initiative, you can see in advance which of their current knowledge areas would become uncovered as they shift focus, and plan accordingly.

The goal is not to eliminate specialization. Deep domain expertise is genuinely valuable and you do not want to thin it out homogeneously across a team. The goal is to ensure that for every high-criticality process, there is at least one other person with enough recent engagement to step in when the primary knowledge holder is unavailable. That minimum coverage bar is achievable in most teams without sacrificing the benefits of specialization. It just requires measuring the gaps first, which is where most teams currently have no reliable mechanism to start.