Bus Factor Review¶
Recurring review — instantiates Specialization Boundary and Reintegration Design
Finds every capability that rides on one irreplaceable person and turns each into a funded plan for redundancy before that person walks.
Specialization concentrates knowledge, and its sharpest failure is the single irreplaceable person: the one engineer who understands the reconciliation logic, the one analyst who can close the books. Bus Factor Review is the recurring review that hunts for exactly that — capabilities whose bus factor is one, meaning the work stalls the day that person is unavailable — and converts each into a deliberate redundancy buffer before the loss happens. Its defining move is that it targets people-and-knowledge single points specifically, and it doesn't stop at naming them: every hotspot leaves the review with a funded action, an owner, and a date, so the output is redundancy, not a worry list.
Example¶
A software team runs a payments service that quietly depends on one engineer — the only person who understands the reconciliation logic and the deploy runbook. Bus factor: one. The review lists the team's load-bearing capabilities, scores how many people can perform each unaided, and flags reconciliation as a bus-factor-1 item with a large blast radius. It doesn't merely note the risk; it assigns a fix — pair a second engineer on reconciliation for a quarter, get the runbook written and tested by someone else, add a backup to the on-call rotation — each with a named owner and a re-check date. A quarter later the review re-runs and confirms payments now clears bus factor two.
How it works¶
- Enumerate load-bearing capabilities — the actual know-how the system runs on, not the org chart.
- Score the bus factor of each — how many people could do it unaided today.
- Prioritise by blast radius — a bus-factor-1 on a critical path outranks one on a backwater.
- Assign a redundancy action and a re-check — documentation, pairing, cross-training, or a hire, each with an owner and a date.
What distinguishes it from a general dependency map is the narrow focus on human single points and the insistence on leaving with a specified buffer.
Tuning parameters¶
- Bus-factor threshold — treat only 1 as critical, or also 2. A higher bar buys resilience at real cost in redundant effort.
- Capability granularity — whole systems or specific tasks. Finer granularity finds hidden solo-knowledge but inflates the list.
- Redundancy mechanism — documentation, pairing, cross-training, or hiring. Each trades speed, cost, and depth of coverage differently.
- Review cadence — quarterly or annually; tie it to attrition and key-person risk.
- Scope of "critical" — revenue-critical only, or also the slow-bleed loss of institutional memory that has no incident but never comes back.
When it helps, and when it misleads¶
Its strength is that it names the single-person risk everyone senses but nobody schedules, and forces it into fundable actions with owners. Its failure modes are real: it counts heads, not depth — two people who each know a system shallowly can still fail together — and a review can decay into theatre, flagging risks it never funds to fix. The classic misuse is running it to rationalise a decision already made: to justify a hire, or worse, to pressure or push out the very expert it flagged. The discipline that keeps it honest is to require a funded action, an owner, and a date for each hotspot, and to verify redundancy by having the backup actually do the work — a "game day" where the expert stays home — rather than trusting the plan on paper. The underlying concept, the bus factor,[n1] is a count of resilience, and a count is only as good as the depth behind it.
How it implements the components¶
overlap_and_redundancy_buffer— the review's entire product is a deliberate redundancy buffer: the cross-coverage, documentation, and succession that keep a single person's absence from stopping the work.
It does not draw the full dependency topology (dependency_and_bottleneck_map) — that's Dependency Heatmap; it does not run the ongoing rotation that builds coverage on a calendar (tooling_and_practice_lane) — that's Rotation & Cross-Training Schedule; and it does not set the overall specialist-to-generalist balance (specialist_generalist_mix) — that's Specialist–Generalist Portfolio Review. This review diagnoses where redundancy is missing and specifies it.
Related¶
- Instantiates: Specialization Boundary and Reintegration Design — it supplies the redundancy buffer that keeps specialization from turning brittle.
- Consumes: Dependency Heatmap — its red single-source cells seed the list of key-person capabilities worth reviewing.
- Sibling mechanisms: Dependency Heatmap · Rotation & Cross-Training Schedule · Coordination Cost Accounting · Handoff Contract Template · Integrator Role Assignment · Over-Specialization Audit · Role/Niche Charter · Role Recomposition Trigger Review · Specialist–Generalist Portfolio Review · Specialization Boundary Workshop
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Finds every capability that rides on one irreplaceable person and turns each into a funded plan for redundancy before that person walks, making its operative form a bounded evaluation of existing evidence or work that produces a finding or disposition.
Independent corroboration: The frozen evidence defines Bus Factor Review as 'Finds every capability that rides on one irreplaceable person and turns each into a funded plan for redundancy before that person walks', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Software-engineering communities named the bus or truck factor to identify projects vulnerable to knowledge held by too few contributors.
Related originating lineages:
- Organizational & Management Science — Succession planning and knowledge management contribute funded redundancy, ownership, and review cadence.
Review resolution: Computer science is the agreed primary lineage because software communities named and operationalized the bus factor. Organizational knowledge management and succession planning materially contribute ownership, redundancy, and remediation practice, so that alternate is retained.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Bus Factor Review is the diagnosis and prioritisation of key-person risk; the ongoing build of coverage belongs to Rotation & Cross-Training Schedule. Keeping them separate lets the review stay a sharp, periodic scan while the schedule does the patient work — a review that tries to also run the cross-training tends to do neither well.
[n1] Bus factor (also truck factor) — the number of people who would have to be lost before a project stalls for want of knowledge held only by them; a bus factor of one marks a single point of human failure. Widely used in software engineering as shorthand for key-person risk. ↩