The Bus Factor Audit: Find the Single-Person Territory in Your Codebase

Step 1: Map touch concentration (10 minutes)

List your five structural modules — the ones other modules import: authentication, the public API surface, deployment scripts, core domain logic, the data layer. For each, pull the authorship of every commit over the last six months and record one number: the share of that module's commits made by the top-1 author.

A five-person team, real numbers: auth at 78% (one author), sync pipeline at 34%, compliance export at 91%, billing webhooks at 62%, data layer at 38%. One glance and you know that a Priya-shaped holiday touches auth, a Tom-shaped resignation takes compliance knowledge to a competitor — and chip by chip, someone has been defaulting into a 62%-shaped shadow they never asked to own.

Step 2: Triangulate with review ownership (5 minutes)

Code lands through reviews, so a module is only safe when both its authorship and its review knowledge are distributed. For each hotspot, check who reviews its PRs:

• Author also owns every review — a single point of knowledge and of quality control on the same code. Act first.
• One stable reviewer per author — the "shadow couple": safe for holidays, not for departures.

The real exposure is the intersection structural × hotspot × single-author. Draw the grid: each red cell is a module at least one future vacation will expose.

Step 3 and 4: Cross the lists, then pick the lightest fix

The lightest mitigation usually beats the obvious big one — order again:

1. Pair one non-owner onto the next real change on the hotspot — an actual feature ticket, not a refactor. Cheapest knowledge transfer that exists, and reviews stay honest.
2. Rebalance the next two planned tasks so a second pair of hands arrives through incoming work, not through a handover meeting nobody retains.
3. Write one architecture note per hotspot while the owner is present — what it does, why it was built this way, where the bodies are buried.
4. Recheck in 30 days — the number matters quarterly; the trend is the only signal that tells you whether the pairing worked.

What not to do: documentation sprints that produce wiki pages nobody updates, and forced rotations across a whole team. Pairing on real change beats both — by a comfortable margin.

What it looks like after 60 days

In one worked team: auth went from 78% single-author to 54% in six weeks of two tickets plus pairing; compliance export from 91% to 71% with an intent document written before any migration work started; billing drifted from 62% to a balanced 47%. Nothing was rewritten — what moved was who is comfortable touching what, which is exactly what the next incident, holiday or resignation actually tests.

Doing this by hand is a photograph that is outdated the day after — and the number that matters is the trend. DevLyTicks tracks authorship concentration and review ownership per module automatically, on every sync. If you want the full 20-minute workbook, the Bus Factor Audit is free.

Conclusion

Your bus factor is not a number you choose — it is the number your commit history has been writing for months. Spend the 20 minutes to read it, triage the two or three cells that are genuinely red, and buy them down with pairing discipline rather than refactors. Your future speed is partly decided by who is allowed to go on holiday.