What Happens When Your Best Engineer Quits?

TLDR: We ran Supabase through our Bus Factor Calculator. Bus factor of 10, top 2 contributors own 16% of commits, and the AI identified three risk tiers — including one contributor rated CRITICAL as a single point of failure. Calculate yours → intelig.ai/tools/bus-factor

Every engineering org has one.

The person who knows where the bodies are buried. The one who built the authentication layer, wrote the deployment scripts, and is the only human who understands the billing integration. The person everyone Slacks when something breaks at 2am.

What happens when that person quits?

The math is brutal

We pointed our Bus Factor Calculator at Supabase — one of the best-run open-source companies in the world. Result: Bus factor of 10. Top 2 contributors own 16% of all commits. Risk level: MODERATE-HIGH.

The AI went deeper. It classified contributors into three risk tiers. Tier 1 (Immediate Concern): one contributor with 13 commits across 3 repos — multi-repo presence means cross-cutting knowledge. Another contributor also at 13 commits but concentrated in a single repo — rated CRITICAL because if that repo is a core service, they’re a single point of failure.

That’s not a criticism of Supabase. They’re well-run. But even in a strong org, concentration happens naturally.

Now imagine your org. Closed source. Probably less documentation. Fewer contributors per repo. The concentration is almost certainly worse.

Key-person dependency is silent

Nobody puts “key-person risk” on the quarterly risk register. It doesn’t show up in sprint retrospectives. Jira doesn’t track it. Your project manager has never mentioned it.

But it’s the single most common cause of catastrophic knowledge loss in engineering teams.

Here’s how it plays out:

Week 1. Senior engineer gives two weeks’ notice. Everyone says “we’ll be fine.”

Week 3. Team realizes that engineer was the only person who understood the CI/CD pipeline configuration, the database migration strategy, and three critical integrations.

Month 2. Velocity drops 40%. New hires can’t onboard because the documentation that engineer “was going to write” never got written.

Month 4. CTO is explaining to the board why the roadmap slipped a quarter.

I’ve watched this happen at multiple companies. It’s always the same story.

What the calculator shows you

Paste any public GitHub org URL. In about 60 seconds, you get:

• Bus factor score — how many people would need to leave before critical knowledge is lost
• Top contributor concentration — percentage of commits owned by the top 1, 3, and 5 contributors
• Per-repo breakdown — which repos are single-points-of-failure
• Risk distribution — visual breakdown of contribution concentration

The repos with a bus factor of 1 are your emergency list. Those are the systems where one resignation creates a crisis.

What you do with this data

First, stop pretending it’s not a problem. Every engineering leader I know acknowledges bus factor risk in theory and ignores it in practice. Theory doesn’t prevent outages.

Second, prioritize knowledge distribution. Take your bus-factor-1 repos and create explicit pairing rotations. Not “we should pair more” — actual scheduled work where a second engineer builds real context.

Third, document the undocumented. The stuff that lives in one person’s head — deployment procedures, architecture decisions, integration quirks — needs to be written down. Not in a wiki that nobody reads. In the code, in READMEs, in ADRs that live next to the systems they describe.

Fourth, make this a recurring metric. Bus factor should be on your engineering health dashboard alongside velocity, cycle time, and incident rate. Check it monthly.

The question

Can you name the person whose departure would hurt your engineering org the most?

Now: can you quantify exactly how much damage that departure would cause?

That’s the difference between gut feeling and engineering intelligence.

Calculate your bus factor now — free, no sign-up →