Critical-person dependency is when your ability to understand or operate a system depends on knowledge held by a single individual. It rarely appears on the risk register because it is invisible while that person is still there.
The engineers you cannot afford to lose are not the risk. The systems that only they understand are the risk.
Reducing it is not about documentation for its own sake. It is about capturing the reasoning, not just the process, and structuring that knowledge so the next engineer can act on it without needing to interrupt the person who built it.
Every engineering leader I speak to can name at least one person on their team who they cannot afford to lose. Sometimes it is a system architect who has been there fifteen years. Sometimes it is a mid-level engineer who happened to be the one who built the pricing engine, or the reconciliation flow, or the piece of connectivity that everyone quietly depends on.
The instinct is to protect that person to retain them, promote them, keep them happy. That instinct is not wrong. But it is treating the wrong problem. The person is not the risk. The system that only they understand is the risk. Critical-person dependency is what we call it when those two are the same thing.
Critical-person dependency is a situation in which an organisation’s ability to understand, operate, extend, or safely change a system depends on knowledge held by a single individual, or a very small number of individuals, that is not captured anywhere else.
The knowledge in question is rarely the code itself. Code is usually reviewable. What is missing is the reasoning behind the code: why it is built the way it is, what constraints shaped it, what happens if you change the thing that looks safe to change, which of the design choices are load-bearing and which are historical accidents.
Engineers who hold that reasoning are indispensable in the operational sense. You cannot replace them by hiring another engineer of equivalent skill, because the new engineer will not have the reasoning. They will have to reconstruct it, slowly, mostly by asking the original engineer.
Which brings us to the tell. If your best engineers are spending a meaningful percentage of their week answering questions that only they can answer, you have critical-person dependency. It is not a hypothetical. It is already costing you delivery time, right now.
Because while the person is present, nothing is failing. The system runs. The team ships. Questions get answered, incidents get resolved, changes get made. The dependency is invisible in the way a load-bearing wall inside a house is invisible when the wall is still there.
Risk registers are usually populated by things that have gone wrong before, or things that governance frameworks explicitly require to be tracked. Critical-person dependency fits neither pattern comfortably. It is a class of operational risk that materialises only when the person leaves, is off sick during an incident, or retires. Until then, the register shows green.
The senior engineers themselves rarely raise it either. Partly because they do not experience it as a dependency; they experience it as competence, and competence is not something you flag. Partly because raising it feels like criticising a colleague or admitting an organisational weakness. The result is that the risk sits invisibly across the engineering estate, held together by the goodwill and memory of a small number of people, and everyone hopes those people do not leave.
The most useful diagnostic is not a survey. It is a very simple question, asked of the engineering manager for each system in the estate:
If [named engineer] left tomorrow, how long would it take before we would notice they had gone?
If the honest answer is “a few weeks, and we would probably lose some delivery velocity but recover,” you do not have a critical-person dependency for that system. If the answer is “immediately, because there are open questions on the change we are about to make that only they can answer,” you do.
The second useful diagnostic is where the questions go. In every engineering team, there are a handful of names that get mentioned when something breaks, or something needs designing. Track those names for a fortnight. If the same one or two names are appearing across incidents, architecture discussions, and change reviews, that person is a critical dependency, whether or not they show up as such in any formal role definition.
The third diagnostic is documentation quality — but not in the way most organisations measure it. The relevant question is not “is there documentation” but “can someone who was not present when the system was built act on the documentation without asking the person who built it?” Most engineering documentation, when tested against that question, fails. It describes the what, sometimes the how, and almost never the why.
The obvious cost is the incident cost when the person eventually leaves. Recovery time for an unplanned loss of critical knowledge, in the engineering teams I have observed, is usually measured in months, not weeks. The organisation continues to function, but delivery velocity drops, changes become more cautious, and confident architectural decisions become slower architectural decisions.
The less obvious cost is what the dependency does while the person is still present. Every hour a senior engineer spends being the human interface to the system they built is an hour they are not spending on new work. Their salary is being paid for delivery, but their time is being consumed by knowledge distribution. That is a real productivity tax, and it usually hits your most experienced people hardest, because they are the ones holding the most reasoning.
There is also a mobility cost. Engineers held in place by the systems they alone understand are engineers who cannot be moved to higher-value work. Which means the organisation cannot restructure engineering effort as easily as the delivery plan needs it to. Critical-person dependency reduces optionality at the exact point in an engineering estate where you most need it: the senior end.
Finally, there is a hiring cost. Graduate and lateral hires ramp slower when the reasoning they need is trapped inside someone else’s head, because the only way to acquire it is to interrupt the person who has it. Which means your onboarding time is governed by your senior engineers’ availability, not by your training programme’s quality. Reducing critical-person dependency is one of the largest indirect levers on time to productivity for new hires. Deliberately rather than left to chance, capability that outlasts the specific technology it was originally taught on.
Finally, there is a hiring cost. Graduate and lateral hires ramp slower when the reasoning they need is trapped inside someone else’s head, because the only way to acquire it is to interrupt the person who has it. Which means your onboarding time is governed by your senior engineers’ availability, not by your training programme’s quality. Reducing critical-person dependency is one of the largest indirect levers on time to productivity for new hires.
The mistake most organisations make is treating it as a documentation problem. Documentation helps, but only a specific kind of documentation, and only if the process that produces it is designed correctly.
Reducing critical-person dependency is really three things happening in sequence.
First, capture the reasoning, not just the process. Standard operating documents describe how to do things. They do not describe why things are the way they are. When a senior engineer leaves, the process documents survive them; the reasoning documents, if they exist at all, are what actually determine whether the next engineer can operate the system safely. Reasoning capture is a specific technical writing discipline, and it usually requires someone outside the original engineering team to conduct it, because the questions that expose reasoning are the questions an outsider would ask.
Second, restructure the knowledge into training rather than reference material. Reference material assumes the reader already knows what to look for. Training assumes the reader is trying to build a mental model from scratch. The senior engineer’s knowledge, once captured, needs to be turned into something a mid-level or graduate engineer can absorb structurally, not just search through when they get stuck. That is what proper practitioner-led training does: it takes the reasoning out of the person and puts it into a form the next engineer can inherit.
Third, verify inheritance. The test of whether the knowledge has actually transferred is not whether the training was delivered. It is whether a new engineer, faced with a real question about the system, can answer it without needing to escalate to the original engineer. If the escalations continue, the dependency has not moved. If they stop, it has.
Fourth, distribute knowledge strategically rather than evenly. A common mistake at this stage is to try to distribute knowledge evenly across the whole team. If four engineers are told they now all need to understand five systems, you get one of three failure modes: cognitive overload, where nobody can hold the deep reasoning for five domains at once; diluted accountability, where everyone owns a system and therefore nobody does, and code quality quietly drops; or the superficial knowledge trap, where you have four people who each know the basics but none of whom can lead when a real incident hits.
Realistic distribution looks different. For each system, name one primary owner and one designated backup. That gives every system a bus factor of two, which is defensibly resilient without asking anyone to hold five systems’ worth of context. Rotate on-call across those pairs. The only reliable way to prove a backup actually understands a system is to have them support it during an incident. And build guardrails into the deployment pipeline — tests, architectural checks, migration gates so the system itself protects the load-bearing design choices, rather than relying on one person’s memory.
Done together, these three steps convert critical-person dependency from an invisible operational risk into a solved capability problem. The senior engineer is still valuable. They just are no longer the only person the system depends on.
Structured knowledge transfer is what makes the first step above possible at all. Without it, reasoning capture defaults to whatever the senior engineer volunteers in the fifteen minutes before they leave. Which is, in every organisation I have seen, insufficient.
Knowledge transfer done well is not a handover meeting. It is a deliberate process that treats a senior engineer’s understanding as an organisational asset to be extracted, structured, tested, and re-embedded elsewhere. It requires someone whose job it is to ask the questions that expose reasoning, and someone whose job it is to check that the answers make sense to a person who was not in the room when the system was designed.
At Mallon, this is the work our technical writers do before we build any training programme. We treat the reasoning capture as a project in its own right, not as a byproduct of training design. The training programme is what we build afterwards, using the reasoning we have captured, to move the knowledge from the senior engineer’s head into a form the rest of the team can inherit.
The point of doing it that way round reasoning first, training second is that most training that skips the reasoning capture step teaches the wrong things. It teaches the language, or the framework, or the general pattern, rather than the specific reasoning that makes your system safe to change. Which is why generic training does not reduce critical-person dependency, and structured knowledge transfer does.
There are a small number of situations in which it is defensible to accept critical-person dependency rather than reduce it.
Very short-lived systems, where the cost of the reasoning capture exceeds the remaining useful life of the system. Systems that are already scheduled for retirement and will be decommissioned before the dependency could plausibly materialise. Systems for which the risk of transfer, for example because they are so sensitive that widening the circle of knowledge itself creates a risk, outweighs the risk of the dependency.
These are exceptions. In most cases, the argument that critical-person dependency is acceptable is really an argument that the reasoning capture is inconvenient right now. That is a valid budgeting position for a quarter. It is not a valid position for a system that will be in production for the next five years.
Four signals, in the order they usually appear.
Escalations from newer engineers to senior engineers drop in frequency for the systems being addressed. Not to zero; there will always be questions, but the pattern shifts from “I have to ask X” to “I checked the material, then I asked X”.
Senior engineers report having more usable time. They notice they are being interrupted less. This is often the first internal signal, and it usually comes from the senior engineers themselves.
Time to productive contribution shortens for new hires on the affected systems. Ramp curves that used to sit around six months compress towards two or three, because the new hire can build a mental model without needing constant senior interruption.
Architectural decisions become faster and more confident. When more than one person genuinely understands why a system is the way it is, the change review meetings shorten, and the decisions become better-argued. The dependency has stopped being a bottleneck on how the system evolves.
If those four are moving in the right direction, the dependency is reducing. If they are not, no amount of documentation has actually solved the problem.
Critical-person dependency is one of those risks that engineering leaders know they have, know they should address, and defer because it never presents as urgent until it presents as a crisis. That deferral is the trap. The best time to reduce it is while the person you cannot afford to lose is still there, and still willing to answer the questions that only they can answer. The window during which reasoning capture is possible is exactly the window during which it does not feel urgent. The organisations that treat that window as the priority are the ones that are not surprised by the departures they should have seen coming.
What is the difference between critical-person dependency and key-person risk?
Key-person risk is a broader term used across most business functions. It usually refers to the risk that a single individual leaving would materially affect the organisation. Critical-person dependency is the engineering-specific expression of that risk, and it is more precisely about the systems, not the people. The distinction matters because the response is different: key-person risk is usually addressed through retention and succession planning, whereas critical-person dependency is addressed through knowledge capture and training design.
Is critical-person dependency the same as the bus factor?
They are closely related. Bus factor is a colloquial phrase for the number of people who would have to be unavailable simultaneously for a project to stall. A bus factor of one is the extreme case of critical-person dependency. The reason engineering leaders tend to prefer the term “critical-person dependency” is that it names the underlying condition rather than the disaster scenario, which makes it easier to address before the disaster occurs.
Can documentation alone solve critical-person dependency?
No. Documentation is necessary but not sufficient. Most engineering documentation captures what a system does and how to operate it, but not why it is designed the way it is. The reasoning is what actually transfers the dependency from one person to a team. If your documentation does not answer the “why” question for a new engineer, it will not reduce the dependency, no matter how comprehensive it is.
How long does it take to reduce critical-person dependency for a major system?
For a well-scoped system with a cooperative senior engineer, a proper reasoning capture and training programme usually takes between six and twelve weeks to complete, and a further quarter to verify that inheritance has actually happened through the four signals described above. Attempting to compress this timeline typically produces documentation that is technically complete but practically unusable.
What if the senior engineer is unwilling to participate in knowledge transfer?
This is more common than most leaders acknowledge, and it usually reflects one of two things. Either the engineer feels their value to the organisation is derived from being the only person who understands the system, in which case the response is a conversation about what their value actually is. Or they are worried that the exercise will surface flaws in the design, in which case the response is a technical writer who asks questions in a way that separates the reasoning from the person’s ego. Both are addressable, and both need to be, because the dependency does not go away just because the participation is difficult.
Where does Mallon Associates fit into reducing critical-person dependency?
We build training programmes for financial services engineering teams by first capturing the reasoning that lives in senior engineers, then structuring that reasoning into practitioner-led training the rest of the team can inherit. We do not sell documentation. We sell the outcome that documentation is supposed to produce — a team that can operate, extend, and change the system without needing to interrupt the person who built it. Thirty years and ten thousand-plus engineers trained across the world’s most complex engineering estates.
For more than thirty years, Mallon Associates has helped financial services organisations build the engineering capability they need, on their own systems, on a timeline they control.
Explore Alwyn Tan’s eighteen-year case study to see how that approach has been applied in practice, with an engineer whose deep institutional knowledge was captured and turned into an asset the whole team could inherit.
Every engagement starts with a conversation.
Talk to us about reducing critical-person dependency in your engineering team.
Talk to us about building engineering capability.
