The problem: key person dependency
Key person dependency hits when Ali is the only one who deploys to production and their vacation week slips release—bus factor equals one. Managers know “Ali is critical” but never budget cross-training—until Ali burns out or leaves.
Key person dependency shows on heatmaps: one name owns an entire column. No wiki runbook—“ask Ali.”
Reducing bus factor means pairing, documenting, and distributing WIP—not just hiring a backup.
Leaders who only see key person dependency in crisis meetings pay reactive costs—weekly leading metrics beat monthly firefighting. Tools alone do not fix it; policy plus cadence plus owner are required.
Symptoms and cost of key person dependency
Key person dependency:
| Symptom | Cost |
|---|---|
| One-person deploy | Release freeze on PTO |
| Single senior review bottleneck | Aging up |
| 'Ask X' culture | No docs |
| Heatmap one hot name | Hidden overload |
| Cross-train 'later' | Risk accumulates |
Key person dependency is technical and HR risk—track both.
Bus Factor Reduction Framework (7 steps)
1. Heatmap audit. workload_heatmap—single-owner clusters. Execute this week—named owner on a task. One-line success criterion in wiki.
2. Top-5 bus factor list. Tasks/domains with one expert. Execute this week—named owner on a task. One-line success criterion in wiki.
3. Pair sprint. Shadow on critical path. Execute this week—named owner on a task. One-line success criterion in wiki.
4. Runbook wiki. Deploy, on-call—test with non-owner. Execute this week—named owner on a task. One-line success criterion in wiki.
5. Rotate review. Spread approval load. Execute this week—named owner on a task. One-line success criterion in wiki.
6. WIP cap per person. Overload = stop pull. Execute this week—named owner on a task. One-line success criterion in wiki.
7. Quarterly bus factor retro. Score improving? Execute this week—named owner on a task. One-line success criterion in wiki.
Leading vs lagging for key person dependency
| Leading | Lagging |
|---|---|
| Table symptom—weekly trend | Stakeholder surprise |
| Experiment with owner | Blame and firefighting |
| Metric from system | “Which number?” debates |
| Updated wiki policy | Repeat mistake next project |
Anti-patterns
- Hero worship
- 'No time to pair'
- Outdated runbooks
- Hire without distributing
- Ignore heatmap
How WKFGo helps with key person dependency
MCP workload_heatmap—overload visual.
Wiki runbooks—task-linked.
MCP search_people—skill map.
Approvals—rotate reviewers.
Sample key person dependency workflow
Monday: MCP brief before sync—same metric as the symptom table. Wednesday: aging or heatmap check if flow-related. Friday: if the experiment changed, one-line wiki update. key person dependency with steady cadence beats monthly workshops.
Scenarios
Ops: One-person on-call. Legacy: COBOL expert. Security: Sole reviewer.
Key person dependency can shrink in two sprints with pair + wiki.
Reduce key person dependency
This sprint: Ali pairs with a second dev on deploy. Heatmap after—did Ali's name spread? Non-owner executes wiki runbook. Planned PTO = bus factor test.
Key person dependency hides in “just 30 minutes of help”—heatmaps show real WIP.
Summary on key person dependency
Heatmap, top-5 bus factor, pair this sprint.
For product managers
Budget cross-train time in sprint plans. Check the metric in the next review.
For engineering
Non-owner deploy dry-run before Ali's PTO. Check the metric in the next review.
For PMO
Cross-project portfolio heatmap—shared key people. Check the metric in the next review.
Teams that treat key person dependency seriously for two sprints have evidence before scaling to a second squad. Leadership must accept trade-offs—add without drop or local fixes repeats the same failure mode. Fifteen-minute weekly reviews on the same metric beat monthly workshops. Wiki the playbook that worked. New tools without policy repeat key person dependency with another dashboard. Revisit the symptom table each quarter—markets and teams change. Start small; evidence before mandates.
FAQ — key person dependency
Bus factor formula? People who won't block domain—target ≥2. For key person dependency, without weekly cadence this question repeats every month.
Pair cost? Less than release slip. For key person dependency, without weekly cadence this question repeats every month.
Remote? Wiki plus recorded walkthrough. For key person dependency, without weekly cadence this question repeats every month.
MCP? workload_heatmap, wiki. For key person dependency, without weekly cadence this question repeats every month.
key person dependency — start now
This week: (1) Validate the top table symptom with real data—not anecdotes. (2) Complete one step of the Bus Factor Reduction Framework (7 steps) with an owner on a task. (3) Fifteen-minute Friday review—same metric. Build a two-sprint baseline; then brief leadership on the trend. key person dependency without weekly cadence returns to heroics. Pilot in one squad before PMO mandate—put the playbook in the wiki.
Review heatmap this week
Top-5 bus factor.
Practical reminder — key person dependency
The most durable teams manage key person dependency with named owners, steady metrics, and fifteen-minute weekly reviews—not monthly workshops. When symptoms return, check policy and definitions first—not individuals. Pilot in one squad before PMO mandates. Wiki playbooks scale. MCP briefs before steering remove number debates. Leadership accepts one explicit trade-off each quarter—add without drop repeats the same cycle. Quarterly retro: did leading metrics improve? If not, change the experiment—not the tool. Starting small today beats big planning tomorrow.