ON THIS PAGE
Every company has a person whose name appears during difficult incidents. They know why the billing job pauses on Tuesdays, which database must be restarted first, and why a configuration value that looks unused cannot be removed.
Their expertise is valuable. Their exclusivity is dangerous.
The bus factor is not a headcount
Two people editing the same repository does not mean two people can recover its production service. Real redundancy asks whether another engineer can diagnose failure, deploy a fix, restore data, and explain the consequences without waiting for the expert.
Knowledge concentrates gradually. The fastest person receives every urgent task. Because they can solve it quickly, nobody else gets the slow learning opportunity. Efficiency today compounds fragility tomorrow.
Documentation alone is not transfer
A large wiki can describe normal operation while missing the judgment required during abnormal operation. Tacit knowledge becomes visible through shared work:
- rotate incident leadership;
- pair on risky deployments;
- ask a second engineer to perform recovery from the runbook;
- record decisions and rejected alternatives;
- run game days where the expert may observe but not intervene.
If the backup engineer cannot complete the task, the exercise found a system defect, not a personal failure.
Design knowledge into the system
Reduce the amount anyone must remember. Encode invariants as tests, operational steps as automation, ownership in a service catalog, and failure context in dashboards. Prefer boring interfaces that expose state over clever machinery that requires interpretation.
The expert should become a teacher and designer of safe boundaries, not a permanent human API.
The most dangerous dependency may be a human, but the solution is not to make people interchangeable. It is to make critical understanding shareable. A resilient organization preserves expertise while removing the requirement that one particular person must always be available.