What Losing Your Lead Actually Costs (a Real Number)

TL;DR: The afternoon your lead engineer gets an outside offer, a budget you were told didn't exist materializes in about an hour. The number that justified it was computable all along: replacement cost, ramp time, and the knowledge that walks out with them. Compute it now, from your own org's figures instead of internet folklore, and spend it early on the raise, the second owner, and the lighter pager. A cost of loss is a shield for your best people. Turn it into a ranking and you've weaponized it, and the team will know.

Thursday, 4pm. Your lead engineer, the one whose name is load-bearing in every planning meeting, asks for fifteen minutes. They have an offer. It's good. Watch what happens next: the salary band that was "unfortunately fixed" in March becomes negotiable by Friday standup. Counter-offer math is the fastest arithmetic in business.

So if the money existed all along, why did it take a resignation to compute the number that unlocked it? The cost of losing them didn't appear with the offer letter. You carried it all year, unpriced and growing with every system that quietly became theirs.

What actually walks out the door

The cost of losing a software engineer has three parts. Every one of them is computable from your own org, no vendor deck required.

Replacement. You'll pay for the search, and then you'll pay the successor's fully loaded cost from day one. Hadzima's classic MIT analysis puts a fully loaded employee at roughly 1.25 to 1.4 times base salary once benefits, space, and equipment are counted. If that multiplier is new to you, start with the fully loaded cost of an engineer. Every number downstream depends on it.

Ramp. The successor isn't productive on arrival, and the ramp runs longer than any hiring plan admits: months of loaded cost before confident shipping, which is why time-to-productivity deserves its own line in the calculation. The research backs the intuition. Rodeghero et al. (2021) surveyed 267 new hires onboarding onto software teams and found that even well-resourced onboarding struggles with the hard part: building connection and context. Context is exactly what your departing lead was carrying.

Orphaned knowledge. The part salary math misses entirely. Avelino et al. (2016) found 34% of 133 studied systems had a truck factor of exactly 1 - one person whose exit orphans code. If your lead is that person for three areas, their departure is a vacancy plus three uncovered systems. A new hire cannot re-learn those from a wiki. As every key-person risk story goes, the wiki was never the real documentation.

A note on the numbers you won't find here. The internet is full of confident turnover multipliers, "losing an engineer costs six to nine months of salary" and its cousins. We couldn't trace those to a primary source worth citing, so we won't quote them. No great loss. A range built from your loaded cost, your last three hiring timelines, and your git history beats a folklore multiplier in any budget conversation, because every input is defensible.

One boundary, stated as policy: this number prices the vacancy, never the person. It exists to defend raises, backup owners, and saner pagers. The moment cost-of-loss becomes a leaderboard of who's "worth" more and who's cheap to lose, you've built a firing signal out of a retention tool. Your best people will smell it immediately.

Price it this hour, for free

1. Pick your org-average loaded cost. One number, the org average, deliberately not any individual's salary. Every later figure inherits its honesty.
2. Estimate replacement time from your own history. How long did your last three senior hires take, from opening the req to start date? That's your search window, and during it the work either stalls or lands on the rest of the team.
3. Price the ramp. Months to confident shipping (your onboarding history knows) times loaded monthly cost. Be honest; hiring plans always round this down.
4. Map the orphans. From 12 months of git history: which areas would lose their only confident owner or reviewer? The method is the same one behind the bus factor fire drill. If the answer is "three areas, no backup," your cost of loss just tripled quietly.
5. Build the protect list. For the two or three people whose loss prices highest, pick one concrete retention move each, this month. A criticality-to-pay check, because the most expensive engineers to lose are often quietly paid below market. A second owner on their areas, so vacations become real. And a look at their working rhythm, because the person everything routes to is usually the one absorbing the after-hours load. Sustained overwork is how team health erodes long before the resignation email.

The point of the hour is timing, not precision. Every retention move on that list is dramatically cheaper before the offer letter than after it, and some (trust, rest, growth work) can't be counter-offered back at all.

How you'd actually see it

The manual version goes stale as ownership shifts. Busfactor's person and team scorecards keep it current: an honest, retention-framed profile of every person. Strengths first, then what breaks if they vanish, where to invest, and what losing them would cost as a low-high range computed on disclosed org-average assumptions. Never their salary, which the system doesn't read. The firewall is structural rather than a promise: no composite score, no sortable column, no compare view - the scorecard grammar cannot express a stack rank, so the number can't be quietly turned into a cut list.

The honest limit: this prices impact. Whether someone is actually thinking of leaving is not a model output, and any tool selling you a flight-risk score on your people is selling surveillance with a dashboard on it. Price the impact with receipts. Learn the likelihood by being the kind of manager people tell the truth to.

The door

The number in the title already exists - the only choice is when you meet it. Meet it on a Thursday at 4pm and it arrives with a two-week deadline and a counter-offer you'll overpay for. Meet it this week and it's budget math: a raise here, a second owner there, a pager that finally rotates. Run the hour. If you'd rather the impact side compute itself, with the receipts attached, connect your repos and open the scorecards.