When one expert carries the knowledge, authority, and recovery steps for a critical service, the organization does not have a star performer. It has an undocumented dependency.

Every operation has one.

The person everybody calls when the normal process stops working. They know which database job occasionally hangs, which application owner must be warned before a restart, which script is safe, and which “documented procedure” has not worked since 2023.

Leaders often describe that person as indispensable.

I hear something slightly different: operational risk.

An indispensable employee is often evidence that the management system is incomplete.

The database expert who could not be reached

Imagine a Database Operations team supporting a revenue-critical customer platform.

One senior DBA has looked after the environment for years. She knows the replication quirks, the storage dependencies, the maintenance sequence, and the undocumented workaround needed when failover stalls. Everyone trusts her because she has rescued the service more times than anyone can remember.

Then, during a holiday weekend, the primary database begins failing. The secondary is healthy, but the automatic failover does not complete.

The on-call engineer opens the runbook. It describes the standard procedure, not the exception this environment has developed. The application team wants an immediate decision. The incident manager asks who is authorized to force the failover. Nobody is certain.

They call the senior DBA.

No answer.

Now a technical incident becomes a management failure. Recovery slows. The Service Desk faces growing demand. Customer transactions fail. Executives join the bridge. Meanwhile, capable employees hesitate because the roles, decision rights, knowledge, and backup coverage were never made explicit.

The organization had resilience on paper. In practice, it had one mobile number.

If your continuity plan depends on one person answering the phone, it is not a continuity plan.

This is not the expert’s fault

Organizations sometimes respond by blaming the expert for “hoarding knowledge.” Occasionally that happens. More often, the system rewards exactly this outcome.

The expert is repeatedly pulled into urgent work. Documentation is postponed because delivery comes first. Managers assign backups, but never protect time for shadowing or supervised practice. Access remains restricted. Decision authority stays vague. Everyone celebrates the rescue, so the hero model quietly becomes the operating model.

The damage grows slowly. Other team members stop building confidence. Routine work waits for one person. The expert cannot disconnect without anxiety. Managers mistake dependency for loyalty, and customers inherit a risk they cannot see.

FLM1 — Roles & Responsibilities is not just about job descriptions or a RACI chart stored in SharePoint. It is about designing clear ownership, decision rights, backup roles, skill coverage, and escalation paths around the outcome.

Name a primary owner and a capable alternate. Define what each role may decide without permission. Turn recovery knowledge into tested procedures. Rotate operational responsibilities. Run simulations while the expert is present, not for the first time while they are unavailable.

The goal is not to make good people less valuable. It is to make the service less vulnerable.

Key Takeaways

  • Single-person dependency is a management-system risk, not a badge of honour.
  • Backup names mean little without access, authority, practice, and current knowledge.
  • Protect time for documentation, shadowing, rotation, and recovery testing.
  • Reward experts for building capability around them, not only for performing rescues.

Discussion question: Which critical service in your organization still depends on one person answering the phone?