Your Acquirer Will Find Your Bus Factor Before You Do

TL;DR: If a raise, acquisition, or serious partnership is anywhere in your future, a stranger will eventually clone your repositories and compute how concentrated your engineering knowledge is. The estimation method is public research; the git history it reads is one you can't retroactively edit. Every finding they'd write, you can find first, months earlier, while it's still fixable instead of priceable. Below: what they'll compute, and how to have already read your own report.

Somewhere in your company's future there's a data room, and in it, an analyst you've never met with read access to everything your team has ever merged. They will not be reading your architecture diagram. They'll be reading the diary your org has been keeping for years without meaning to: who actually built each system, who reviews it, and how many of those names appear exactly once.

If you haven't computed your own bus factor, the title of this article is just literally true: the first person to measure your key-person risk will be someone pricing it against you.

Why bus factor shows up in technical due diligence

What a buyer actually purchases is the ability to keep changing the code. Technical due diligence exists to price the risk that this ability doesn't transfer, and nothing threatens transferability like knowledge that lives in one head. A codebase with a bus factor of one is a retention negotiation wearing an asset costume.

That's why key-person risk gets its own line in diligence reports, next to debt and security. The buyer's question is brutally simple: if these two people decline our offer, what did we just buy?

What a diligence analyst can compute from your git history

More than most founders expect, with public methods:

• Truck factor, formally. Avelino et al. (2016) published the method a decade ago: weight authorship per file, greedily remove authors, count how many departures orphan the system. Across the 133 popular GitHub systems they studied, 34% had a truck factor of exactly 1, and around 65% sat at 2 or lower. Your analyst has read this paper. The uncomfortable base rate says the finding is more likely against you than for you.
• Ownership health, both directions. Bird et al.'s ownership research (Windows Vista/7) found more low-expertise contributors correlates with more faults and failures, while strong top-owner ownership correlates with fewer. So diligence reads concentration two ways: too diffuse looks like quality risk, too concentrated looks like continuity risk. "One clear owner plus a capable second" is the profile that reads well, which is exactly the shape succession planning builds.
• The story-versus-repo gap. If the pitch says "strong team ownership culture" and the history shows one name on 70 files and every review rubber-stamped by the same person, the contradiction itself becomes the finding. Git history doesn't negotiate.

What they can't compute - pager lore, vendor relationships, the undocumented deploy - they'll extract in interviews. The 2024 Stack Overflow survey's finding that 45.2% of developers say knowledge silos block ideas from crossing the org is the kind of ambient truth a good interviewer surfaces in an afternoon.

Run the buyer's analysis on yourself first

1. Compute your own truck factor with the honest afternoon method in how to calculate bus factor. Per area, not just per repo; the repo number hides the orphans.
2. Inventory the bus-factor-1 areas and rank by blast radius. Which orphaned area stalls revenue? Which is actively changing?
3. Spread the worst two, starting now. Review rotation plus deliberately routing the next tickets to a second person. The mechanics are in how to reduce bus factor, and the ninety-minute drill is the fastest way to find the walls git can't show you. Knowledge transfer has a floor on how fast it goes; that floor is why this starts months before any process does.
4. Write the mitigation memo. A known, mitigated concentration reads as competence; a discovered, denied one reads as a discount. One page per red area: the risk, the second person, the trajectory.
5. Protect the people the analysis names. This is the part that matters most, and not only for the deal: the engineers your map flags are your most load-bearing people, not suspects to manage. Recognition, real vacations, and retention conversations are dramatically cheaper before a diligence report makes those names leverage. A concentration map is a protect list - if any process turns it into a cut list, the analysis has been read upside down.

The report you'd rather write yourself

Everything above works as a one-time audit. Its weakness is the calendar: ownership shifts with every merge, and the audit you ran in March is fiction by August - possibly the exact month the term sheet arrives.

Busfactor runs the buyer's analysis continuously: authorship-weighted, review-aware ownership per area, the bus-factor-1 flags, and the departure simulation that turns an abstract score into a sentence a board understands - it takes two people not showing up, and eight areas become orphans - each finding linked to the commits and reviews behind it. The honest limit is the same one the analyst has: git shows authorship and review, not what's in heads or on pagers. The map tells you where to have the conversation; it doesn't replace it.

The door

The data-room version of this analysis costs you negotiating leverage. The this-week version costs ninety minutes and a repo connection. Compute your own number, fix the worst two areas, write the memo. Then walk into diligence as the person who hands over the report instead of the one who receives it.