Key-Person Risk: The Quiet Threat in Every Codebase

TL;DR: Key-person risk is what your org carries when one engineer's absence would stall a critical system. It forms silently, out of perfectly reasonable decisions, around your best people. Truck-factor research on 133 popular GitHub projects found 34% would stall if a single developer left. The person is never the problem; the routing is. The fix is systemic (spread ownership, rotate reviews, document hot paths) and it starts with protecting the human at the center, not blaming them.

Every engineering org has at least one: the person about whom someone eventually says, half joking, "we're in trouble if she ever leaves." Everyone laughs. Nobody writes it down. Nobody prices it. And the org keeps making the exact decisions that deepen it - because every one of those decisions, taken alone, is correct.

That's key-person risk: the quiet, compounding exposure that never appears on a risk register until the day it converts, at full price, into an incident with a farewell card.

What is key-person risk?

Key-person risk is the concentration of critical knowledge, access, or judgment in a single human, such that their absence (resignation, illness, parental leave, or a two-week vacation) materially disrupts the organization. Finance has insured against it for decades. Engineering mostly hasn't, even though software concentrates knowledge more aggressively than almost any other discipline: the map of why a system is the way it is lives in heads, not in the code.

Its codebase-level cousin is the bus factor: the count of people who must disappear before a project stalls. Key-person risk is the same exposure seen from the org chart: not "this repo has one owner" but "this person is load-bearing across that repo, the deploy pipeline, the vendor relationship, and every incident bridge." Git sees a subset of it. The org feels all of it.

How key-person risk forms (hint: nobody's fault)

No one decides to create a key person. The system does it through incentives that are locally sensible every single time:

• Speed routing. The payments bug goes to whoever fixes payments fastest. Every time. Three years of that and there is exactly one payments engineer, made - not born.
• Review gravity. Their approval means the most in the domain, so every PR waits for them, so nobody else builds judgment, so their approval means even more. The loop closes.
• Competence rewarded with load. The reliable person gets the on-call, the migration, the "can you just look at this," each yes narrowing the org's options while looking like its strength. Much of that load is glue work: load-bearing, invisible in every metric, and concentrated on exactly the person you can least afford to lose.
• Heroics applauded, prevention invisible. The 2 a.m. save gets a shoutout; the documentation that would have prevented it gets nobody promoted.

Note what's absent from that list: hoarding, ego, malice. The stereotype of the engineer who guards knowledge for job security exists but is rare. The common case is the opposite: the generous expert who kept saying yes while the system kept routing everything their way. This is why the fix is never "have a word with them." They didn't build the funnel. The org did.

The base rate is worse than you think

More common than any leadership team assumes. When Avelino et al. estimated truck factors for 133 popular GitHub systems, established and widely-used projects, they found 45 of them (34%) had a truck factor of 1 and roughly 65% sat at 2 or lower. A third of the studied ecosystem was one departure from stalling, and these were the successful projects.

The everyday cost runs even while everyone's still employed: in the 2024 Stack Overflow survey, 45.2% of professional developers said knowledge silos prevent them from getting ideas across the organization, and 30% said silos hit their productivity ten or more times a week. A key person is a silo with a badge photo - the queue behind them, the estimates only they can give, the vacation they can't quite take. The departure just presents the final invoice.

And if the company is ever acquired or raises seriously, somebody else runs this count for you: concentration is a standing item on the technical due-diligence checklist, where a one-person system stops being an engineering worry and becomes a retention clause, an escrow, or a price adjustment.

How to spot it before it converts

The evidence is already in your systems. Three concentration checks:

1. Authorship: areas where one person lands nearly all meaningful changes over 6-12 months, the raw input to a bus-factor calculation.
2. Review: areas where authorship looks spread but one name approves everything. A sole qualified reviewer is a single point of failure who also happens to be a bottleneck.
3. Escalation: incidents, pages, and "quick questions" that always route to the same person. Your on-call history and Slack know who this is even when git doesn't.

Then rank by blast radius, the same way you'd triage knowledge silos: a key person on a revenue-critical, actively changing system outranks ten on peripheral ones. A ranked list of three beats an unranked list of thirty.

Fixing the system without punishing the person

The cardinal rule: the key person is an asset at risk, not a risk to be managed out. Handle it clumsily, with expertise "redistributed" in a way that reads as demotion, and you convert a retention problem into a resignation, which is the risk arriving early with a grudge.

The moves that work target the routing, not the human:

• Rotate a second reviewer into their domain; reviewing is how outsiders earn context.
• Route the next real feature in the area to someone else, with the expert reviewing instead of writing. Toy tasks don't transfer knowledge; real stakes do.
• Document the hot paths only: the code that churns most, the runbooks for what actually pages. Encyclopedic wikis rot; targeted docs get read.
• Unload them visibly. Take the unglamorous on-call and the interrupt queue off their plate as knowledge spreads. The goal state is a person who can take three weeks off with their laptop closed - which, not incidentally, is also what makes them stay.

This is the protect-and-grow half of team health: knowing exactly what you'd lose with each person is a retention signal, not a ranking. The door: name your top three key people this week - you already know who they are - and for the one with the biggest blast radius, schedule the first ownership rotation this sprint. The cheapest time to reduce key-person risk is always the same time: before the resignation email teaches you its price.