Your bus factor is not theoretical. It is a business continuity metric, and unlike most culture-y engineering concepts, it's one you can actually pin down with a bit of investigation.
Bus factor = the number of people who, if they disappeared tomorrow (vacation, illness, quitting, not literally a bus), would put your project in serious trouble. A bus factor of 1 means one engineer is a single point of failure. Higher is safer.
Step 1: Find it
You don't need tooling to start finding bus-factor-1 risk. You need the right questions, asked consistently:
- For each critical service or system, ask: "If this person took a month off starting tomorrow, who else could operate it?" If the honest answer is "no one," you've found a risk.
- Look at your on-call escalation path. If the same one or two names show up as the de facto expert for every incident in a given area, that's a signal.
- Check PR review assignments over the last quarter. If one person is consistently the sole reviewer (or sole author with no reviewer who really understood the change) on a critical path, that's concentration.
- Ask new hires and junior engineers directly: "What's the part of the system you'd be most nervous to touch, and why?" Their answers usually point straight at the single points of failure, because they've already bumped into them.
None of this requires new tooling. It requires making the exercise a habit instead of something you only discover after someone's already gone.
Step 2: Fix it with this checklist
Once you know where the risk is concentrated, here's a practical checklist to raise bus factor without slowing the team down:
- Reassign low-urgency bugs deliberately. When triaging, ask "who does not know this part of the system?" as often as "who knows it best?"
- Require a design doc or PR description for non-trivial changes. Even a few paragraphs of "why" saves hours later.
- Rotate on-call and deploy duties, not just the pager — the pipeline, the runbooks, the "how do I roll this back" knowledge.
- Make PR review mandatory for everyone, including seniors reviewing juniors' code and vice versa.
- Pair on the scary stuff. Not everything — but the systems with the highest concentration of risk are exactly where 30 minutes of pairing pays off.
- Run a "keys to the kingdom" audit quarterly. Who's the only person with access to that AWS account, that admin panel, that legacy cron job? 7.** Track it over time.** A single check tells you where you are. Repeated checks tell you if you're improving.
The bigger point
Bus factor is one of the few culture/process problems you can actually pin down instead of just sensing. You don't have to guess who your single points of failure are because these patterns, data, and a few honest conversations will tell you. Treat it like a metric, not a vibe: check it, put a number on it, and revisit it every quarter the way you'd revisit test coverage or deploy frequency.
Your bus factor is not theoretical. It is a business continuity metric.
Top comments (0)