Name the engineer whose resignation email would ruin your quarter.
You had a name before the sentence ended. Most leaders do. What almost nobody has is the second name, the third, or a number that says how deep the bench really goes. The first answer is instinct. The rest is risk management, and most software organizations have never done it.
Here is the claim I want to defend: most software organizations are at most two departures away from stalling, and they have never measured the distance. Not because the risk is hidden. Because nobody counted.
A Number, Not a Feeling
Engineers call this the bus factor: the smallest number of people who, if they vanished tomorrow, would leave a system nobody can confidently change. The name says something about the profession's optimism. In our imagination, nobody ever takes a better offer or burns out quietly. They have to get hit by a bus.
The nickname makes it sound like trivia, a morbid icebreaker for retros. Wrong category. It is a number, it has a peer-reviewed estimation algorithm, and it has been computable from your git history for a decade.
Avelino and his co-authors ran exactly that computation across 133 popular GitHub systems and found that 65 percent had a truck factor of two or less. Two departures from stalling, in well-known projects with global contributor pools and every line of code in public view. I see no reason to believe the average private codebase, written under deadline and reviewed by nobody outside the building, does better.
And git history flatters you. Commit analysis sees who wrote the code. It does not see who reviews everything, who unblocks every stuck thread, who carries the memory of why the billing system has that one terrifying feature flag. Some of your most dangerous dependencies have thin commit logs and full calendars. If your audit only reads the repository, your real number is worse than the one on the screen.
So measure properly, then run the cheapest audit in the industry: send each key person genuinely offline for two or three weeks and keep a written log of everything that stalls and everyone who pings them anyway. That gap log is your succession plan in draft form, written by reality instead of by HR.
The Clock Is Already Running
The standard objection arrives on cue: our people are happy, nobody is leaving. Maybe. But tenure has a curve, and it is shorter than your roadmap. Nash Squared surveyed just over two thousand technology leaders across 62 countries and found they expect to stay in their current role for 3.3 years on average. Not the disgruntled ones. The average ones.
That number converts every key-person dependency from a hypothetical into a dated liability. If your architecture lives in one head, the expected case, not the unlucky one, is that the head is somewhere else within three years. You do not get to schedule the departure. You only get to schedule the preparation.
The cost of getting this wrong is documented at the very top of the org chart. Harvard Business Review put the market value wiped out by badly managed CEO and C-suite transitions at close to a trillion dollars a year in the S&P 1500 alone. Boards already treat CEO succession as standing scenario planning. Almost nobody runs the same exercise on the staff engineer who is the only person able to deploy the thing the company actually sells. The title is smaller. The dependency is not.
Nobody Is Coming
There is a comforting story we tell about departures: someone steps up. The repository is still there, the docs are mostly fine, a capable replacement absorbs it all in a quarter. Open source gives us a way to test that story at scale, and Nourry and colleagues did, across more than 36,000 projects. Of the projects that lost all their core developers, only 27 percent ever attracted a replacement. The rest just stopped.
A company can do something an open source project cannot: pay someone to show up. But you are hiring a body, not the map. The new hire receives the code. They do not receive the decade of rejected alternatives, the constraints nobody wrote down, or the list of things that look refactorable and are actually load-bearing.
The standard mitigation fails too. The notice-period knowledge transfer, two weeks of walkthrough meetings while the departing engineer's heart is already at the next job, is theater. Nobody retains a passive tour of a decision engine. Knowledge moves when the receiver does hands-on work with the expert reviewing rather than driving, and that takes calendar time you do not have once the resignation lands. Transfer works in peacetime. The time to start was before anyone resigned, and the second-best time is this quarter.
Replaceable on Purpose
I run an AI engineering studio with more than 65 engineers, and the question I ask myself most often is uncomfortable in exactly the right way: what stalls if I disappear? If the honest answer is "a lot," then I have not built a company. I have built a bottleneck with a personal brand.
So I treat my own replaceability as a design requirement, the same way I treat uptime. Hand off one real responsibility every quarter, permanently and visibly. Grow two candidates for every critical role, because a single anointed successor is a bet, and bets miss. Promote people for making others capable, and stop rewarding indispensability. An irreplaceable engineer is a failure of the system around them, and most organizations quietly pay people to stay irreplaceable.
The same conviction shapes how we work with clients. Our integrated teams carry a three-month minimum, and this essay is the reason: code ships in weeks, but judgment transfers slowly, through working together on real systems. An outside team that leaves and takes the understanding with it has not lowered your bus factor. It has rebranded it. We refuse to become the dependency we were brought in to remove.
Engineer It Down
Bus factor responds to engineering the way latency does: measure, set a target, work the levers, re-measure. We compressed everything we know about those levers into The CTO Succession Framework, 48 checks across measurement, knowledge transfer, documentation, deputy development, org design, and board governance, with every statistic re-verified against primary sources. If you only take five things from it, take these:
- Run a truck-factor analysis on every production repository, quarterly, and govern the trend rather than the snapshot.
- Cross-check the scores against review load and meeting load, because the glue people never show up in commits.
- Run the vacation test and treat the gap log as a work queue, not an anecdote.
- Replace walkthrough meetings with hands-on transfer, verified by the receiver operating the system with the expert out of the room.
- Develop deputies with real, permanent handoffs, and start years before any expected departure.
None of this is glamorous. That is rather the point. The companies that survive departures are not the ones with heroic engineers. They are the ones where heroism became unnecessary, one handoff at a time.
Two departures. For most teams, that is the whole distance between a roadmap and a standstill. You can find your real number this quarter with a script, an honest afternoon, and the willingness to hear the answer. Or you can find it the way most companies do: during a four-week notice period, with years of context to transfer and nothing but goodwill to transfer it with.
I know which postmortem I would rather not write.