Key-Person Dependency in IT: The Risk Nobody Talks About

If you were to ask a colleague what happens if that person is away for three weeks, the answer would often be an uncomfortable pause rather than an explanation.

This is key-person dependency, and it is far more common than most leadership teams realise. It rarely comes up in board meetings, partly because it is hard to put a number on and partly because naming it can feel like criticising a valued member of staff. Even so, it is one of the most persistent operational risks in IT, and it tends to grow quietly for years before anyone notices how deep it has become.

What Key-Person Dependency Actually Looks Like

Once you know what to look for, the pattern is easy to recognise. One person holds the passwords and admin access to systems that nobody else has ever needed to touch; the logic behind an outdated integration, the reason a particular workaround exists, the order in which overnight jobs need to run — none of it is written anywhere except in that person's memory.

New hires learn the system by sitting next to this person and being talked through it, rather than through any formal onboarding process. Documentation, if it exists at all, was last updated several years ago and no longer matches how the system actually behaves. When that key person takes annual leave, certain tasks simply wait until they return, and if they are off sick for more than a few days, small problems that would normally take an hour to resolve take a week.

From the inside, none of this looks dramatic as work still gets done, deadlines are mostly met, and the arrangement feels stable because it has held for so long. That stability is exactly what makes the dependency easy to miss.

The same pattern shows up in smaller places too. A spreadsheet with a macro nobody else can safely edit; a supplier relationship that runs through one inbox because that person set it up years ago and it was never handed over. Individually, these look like minor habits rather than risks, but put together, they describe a business that has become far more reliant on one person than anyone intended.

Why It's More Common in Legacy Environments than Anywhere Else

Modern cloud platforms carry a certain amount of shared knowledge built into them: a vendor maintains documentation, a support team can be called, an online community has usually already answered the same question, and for common problems, there are standard practices. Some of the knowledge needed to run the system lives outside any one employee's head.

Bespoke or heavily customised legacy systems have none of this. A system built in-house twenty years ago, extended piecemeal ever since, exists only in the form one person understands; there is no vendor to call and no community to search. This is close to what engineers mean by a single point of failure, a term that is usually applied to servers or network infrastructure, but is just as relevant when the single point is a person rather than a machine. In software teams, the same idea is sometimes called the bus factor, shorthand for how many people would need to be unavailable before a project stalled.

The uncomfortable part is that this dependency does not level off with time. The longer a legacy system runs, the more of its behaviour becomes tribal knowledge, and the harder it becomes for anyone else to catch up.

The Real Cost, and Why It's Hard to See Until It's Too Late

The cost of key person risk, much like the true cost of ageing legacy systems more broadly, rarely shows up as a single, visible event you can trace back to. It materialises as friction that accumulates in places nobody thinks to connect. Hiring slows down, because a new team member cannot become properly productive until the one person who understands the system has walked them through it, and that person has their own work to do in the meantime.

At times when a business has no control, like when that person quits, gets sick, or just decides to retire, the risk increases. It also surfaces during due diligence, when a prospective buyer asks how a critical system is supported and the honest answer is one specific person. And it subtly shapes conversations about pay and conditions, since a business that depends entirely on a single individual's goodwill has less room to negotiate than it would like to admit.

One Hollinford client discovered this directly. They wanted to bring in a second systems administrator ahead of a planned retirement, expecting a straightforward handover. The amount of informal, undocumented knowledge was too great to transfer in any reasonable amount of time, so the hire had to be postponed until a more thorough, extended transition could be arranged. None of the figures involved was dramatic. What made the situation costly was simply how long it took to unwind a dependency that had built up unnoticed over many years.

Why "Just Document It" Rarely Works

The instinctive fix is to sit the key person down and get them to write everything up. In practice, this rarely produces anything useful. The knowledge holder has spent years inside the system, and what feels obvious to them is precisely the part that other people would need explained.

They will document the steps of a process without mentioning the exception they handle automatically, or the reason a setting was changed three years ago, because to them it does not feel like a decision worth recording; it is simply how things are done. This method of documentation typically describes the system's surface rather than the underlying logic, which is exactly what a newcomer needs.

There is also a timing problem. A documentation project is usually commissioned once someone is already planning to leave, meaning it competes with a handover, a notice period, and everything else that person is trying to finish before they go. Given these circumstances, writing down years of accumulated understanding in a few weeks, alongside a full workload, is not a realistic task. Hence, the resulting document tends to be thinner than it looks on the day it is signed off.

What Actually Reduces the Risk

Reducing key-person dependency is less about a single document and more about changing how knowledge is created and shared going forward. Instead of asking the key person to document in isolation, assigning them to a real task with a colleague forces the less obvious decisions to emerge organically, in context, as they occur, which works a lot better than trying to reconstruct reasoning afterwards. A short note on why a change was made is worth more than a long manual written months later from memory.

Routine tasks, like managing a support queue or running the monthly close, can be shared on a rotating rather than fixed basis, which keeps multiple people genuinely current rather than just aware. None of this needs to happen all at once. A gradual shift, starting with the areas that would hurt most if the key person were suddenly unavailable, is far more workable than a single sweeping initiative.

Where the underlying system is old enough, complex enough, or undocumented enough that the dependency is really structural, no amount of knowledge sharing fully removes it. In those cases, modernising the system itself becomes the more durable answer, since it replaces something only one person can maintain with something a team can. This is the territory our legacy modernisation work sits in, and it is usually the conversation businesses have once they have recognised the pattern in themselves.

A Quick Way to Check Your Own Exposure

A short exercise is often enough to see where you stand.

If the honest answers are uncomfortable, that discomfort is useful information rather than cause for alarm.