On a Tuesday afternoon in March 2016, software builds began failing at technology companies around the world. The cause traced back to a dispute involving a developer named Azer Koçulu and a seemingly insignificant piece of JavaScript code.
Koçulu had published hundreds of software packages on npm, the widely used registry where JavaScript developers share and download code. One of his packages was named kik. When the company behind the Kik messaging app claimed the package name, npm sided with them under its package-name dispute policy. Koçulu objected and, in protest, unpublished all 273 packages he maintained. Among them was a tiny package called left-pad. It was eleven lines of code that added spaces to the front of a text string so it lined up. A first year computer science student could write it over lunch.
Builds broke within minutes. Facebook, Netflix, Spotify, PayPal and Airbnb all shipped software that depended on left-pad, most of them without knowing it. Popular tools required it, other tools required those tools, and eleven lines of string padding held up a large share of the JavaScript ecosystem. No one had traced the chain, because nothing had ever forced anyone to. npm then did something it had never done before, restoring a package over its author’s objection, and rewrote its rules so that a widely used package cannot vanish on an afternoon. The outage was over in hours. People still tell the story ten years later because one person maintained eleven lines that much of the internet leaned on, and many people did not know until the lines were gone.
The story travels because you can see your own organization in it. Randall Munroe drew the same idea in xkcd 2347: the whole edifice of modern digital infrastructure stacked into a tower, the entire weight resting on one narrow block near the bottom, labeled “a project some random person in Nebraska has been thanklessly maintaining since 2003.” We laugh at that cartoon, then we think about our own org chart and stop laughing.
Engineers named the risk with a joke. The bus-factor is the number of people who would have to be hit by a bus before a project stops. Use a lottery win instead of a bus if you prefer the cheerful version. A bus-factor of one means one person understands billing reconciliation, or holds the only working knowledge of the legacy service, or knows how a Friday release gets deployed. That person is your left-pad. Their importance stays invisible until the morning they are not there.
Non-engineers read this as an open source curiosity and file it under someone else’s problem. Look at your own function. Finance has a left-pad, the analyst who knows how the quarterly close runs as opposed to how the close is documented. Sales has one, the account executive holding the personal relationships with your three largest customers. Operations has one, the person your critical vendor will pick up the phone for. Legal has one. HR has one. Your leadership team probably does too. Wherever hard won, undocumented knowledge sits in one head, you have a load-bearing human. The stronger your team, the more of them you have, because you keep routing the hard work to whoever handles it best. Shorter tenures and more complex systems tighten the concentration further.
Most of the incentives in your organization work to keep key person risk out of sight.
Heroics get rewarded. The person who swoops in at midnight to fix the thing only they understand gets praised and promoted. The colleague who spent that same week writing the runbook that would have prevented the midnight call gets nothing, because you cannot celebrate an outage that never happened. Your recognition budget flows to firefighters, and almost none of it reaches whoever fireproofed the building.
Redundancy looks like waste. Cross training a second person on one critical job costs real time this quarter to protect against a loss that may never arrive. On a spreadsheet it reads as slack, and slack gets trimmed. This is the same reasoning that leads a comfortable organization to cut its safety and sensing functions in a good year, and to rebuild them in a hurry after a bad one.
Indispensability feels good. Being the only person who can do something is job security and a source of pride. Most load-bearing people are not hoarding anything. They have no incentive to make themselves replaceable and a quiet emotional reason not to, and you have never asked them to, because the work keeps getting done. You will not get a warning while the key person is still showing up every day.
In early 2024 an attacker came close to compromising a large share of the servers on the internet, and the whole operation ran through one tired maintainer. XZ Utils is a compression tool that ships inside almost every Linux distribution, which puts it inside most of the machines running the internet. For years one unpaid maintainer carried it alone, for little reward. Someone using the name Jia Tan, helped by accounts researchers believe were sock puppets, spent roughly two years posing as a generous contributor and pressuring that maintainer, until Tan held co-maintainer status, commit access and release authority. Tan then shipped a backdoor that would have opened remote access to an enormous number of machines.
Andres Freund, a Microsoft engineer working on something else entirely, caught it. He noticed odd CPU usage and errors in a memory debugger, then found SSH logins running about half a second slower than they should, and he kept going until he found the code. No automated system flagged any of it. One of the most consequential single points of failure in open source turned out to be an exhausted volunteer, and the save came down to one engineer with the curiosity to chase half a second slowness.
This is the shadow side of a theme I wrote about in The Vital Few. That piece was about performance concentrating in a small number of people and the obligation leaders inherit when it does: support the people carrying the load, and build more people who can carry it. Key person risk is that same concentration taken past the point of safety. Your strongest people become your load-bearing people because competence attracts responsibility, and you keep handing the hard work to whoever handles it best until the organization is built around one person’s continued presence. Stewardship means the organization survives their departure, their illness, their burnout, or in the XZ case, someone hunting them.
None of this requires an attacker. In 2016 Nadia Eghbal documented the pattern for the Ford Foundation in a report called Roads and Bridges, which traced how much of the digital world runs on infrastructure maintained by unpaid or barely paid volunteers. Her signature example was OpenSSL, the encryption library then serving roughly two thirds of web servers with a handful of maintainers, one full time employee and about two thousand dollars a year in donations. A security bug nicknamed Heartbleed, released in 2012 and found in 2014, made that impossible to ignore for many companies. Once you know the shape, you start seeing it in your own spaces.
You are not trying to diminish these people. You are trying to find the risk while you still have room to do something about it.
Run a bus-factor audit. Sit with your team and ask, for every critical system and process, how many people could do this if the primary were gone tomorrow. Where the answer is one, write the name down. An unnamed risk never makes it onto anyone’s plan.
Run the vacation test and mean it. Two weeks off the grid is the cheapest diagnostic you own. If the operation degrades while someone is on a beach, you found a single point of failure at the best possible price, since the person is still reachable if it gets bad enough. Dedication is the wrong lens for that result. Fragility is the right one.
Reward the fireproofers. Change what you applaud. Reward the documentation, pairing, cross-training and deliberately unglamorous work that makes the organization less dependent on any one person. If recognition only follows heroics, you are teaching your best people to keep what they know to themselves.
Make redundancy a design principle. Rotate responsibilities. Pair people on critical systems. Require that important knowledge lives in writing and in a second head. Treat a bus-factor of one the way you treat a production server with no backup, as a defect with an owner and a due date.
This week, find your left-pad. Pick your most critical system, process or relationship and name the one person holding it up. Then ask what happens if that person is unreachable for a month starting tomorrow. If the answer scares you, write it down before the feeling passes, because these risks survive on the decision to think about it later. Resignation letters rarely arrive with months of warning, and illness and burnout give even less. You get to choose whether you learn this on a Tuesday you picked, or on a Tuesday that picks you.