Bus Factor: What It Is and Why Most Teams Ignore It

Bus factor is the number of people who could disappear from your engineering team tomorrow before a project grinds to a halt. Most teams don't know their own number. I watch this closely in Abloomify's own 4-person engineering team, and I've seen bigger teams get burned by it too: one senior engineer leaves, and suddenly nobody can safely touch the billing service.

A: A bus factor of 1 means a single person holds enough unique knowledge that if they left today, got sick, or took a new job, the project would stall. It's the most severe score on the scale and more common than most engineering leaders assume, especially on lean teams of 5-10 engineers shipping fast without anyone tracking ownership.

A: There's no single formula. Count how many people would need to leave before nobody understands a critical repo, deployment process, or integration well enough to change it safely. Abloomify approximates this from connected GitHub data: PR ownership concentration, review participation, and self-merge rate, then flags the repos where one person owns nearly everything.

A: Not always. A 3-person startup will have a bus factor of 1 on almost everything, and that's fine at that stage. It becomes a real risk once you have 20+ engineers and real revenue riding on a system only one person can safely change. The goal isn't zero risk everywhere, it's knowing which risk is on purpose.

A: Tools like Cursor and GitHub Copilot let one engineer generate far more code per day, which can raise bus factor risk instead of lowering it if that code never gets a second reviewer. Abloomify tracks human vs AI-agent contribution across PRs and reviews so leaders see when velocity concentrates knowledge in fewer people.

A: Require a second reviewer on every PR touching the flagged repo, then pair the sole owner with someone else for the next real change. A wiki page written once a year doesn't substitute for a second person who has actually shipped code there.

Bus factor is a software engineering term for how many people on a team would need to leave, quit, get sick, or (the original, morbid framing) get hit by a bus, before nobody left understands a critical system well enough to keep shipping it safely. The lower the number, the more fragile the team. A bus factor of 1 means one person is the sole keeper of that knowledge: the deployment script nobody else has run, the billing integration only they've touched, the client relationship only they manage. It isn't about headcount. A 40-person engineering org can still carry a bus factor of 1 on its most important service if only the person who built it ever goes near it. The term started in open-source projects tracking maintainer risk, but it applies just as hard inside a funded startup with a roadmap and a board deck.

Here's the part that surprises people: bus factor usually isn't visible in a standup. The person who's become a single point of failure is often your best engineer. They ship fast, they don't complain, and nobody notices the risk until they're out for two weeks and three tickets nobody else can touch pile up behind them.

There's no industry-standard formula for bus factor, which is exactly why most teams never measure it. The closest thing to a repeatable method is looking at four signals together: who authored the most commits in a repo over the last 90 days, who reviewed those PRs (or whether anyone reviewed them at all), who's the only person who has ever touched a given file or service, and who's the only one on the on-call rotation who can actually resolve an incident in that area without escalating. A repo where one person wrote 80% of the commits and reviewed none of their own work still has a bus factor problem if nobody else reviewed it either. The honest exercise is uncomfortable: name your five most important services, then name every person who could safely deploy a change to each one tomorrow without asking a question first. If any list has one name on it, that's your bus factor.

AI coding assistants make bus factor worse before they make it better, and almost nobody plans for that. The mechanism is simple: a single engineer using Cursor or GitHub Copilot can now generate, refactor, and ship meaningfully more code per day than they could two years ago. If that extra output gets the same review scrutiny as before, fine. If it doesn't, because the team is moving fast and reviewers are stretched thin, you've just made your existing bus factor problem worse and faster. The engineer who was already your sole owner of the billing service is now shipping three times the code in that service, alone, with an AI tool nobody else is watching over their shoulder. Velocity went up. Risk went up with it. Most teams only track the first number.

I switched Abloomify from GitHub Copilot plus ChatGPT to Cursor back in January, and it was one of the best calls I made all year for raw output. It also made me pay closer attention to who was reviewing what, because faster shipping with the same reviewer bandwidth just means more unreviewed surface area per person, not less risk. This is exactly why Abloomify separates human vs AI-agent contribution across code and reviews instead of just reporting total PR volume: a velocity number that doesn't show who actually looked at the AI-assisted output is telling you half the story.

Fixing bus factor doesn't mean slowing down, it means changing who touches the risky work, not how much work gets done. Start by identifying the two or three repos or services where a single person owns the most PR volume and the least review coverage; that's your actual risk map, not a guess. Then apply the fix in order of cheapest first: require a genuine second reviewer (not a rubber-stamp approval) on every PR touching those repos for a fixed period, rotate on-call responsibility for that service even if it means the original owner is on standby for the first few incidents, and pair the sole owner with one other engineer on the next real feature or bug fix there, not a toy ticket. Documentation matters, but it's the last step, not the first. A wiki page written by the person who already understands the system doesn't transfer the tacit knowledge of what breaks and why nearly as well as a second person actually shipping a change.

Most leaders find out about a bus factor problem the hard way: someone leaves, and three weeks later a bug in a system nobody else understands takes down a customer-facing feature. Abloomify's engineering productivity analytics connect to GitHub, GitLab, Bitbucket, Jira, and Linear and compute the underlying signals continuously instead of once a year during a headcount review. PR flow analytics show cycle time, time to first review, self-merge rate, and code velocity per person, alongside DORA metrics banded Elite through Low. Workload balance across the team surfaces who's carrying disproportionate ownership before it becomes a crisis. And because Abloomify separates human vs AI-agent contribution across code and reviews, a VP of Engineering can see exactly where AI-assisted output is concentrating risk in one person instead of distributing capability across the team.

One of our customers, a 50-person Canadian SaaS company, put it well after connecting their GitHub and Jira data: "What I did manually this week in a spreadsheet is exactly what I think Abloomify should be doing automatically." That's the same manual exercise most teams run once, if ever, to find their bus factor risk. The 10-Day Engineering Velocity Pilot delivers a team health scorecard with DORA bands, a PR bottleneck map, and a human vs AI-agent contribution breakdown, so you see where ownership is concentrated before it costs you a bad week.

Treating bus factor as a code-review problem misses the point. It's a capacity and continuity problem that happens to show up first in a git log, and it belongs on the same list a COO already tracks: capacity gaps, workload imbalance, and where output would break if one person walked out tomorrow. The same pattern shows up outside engineering too, in the one salesperson who owns every enterprise relationship, or the one ops person who understands why a vendor contract is structured the way it is. Engineering just happens to leave a data trail through GitHub and Jira that makes the risk measurable, if anyone on the engineering leadership or operations side bothers to connect it. Most companies don't connect it. They treat capacity planning and code ownership as two separate conversations, run by two different people, reviewed on two different cadences, and then act surprised when the risk they never measured turns into an outage or a resignation nobody saw coming.

Big companies bring ceremony around this: a headcount review once a year, a risk register nobody updates. Startups that get it right just watch the signal every week. Track it before the bus shows up. Not after.

There is no universal target, but most engineering leaders treat 1 as a red flag on anything customer-facing or revenue-critical, and 2-3 as a reasonable floor for a service that matters. A 40-person org can still run parts of its stack at a bus factor of 1 if leadership never measured it. The number matters less than whether anyone is tracking it at all.

Yes. The same risk shows up wherever one person quietly becomes the only one who knows how something works: the one salesperson who owns every enterprise relationship, the one ops person who understands the billing reconciliation process, the one manager who has the only copy of a critical vendor contract. Abloomify treats it as a workforce capacity problem, not just a code problem.

Key person risk is the broader HR and business continuity term for what happens when one person leaving damages the company. Bus factor is the software engineering version of that same idea, usually measured through code ownership, PR history, and review participation instead of org charts. They point at the same underlying problem from different data.

Abloomify does not output a single "bus factor" number, but it tracks the underlying signals: PR ownership concentration, review participation, self-merge rate, and human vs AI-agent contribution split, straight from your connected GitHub, GitLab, or Bitbucket data. Those are the same inputs most manual bus factor exercises use, just computed continuously instead of once a year.

Require a second human reviewer on every PR touching the flagged repo for the next two sprints, and pair the sole owner with one other engineer on the next non-trivial change to it. Documentation helps later. It does not substitute for a second person who has actually shipped a real change in that code.