Single-person Dependency

1. The latent failure: everything looks healthy while the key person is present

Single-person dependency exists when a critical workflow can be completed only while one person is available: deployment, rollback, migration, credential operation, incident escalation, or final approval. The service can look perfectly healthy until absence, overload, or departure removes that person. The useful test is therefore not a normal-day dashboard; it is a bounded exercise in which the primary is unavailable and the workflow must complete, safely escalate, or fail visibly.

2. Subject-matter ownership is not automatically a single point of failure

A primary expert can be healthy. The failure appears when knowledge, authority, credentials, documentation, or execution experience are concentrated so tightly that recovery stops without that person. Ask not merely how many names are listed as owners, but how many authorized people can independently execute or correctly escalate the critical workflow using current evidence.

3. Define the critical workflow before counting people

Do not measure dependency against vague labels such as “backend” or “production.” Use operational units: deploy service A, rotate the rollback credential, recover a failed migration, or approve a critical module change. A team may have strong deployment coverage while a rare data-repair branch remains single-person. The record keeps that boundary explicit.

4. A named backup is not the same as a qualified backup

For this lesson, a backup is qualified only when required knowledge, independent authorization, current access, usable procedure, and rehearsal evidence align. A teammate who knows the procedure but lacks production access is not qualified. A teammate who has access but has never performed the rollback and has no rehearsal or safe-escalation evidence is still OPEN. A rota or CODEOWNERS entry is routing evidence, not operational-capability proof.

5. Independent access is separate from knowledge

Keep knowledge and access in different evidence fields. Someone can understand the migration playbook but lack the role, MFA device, break-glass path, or credential authority required to act. Another person can have permission without operational knowledge. The record separates knowledge, independent access, and authority boundary so the repair targets the actual gap.

6. A runbook must be current and executable

The existence of a document is insufficient. The procedure must match the current system, expose dependencies and safety checks, and provide an escalation path. The lesson counterexample uses a runbook that still references a retired deployment step: the backup has access, but the rehearsal fails safely. That failure is stronger evidence than a green documentation checklist.

7. CODEOWNERS and rotas are only part of the evidence

GitHub supports multiple code owners for a path, and when code-owner review is required, one listed owner can satisfy that requirement. This is useful routing and reviewer-redundancy evidence, but it does not show that every owner has production access, incident knowledge, or credential custody. Record it as configuration or authority evidence, not as closure proof.

8. Rotation, shadowing, and backup escalation transfer capability

Google SRE on-call guidance describes rotation, documentation, shadow shifts, and backup escalation as practices used to transfer operational responsibility. The useful pattern is staged independence: a backup first shadows experienced staff, then becomes primary while escalation remains available. This is a practice example, not a universal staffing ratio. Bind shadow/rotation evidence to a specific workflow and rehearsal date.

9. The rehearsal must make the primary unavailable

If the primary sits beside the backup and narrates every step, knowledge transfer may be happening, but independence is not proven. A closure rehearsal removes the primary from the execution path. The authorized backup must use independent access and auditable documentation to complete the workflow or correctly escalate it. If escalation simply returns to the same primary, dependency remains.

10. Safe escalation can be a valid recovery outcome

Not every backup must perform the deepest repair alone. For some workflows, a valid outcome is to diagnose the incident, bound the blast radius, and escalate to an independent authorized team. The escalation path must not create a new single-person dependency, and the resulting recovery time must fit the workflow requirement. Keep this distinction explicit in the record.

11. Containment is not closure

Adding a backup name, granting temporary access, or writing a runbook can reduce exposure, but these are containment steps. Closure requires independent evidence that the critical workflow can proceed without the primary. If the rehearsal has not happened, classification stays OPEN or at most REDUCED. A green mitigation rerun does not prove causality or erase residual risk.

12. Key-person Dependency Resilience & Handoff Record v1

The record captures critical workflow, primary owner, qualified backup count, independent access, credential/authority boundary, runbook currency, shadow/rotation evidence, last rehearsal, primary-absent result, escalation path, recovery time, knowledge transfer, role coverage, residual gap, and closure status. Every decisive claim traces to observation or authority evidence; unsupported dimensions remain UNKNOWN.

13. Classification: OPEN, REDUCED, or CLOSED

OPEN means the workflow still stops on the primary or decisive evidence is missing. REDUCED means some controls are in place but a branch, access boundary, or rehearsal gap remains. CLOSED means that for the bounded workflow at least one authorized backup, using current procedure and independent access, has completed a primary-absent rehearsal or reached a valid independent escalation path. The classification is scoped; it is not a global statement about the team.

14. Lab: eight fixtures and 64 assertions

The lab contains eight cases: primary-only, named backup without access, access without knowledge, stale runbook with failed rehearsal, independent safe escalation, independent successful rehearsal, two qualified backups, and a transfer case where everyone has access and current runbooks but only the primary has rare data-repair experience. Eight deterministic outputs are checked per case: qualified backup count, access independence, runbook readiness, rehearsal result, workflow state, dependency classification, closure status, and decision. That yields 64 assertions.

15. Exit checklist and transfer

Before exit, name the bounded workflow; record primary and backups from evidence; separate knowledge from access; verify runbook currency and last rehearsal; capture the primary-absent result and escalation path; do not label containment as closure; preserve the residual gap. Then rebuild the transfer fixture from blank evidence: all three engineers have access and current runbooks, but only the primary has performed the rare data-repair escalation. Decide CLOSED, REDUCED, or OPEN for that branch and state what evidence would change the decision.