Key-Person Risk in IT: How to Spot and Fix a Bus Factor of One

There’s a pattern that plays out in a lot of technology shops, and it tends to confuse everybody involved. For years the business leans on one engineer for everything hard. The outage nobody else can figure out, the vendor escalation that’s going sideways, the migration with no margin for error, the “can you just take a look at this” message at 9:40 on a Friday night. That person always shows up, and they’re good. Really good. Then, seemingly out of nowhere, leadership starts routing decisions around them. Meetings happen without them. A new hire shows up with a job description that looks a whole lot like theirs, and somebody starts asking for “documentation on everything you do.”

From the inside, that feels personal. Most of the time it isn’t. What’s usually going on is that leadership has finally noticed a risk that’s been sitting in plain sight for years. The business has built a critical dependency on one human being. That’s key-person risk, and in technology environments, especially the ones that keep critical infrastructure running, it’s one of the most common single points of failure we have and one of the least discussed.

So let’s talk about it plainly. I’ll cover what key-person risk is, how to spot it, how to measure it and how to fix it, along with how to handle the human side so you don’t lose the very person you’re trying to stop depending on.

What key-person risk actually is

Key-person risk (you’ll also hear key man risk, key person dependency, bus factor, truck factor and, for the more optimistic crowd, lottery factor) is the exposure a business carries when losing one specific person would seriously hurt its ability to operate. The bus factor puts a number on it. It’s the minimum number of team members who would have to suddenly disappear before a project or service stalls for lack of knowledgeable people. A bus factor of one is a single point of failure. Morbid name, useful idea.

The “bus” doesn’t have to be a bus, either. People take new jobs. They retire. They go on parental leave, get sick, deal with a family emergency, or just burn out and stop answering the phone. None of those are disasters for the person, but any of them can be a disaster for a system that only one person understands.

If you think this is a rare edge case, the research says otherwise. In a 2016 study of 133 popular GitHub projects, Avelino and colleagues estimated that 65% of them had a truck factor of two or less, and 34% had a truck factor of exactly one. Those are some of the most visible, most collaborative codebases on the planet. Now think about the internal firewall rule base, the PLC logic, the voice platform or that homegrown automation script that only one person in your building has ever touched.

This next part catches people off guard. Key-person risk usually comes from a great employee, and very rarely from a bad one. The people who turn into single points of failure tend to pair deep technical ability with a strong sense of ownership and urgency. They know how the thing works, they care whether it works, and they’ll stay up until it does. The business notices that and keeps handing them the hard problems, because that’s the fastest way to get the hard problems solved. Nobody plans it. It piles up one escalation at a time, like sediment.

Why technology and critical infrastructure feel it worse

Every business has key people. Technology environments concentrate the risk for a few reasons.

First, the knowledge is deep and narrow. Understanding why a routing policy was built a certain way, why a legacy integration needs a weird workaround, or why a particular controller can’t be scanned during production hours takes years of context. You can’t hand that over in a two-week notice period.

Second, a lot of it is invisible. Configuration lives on devices, credentials live in someone’s head (or worse, their personal password manager), and the reasons behind design decisions often never made it into a ticket. When the person carrying all of that walks out the door, the business loses more than labor. It loses the map.

Third, in critical infrastructure the consequences don’t stay on a dashboard. In OT environments, the person who understands the plant network is often the same person who knows which devices will fall over if you poke them wrong, which is exactly why I spent a whole post on safe OT asset discovery. When that knowledge leaves, the next person learns it the hard way, and the hard way in a substation, a hospital or a water plant has real-world impact.

Finally, there’s the security angle. When one person holds the only admin credentials to critical systems, that’s an availability risk when they’re gone and an insider risk while they’re here. That says nothing bad about the person. Good controls simply shouldn’t depend on trusting any one individual forever. NIST bakes that idea into SP 800-53 with controls like AC-5, Separation of Duties, and the contingency planning family, which includes CP-2, Contingency Plan, and CP-3, Contingency Training.

How to spot key-person risk before it costs you

The tricky thing about key-person risk is that it looks like success right up until it doesn’t. Things get fixed and projects get delivered. The problem is how they get delivered. These are the signals I’d look for.

One name on every escalation. If the same engineer gets pulled into most P1 and P2 incidents regardless of what’s broken, you don’t have an escalation path. You have a person.
“Only so-and-so knows that.” When that phrase comes up in a meeting and everybody nods like it’s normal, write it down. That’s a finding.
Work stalls when one person is out. Changes get pushed, approvals wait and tickets sit until they’re back from vacation. That’s a single point of failure with a PTO calendar.
Vacation anxiety. The key person checks email from the beach, or the team quietly dreads the weeks they’re away. Both are symptoms.
Tribal knowledge instead of documentation. Runbooks are missing, stale or say “call Dave.” Network diagrams live in one person’s Visio folder, or one person’s head.
A single admin on critical systems. One account, one person, one MFA token for the core firewall, the domain, the SCADA historian or the cloud tenant. No break-glass process, no second holder.
Heroics culture. The organization celebrates the 2 a.m. save more than the boring change that prevented the outage. Heroes are great. A system that needs heroes is fragile.
Homegrown tooling with one author. Scripts, integrations and automation built by one person, living in one person’s repo (or home directory), with no tests and no README.
Decisions route through one person informally. Even when the org chart says otherwise, nothing important happens until a particular engineer weighs in.

One or two of those is normal in a small team. If you’re seeing several at once on systems the business can’t operate without, you’ve got real exposure.

How to measure it instead of guessing

Gut feel gets you started, but leadership responds to something more concrete. Here are a few ways to put some structure around it.

Run a bus factor exercise

Pick a critical service and ask a simple, slightly uncomfortable question. If this person (or these two people) were unreachable for 30 days starting tomorrow, what breaks, what stalls and what can’t we recover? Walk through it like a tabletop exercise. Do it per critical system rather than per person, since the goal is to find fragile services and nobody needs a ranking of humans.

Map the knowledge

Build a simple matrix with your critical systems and capabilities down the side and team members across the top. For each cell, mark whether that person can operate it, troubleshoot it, change it safely or design it. You’ll quickly see columns that are full and rows that are nearly empty. Any row with only one meaningful mark is a bus factor of one.

For software and automation, you can pull some of this from data. The truck factor research above estimated authorship from version control history, and your own commit history, code ownership files and change records will tell you who actually touches what.

Plot criticality against concentration

Take the systems from your map and rate each one on two axes, how critical it is to the business and how concentrated the knowledge is. The high-criticality, high-concentration corner is your priority list. Low-criticality systems with one owner are worth fixing someday. High-criticality systems with one owner should get fixed this quarter.

Look at your escalation and on-call data

Your incident and ticketing systems already know who the key people are. Pull six to twelve months of data and look at who got paged, who resolved what, and who got pulled in after the first responder got stuck. If one name shows up as the final resolver on a big share of high-severity incidents, that’s measurable concentration.

Audit access and credentials

List the privileged accounts on your critical systems and who can actually use them. Look for shared accounts with one keeper, admin credentials stored outside your vault, and MFA tokens tied to one person’s phone. Access concentration is one of the easiest kinds of key-person risk to find, and one of the most dangerous to ignore.

How to mitigate it

There’s no single big project that fixes this. What works is a set of habits that gradually spread capability across the team until no single absence can take the business down.

Documentation and runbooks that people actually use

In that same truck factor study, the developers surveyed named documentation as the most effective practice for surviving a truck factor event. That lines up with what most of us see in operations. Documentation only helps, though, if it’s easy to find, kept current and written for the person who’ll need it at 3 a.m. An auditor is the wrong audience. Start with the runbooks for your most critical, most concentrated systems, covering how to check health, restart, fail over and roll back, plus who to call. Write down the “why” behind design decisions too, because the “why” is usually what walks out the door.

Cross-training, pairing and shadowing

Have the key person pair with someone on real work instead of walking them through a slide deck. The second person drives and the key person navigates. Do the next maintenance window that way, and the one after that. Shadowing on incidents works too, as long as the shadow eventually takes the keyboard. People learn this stuff by doing it, and watching only gets them so far.

Rotation

Rotate on-call, escalation ownership and project leads so more people build real-world experience on critical systems. It’ll be slower at first. That’s what the insurance costs, and it’s cheaper than paying the premium in the middle of a crisis.

Overlapping and redundant hires

Sometimes the only real fix is another person with overlapping skills. That can look wasteful to a budget owner, but it’s the same logic we apply to redundant power supplies and dual uplinks. Nobody calls a second core switch “wasteful” until the first one fails.

Shift from heroics to systems

Google’s SRE book defines toil as work that tends to be “manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows” in its chapter on eliminating toil. A lot of what key people do is exactly that kind of work, done well and fast because they’ve done it a hundred times. Turn it into process. Standard change templates, peer review for risky changes, defined escalation paths and good postmortems all cut down on how much rides on one person’s judgment in the moment. If you want a place to start, blameless postmortems are a great way to move lessons out of one person’s head and into the team’s habits.

Automation and infrastructure as code

When configuration lives in version-controlled templates instead of on devices, the knowledge lives in the repo instead of in someone’s memory. Infrastructure as code, configuration management and automated validation make changes repeatable and reviewable by more than one person. Just be careful you don’t recreate the problem. If one person writes all the automation and nobody else can read it, you’ve traded one bus factor of one for another.

Credential vaulting and break-glass access

Move privileged credentials into a shared, audited vault. Make sure at least two people can reach every critical system, and set up a documented break-glass process for emergencies that gets logged and reviewed whenever it’s used. Test it, too. A break-glass procedure that’s never been exercised is a theory.

Succession planning for technical roles

Most organizations do succession planning for executives and skip it for the senior engineer who actually keeps the lights on. Figure out who would step into each critical technical role, what they’d need to learn and how long it would take, then start closing that gap now.

Change management that spreads awareness

A good change process does more than gate changes. Each change someone else reviews is a small knowledge transfer. When a second engineer has to understand a change well enough to approve it, the bus factor on that system creeps up a little.

Fix the structure that creates key people

None of this means swinging to one extreme or the other. You don’t have to push the key person out, and you can’t leave everything the way it is and hope for the best either. What has to change is the structure around them, so a new key person doesn’t grow up in their place.

That second part matters more than most people expect. Key people don’t show up by accident. They come out of how the work gets routed, who gets handed the hard tickets, who holds the credentials and what the organization rewards, and if you remove the key person and leave all of that alone, the same pressure just lands on whoever is next most capable. Give it a year or two. You’ll have a brand new single point of failure with a different name on the escalations.

That’s why the move from heroics to systems I covered earlier carries so much weight here. The root cause sits in a structure that keeps handing one person the hard problems, so spread that work out through process, rotation, shared access and peer review, and the organization quits producing a new hero to lean on.

The human side: why mitigation can feel like rejection

Most articles skip this part. All of the steps above are sound risk management, but to the key person a lot of them can feel like being pushed out.

Think about it from their seat. They’ve been the go-to for years. They’ve given up nights, weekends and the occasional holiday dinner to keep things running. Then they start noticing changes.

Exclusion from decisions. Meetings they used to lead now happen without them, because leadership is deliberately building decision-making capacity elsewhere.
Pressure to diffuse knowledge. Suddenly everybody wants documentation, walkthroughs and knowledge transfer sessions, often on a deadline.
Overlapping hires. A new person shows up with skills that look a lot like theirs, and nobody explains why.
A narrative shift. Wins that used to be credited to them by name start getting credited to “the team” or “the process.”
Fewer late-night calls. Which sounds like a gift, until it starts to feel like being taken off the roster.

Any one of those, done without explanation, reads like a demotion. Put them all together, done quietly, and it reads like the business is getting ready to show them the door. The irony is that key-person mitigation, handled badly, can cause the very departure it was supposed to protect against. Your most capable, most committed engineer decides they’re not wanted anymore and takes a job somewhere that does want them. Now you’ve got the risk you were trying to avoid on a shorter timeline, with less knowledge transfer than if you’d done nothing at all.

Advice for leaders

If you’re the one doing the mitigating, a few things go a long way.

Be transparent about the why. Say it out loud. “We’ve built too much dependence on you, and that’s a risk to the business and frankly unfair to you. We’re going to fix it, and we need your help to do it.” People can handle a lot when they understand the reasoning. What they can’t handle is being left to guess.

Frame it as resilience. You’re adding redundancy to a critical system, and the person is part of that system, so make it clear nobody is being demoted. Nobody thinks less of the primary core switch when you install a second one.

Give them a growth path. The natural next step for a key technical person is usually an architect, principal engineer, mentor or technical lead role, where their value comes from judgment, design and developing others rather than from being the only one who can do the work. Make that path real, with a title, scope and compensation to match.

Keep them in the room for the right decisions. Pulling someone out of day-to-day operations makes sense. Pulling them out of strategic decisions they’re uniquely qualified to inform doesn’t, and it’s worth knowing the difference.

Credit the transfer. When the key person documents a system, trains a teammate or automates themselves out of a task, recognize it as loudly as you used to recognize the 2 a.m. saves. Whatever you celebrate, you’ll get more of.

Advice for the key person

If you’re the one everybody calls, here’s my honest take. Lean into it.

Document before you’re asked. Write the runbooks, draw the diagrams and write down the reasons behind the designs. Doing that proves your value instead of giving it away.

Teach. Pair with junior engineers and let them drive. Answer the same question three times if you have to. The best engineers tend to measure themselves partly by how many other people they’ve made capable.

Get valued for judgment rather than gatekeeping. Being the only person who can do something gives you some pull, but it’s fragile, and it keeps you stuck doing the same work forever. Being the person whose judgment everybody wants on the hard calls lasts a lot longer, and it goes with you wherever you go.

Recognize the freedom in being replaceable for tasks. Each task you hand off is time you get back for bigger work like architecture, strategy, mentoring and the projects that actually move the business. You can’t climb the ladder if you’re the only one holding it steady.

Ask the direct question. If you’re seeing the signs above and nobody’s explained them, ask your leader plainly whether this is a resilience effort and what your role looks like on the other side of it. Most of the time the answer will be more reassuring than the silence.

A practical key-person risk checklist

If you want to start this week, here’s a short list you can work through with your team:

List your critical systems and services, the ones the business can’t operate without.
For each one, identify who can operate it, troubleshoot it, change it and design it. Flag every system where that’s only one person.
Pull six to twelve months of incident and escalation data and look for names that show up as the final resolver over and over.
Audit privileged access. Make sure at least two people can reach every critical system, and move credentials into a shared, audited vault.
Write or update runbooks for the top five highest-risk, highest-concentration systems first.
Schedule pairing on the next few changes and maintenance windows, with the backup person driving.
Add critical systems to the on-call and escalation rotation so more people get real experience.
Move repeatable configuration into version control and automation, and make sure more than one person can read and maintain it.
Create and test a break-glass procedure for each critical system.
Name successors for critical technical roles, not just leadership roles.
Talk openly with your key people about what you’re doing and why, and define their growth path before the changes start.
Revisit the bus factor exercise every six months. Concentration creeps back in quietly.

Wrapping up

Key-person risk is easy to ignore because it looks like things are working. The outages get fixed, the projects get delivered and the person in the middle of it all seems fine. A business that can only function when one specific person is available is running on luck, though, and luck makes a poor plan.

Leaning on great people is fine. Letting the business depend on any one of them alone is the part to stop. Done right, the business gets resilience and the team gets more capable, and the key person finally gets a vacation where the phone doesn’t ring. Done carelessly, it drives off the very person you were trying to protect yourself from losing. It’s the old advice about not putting all your eggs in one basket, and the trick is not kicking the basket over while you’re moving the eggs.

If you’re working through this on your team, from either side of the table, I’d love to hear how it’s going. Figure it out together. It’s faster that way.

73,
Ryan

Key-Person Risk in Technology: How to Spot, Measure and Fix Your Bus Factor