Single Points of Failure in Your Engineering Team

TL;DR: You'd never ship a production system with one database node and no failover. Most teams run exactly that architecture on their people: one deploy person, one billing expert, one reviewer per critical area. Research on 133 popular GitHub projects found 34% one departure away from a stalled codebase. People SPOFs are detectable from git history and fixable deliberately, or discoverable the hard way during someone's two weeks' notice.

Your infrastructure review would fail a system with a single point of failure. One load balancer? Add a second. One region? Multi-region. You spent real money on redundancy because the math is obvious: anything critical that exists once will eventually not exist at all, at the worst possible moment.

Then Monday standup happens, and the deploy waits for Sam because only Sam runs deploys. The billing bug waits for Priya because only Priya has ever been inside that integration. Every PR into the search service waits for one reviewer. The same rigor you apply to machines is nowhere in sight for the far scarcer resource. And unlike servers, people resign, burn out, take parental leave, and win better offers.

What is a single point of failure in an engineering team?

A single point of failure (SPOF) in a team is a person whose sudden absence stops a critical capability. Not "things get slower" - stops. Nobody else can run the migration, debug the payment flow, or safely change the code, so the work queues behind an empty chair.

This is bus factor viewed one person at a time: every area with a bus factor of 1 has a human SPOF at its center, and the org's real resilience is set by the worst critical area, not the average. The scale of the problem is measurable: Avelino et al. (2016) computed truck factors for 133 popular GitHub systems and found roughly 65% at a truck factor of 2 or less, with 34% at exactly 1. Those are successful open-source projects with public contributor pools. Your internal codebase has no volunteers waiting in the wings.

One important distinction before the hunt starts: an expert is not automatically a SPOF. Expertise is how hard things get built. A SPOF is expertise with no redundancy behind it, and the fix is to stop the expert being the only copy, never to flatten them.

Where do people SPOFs hide?

They cluster in predictable places, and almost never on the org chart:

• Deploy and release tooling. The scripts one person wrote in year two that everyone is afraid to touch. Ships fine daily; orphaned instantly.
• Money paths. Billing, payments, invoicing, tax: high-stakes, unglamorous, historically owned by whoever said yes first and never rotated out.
• The legacy service. Still in the critical path, no longer anyone's roadmap, one person's accumulated context standing between it and abandonment.
• The only reviewer. Authorship can look spread while every PR into an area is approved by the same person. One queue, one qualified judge, one face on both the bottleneck and the risk.
• Operational knowledge. The person who knows why: why that flag exists, why the retry is 7 seconds, why you must never run the backfill on Fridays. Nothing in the code says it.

Notice what these have in common: nobody planned them. Each one is an accumulation of locally reasonable decisions, like routing the work to whoever's fastest and letting the expert review their own domain. That's also why nobody is to blame, including the person at the center. They're usually the one who absorbed the work nobody else wanted. Roast the system that concentrated the risk; thank the human holding it up.

Detecting people SPOFs from git history

Skip the survey. The evidence has been accumulating in git the whole time. Three signals, cross-referenced:

1. Single-author areas. Over the last 6-12 months, which directories have one person landing nearly all meaningful changes? (The honest weighting method, authorship rather than raw commit counts, is covered in how to calculate bus factor.)
2. Single-reviewer areas. Which areas have every PR approved by the same one person, regardless of who authored?
3. Frozen contributor lists. Healthy areas rotate people through; a SPOF area's set of names is identical year over year, and short.

Areas flagged by more than one signal are your live SPOFs. The full detection playbook - including the silo patterns that precede a SPOF - is in knowledge silos in engineering teams, and the person-centric view of the same risk is key-person risk: same exposure, seen from the individual rather than the codebase.

The cost of a people SPOF

Nothing, then everything. That deferred payoff structure is exactly what makes it dangerous: while the person is present, the SPOF looks like efficiency - fast answers, quick closes in their domain - so every normal metric rewards it right up until the resignation letter.

The everyday tax is quieter but real. In the 2024 Stack Overflow Developer Survey, 45.2% of professional developers agreed that knowledge silos prevent them from getting ideas across the organization, and 61% reported spending more than 30 minutes a day searching for answers or solutions. That searching is largely people routing around knowledge that exists only in one head or in documentation nobody can find. The SPOF's queue, the estimates nobody else can give, the vacation the expert takes with a laptop - all of it is interest on a debt whose principal comes due at departure.

How do you remove a single point of failure?

The way you did it in infrastructure: add redundancy deliberately, where failure is expensive, and skip the rest without guilt.

1. Rank by blast radius. For each flagged area: how much of the product stalls if this goes dark tomorrow, and how actively is it changing? Hot, critical, single-owned areas top the list. A SPOF in code you're about to delete is trivia.
2. Rotate a second reviewer in. The cheapest transfer mechanism that exists: outsiders earn real context by reading the expert's diffs. This is also where your code ownership model either helps or hurts: strong ownership with no second set of eyes is a SPOF factory.
3. Swap author and reviewer. Route the next meaningful feature in the area to a non-expert, with the expert reviewing instead of writing. One slower feature buys structural redundancy forever.
4. Runbooks where the churn is. Short, close to the code, covering the "why" that git can't show. The broader discipline of moving context out of heads on purpose (pairing, rotation, docs) is the subject of knowledge transfer in engineering teams.

Then re-measure on a schedule, because SPOFs re-form the way they formed: silently, one reasonable routing decision at a time. A continuously computed ownership map - every area, who really owns it, which ones are one absence from orphaned - is exactly what Busfactor's knowledge view renders from the git history you already have. You gave your infrastructure failover. Your team is the more critical system, and the redundancy audit takes an afternoon.