Bus-factor / key-person concentration
Appendix B
•
Appendix
•
4
min read
Bus-factor / key-person concentration
| What it is | How much of your delivery depends on a single person. A bus factor of one means one resignation, or one bad week, stops the work. |
| How to measure | For each critical area, count how many people can ship a change there unaided. Map ownership across the codebase and flag anything with exactly one name on it. |
| What good looks like | No single owner for anything that matters. At least two people who can keep each critical path moving. |
| Serves | Team performance. |
Change-failure rate
| What it is | The share of changes that cause a failure in production — a rollback, a hotfix, a degraded service. A DORA key metric (DORA, 2024). |
| How to measure | Over a window, divide the number of changes that caused a failure by the total number of changes deployed. Define "failure" once, in writing, and apply it the same way every time. |
| What good looks like | Low and falling. Some failure is normal; a rate that climbs is a quality signal, not bad luck. |
| Serves | Operational reliability. |
Time to restore (MTTR)
| What it is | When something breaks, how long until service is back. A DORA key metric (DORA, 2024). |
| How to measure | Timestamp the start of each incident and the moment service is restored. Report the median time to restore across incidents. |
| What good looks like | Fast and predictable. Founders fixate on never failing; the reliable measure is how quickly you recover when you do. |
| Serves | Operational reliability. |
Defect escape rate
| What it is | The share of defects that reach customers instead of being caught before release. A bug found in review is cheap. A bug found by a user is not. |
| How to measure | Over a window, divide defects reported by users by total defects found (users plus those caught internally before release). Track the trend. |
| What good looks like | Most defects caught before they ship, and the escape rate trending down. A rising number means your safety net has holes. |
| Serves | Technical quality. |
Rework ratio
| What it is | How much effort goes into redoing or repairing work already "finished," versus building something new. The tax the spec graveyard and accumulated debt charge you. |
| How to measure | Tag each task as new work or rework (fixing, reworking, or paying down debt on prior work). Track rework as a share of total effort over time. |
| What good looks like | A modest, stable share. Climbing rework is the codebase telling you it's rotting before anyone says the word "debt." |
| Serves | Technical quality. |
% of work tied to a business outcome
| What it is | The share of delivered work that traces to a named business goal — revenue, retention, a cost saved, a risk closed. The antidote to building features nobody asked for. Pendo found 80% of features are rarely or never used (Pendo, 2019); this is how you stay out of that 80%. |
| How to measure | Require every task to name the outcome it serves. At the end of a window, divide work tied to a stated outcome by all work shipped. |
| What good looks like | High, with each linked outcome real rather than a label bolted on after the fact. Work that traces to nothing is the first thing to question. |
| Serves | Roadmap & business alignment. |
Roadmap commitment accuracy
| What it is | When you commit a roadmap item to the business, how often it lands roughly when you said. Predictability (KPI 2) measures the cadence; this measures the promises you make outside engineering. |
| How to measure | Record each roadmap commitment with its target window. When it lands, mark hit or missed against that window. Accuracy = hits ÷ commitments, over time. |
| What good looks like | High enough that the business can plan around your word. A roadmap nobody trusts is just a wish list with dates. |
| Serves | Roadmap & business alignment. |
A last word on using these. Measure a handful well rather than all ten badly, and define each one in writing before you track it, so the number means the same thing next quarter as it does today. Ten numbers on a page are easy to admire. The harder question, the one Chapter 12 leaves you with, is who owns moving them.
the-title-trap
what-a-cto-is-actually-accountable-for
software-delivery
team-performance
operational-reliability
technical-quality
roadmap-business-alignment
the-spec-graveyard
task-shaped-work
running-the-cadence
visibility-accountability
the-scorecard-the-top-10-kpis
technical-quality-is-the-codebase-getting-cheaper-or-more-expensive-to-change
build-hire-or-subscribe
conclusion-reliable-execution-delivered
the-artifact-pack
the-top-10-kpis-definitions-how-to-measure
bus-factor-key-person-concentration
fractional-cto-sources-further-reading
the-cost-maths-chapter-13
Download the full PDF for free?
Oops! Something went wrong while submitting the form.