𝗧𝗵𝗲 𝟭𝟭-𝗟𝗶𝗻𝗲 𝗟𝗶𝗯𝗿𝗮𝗿𝘆 𝗧𝗵𝗮𝘁 𝗕𝗿𝗼𝗸𝗲 𝘁𝗵𝗲 𝗜𝗻𝘁𝗲𝗿𝗻𝗲𝘁

In March 2016, a developer named Azer Koçulu unpublished a tiny NPM package called left-pad. It padded strings on the left. 11 lines of code.

Within hours, builds across JavaScript started failing. Babel broke. React broke. Thousands of projects that had never heard of left-pad couldn't compile, because something deep in their dependency tree quietly relied on it.

One person walked away from a function nobody thought was important, and large parts of the internet stopped building.

This is the Bus Factor. The number of people who, if hit by a bus, would put your project in serious trouble.

A bus factor of 1 means one person holds the critical knowledge. A bus factor of 5 means you could lose any one of five specific people before the work stops. The metric is brutally simple, and it's almost always lower than people think.

You see it everywhere:

A startup has one engineer who understands the legacy billing system. They take a long vacation, and the team realizes nobody else can debug a single invoice issue.

A 50-engineer codebase has two or three people who actually know how the deployment pipeline works. The onboarding doc says "ask Maria."

The Linux kernel has thousands of contributors, but several subsystems run on a single active maintainer. If they step away, that part of the kernel is in trouble until someone else learns it.

Open source projects measure their health partly by how many maintainers can drive things independently. A bus factor of 1 is a warning sign. The left-pad incident is what happens when you have hundreds of bus-factor-1 dependencies and one of them disappears.

Now stack the bus factor against the 𝗗𝗲𝗮𝗱 𝗦𝗲𝗮 𝗘𝗳𝗳𝗲𝗰𝘁. In bad organizations, the best engineers leave first, because they have options. The ones who stay are often the ones who can't easily find work elsewhere. Talent evaporates and mediocrity accumulates. Like the Dead Sea, where water escapes but salt remains.

Combine low bus factor with the Dead Sea Effect and you get organizations where critical knowledge is held by people who are increasingly the wrong people to hold it. The institutional knowledge isn't institutional. It's locked inside a few heads, and the strongest of those heads are leaving first.

The fix is straightforward:

𝗣𝗮𝗶𝗿 𝗽𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 on critical systems. The second person doesn't have to write the code. They have to understand it.

𝗖𝗼𝗱𝗲 𝗿𝗲𝘃𝗶𝗲𝘄𝘀 that aren't rubber stamps. A real review forces the reviewer to learn the code well enough to push back.

𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 written for the engineer who joins next year, not the one who already knows. Runbooks for failure modes. ADRs for the why, not just the what.

𝗥𝗼𝘁𝗮𝘁𝗶𝗼𝗻𝘀. On-call is the one place most teams already do this. Extend the principle. Rotate ownership of subsystems, deployment, incident response.

The honest test: pick a person. Could the team ship next quarter without them? If the answer is no, you don't have a star. You have a single point of failure, and the team is one resignation away from a left-pad of your own.