When reliability depends on one dependable person, you do not have a strong process. You have a polite emergency waiting to happen.

Every IT organization has one.

The person everyone calls when the documentation stops making sense, the monitoring produces a mystery, or a legacy system behaves like it has developed a personality.

They are experienced, dependable, and usually generous with their time.

They are also becoming the process.

Leaders often describe this person as indispensable. It sounds like praise. Operationally, it is a warning.

The IT delivery example: Server Operations

Imagine a Server Operations team supporting hundreds of Windows and Linux systems across multiple business services.

One senior engineer—let us call her Maya—knows the environment better than anyone. She understands which older applications cannot tolerate a standard restart, which clusters have unusual dependencies, and which recovery documents describe how the system was designed rather than how it actually behaves.

When an alert appears, the team messages Maya. When a change is complicated, Maya reviews it. When a problem crosses Server, Storage, Network, and Applications, Maya joins the bridge and translates.

The arrangement works beautifully—until Maya takes a long-awaited vacation.

During her absence, a certificate expires on a management component used by several application servers. Automated jobs fail, but the symptoms appear unrelated: delayed files, missed batch processing, and intermittent application errors.

The support team follows the runbook. The steps do not match the current configuration because Maya made an emergency adjustment months earlier and never found time to update the document.

Calls and messages begin reaching her personal phone.

She eventually joins from vacation, identifies the dependency, renews the certificate, and helps restore service.

The organization praises her commitment.

And once again, the system learns the wrong lesson: Maya saved us, so the model works.

It does not. Maya compensated for the model.

The consequences reach beyond one incident

For employees: the expert carries constant cognitive and emotional load. Time off becomes conditional. Focus work is interrupted. Meanwhile, colleagues receive fewer opportunities to build confidence because the difficult work keeps returning to the safest pair of hands.

For service delivery: queues form around one person, response times vary with their availability, and knowledge transfer is always postponed by today’s urgent demand. The team may appear fully staffed while functioning at the capacity of one key individual.

For customers: restoration takes longer when the expert is unavailable. Customers receive uncertain updates because others cannot confidently explain dependencies, risks, or recovery options.

For the organization: operational risk becomes concentrated in a person who can resign, become ill, change roles, or simply need an uninterrupted holiday. Retention pressure rises because replacing a job description will not replace years of undocumented context.

What human behaviour tells us

Teams naturally develop a form of shared memory: people learn not only information, but also who knows the information. This can be efficient. Nobody needs to memorize everything when expertise is distributed and accessible.

The risk appears when “Maya knows that” replaces documentation, cross-training, and shared practice. Each successful rescue reinforces the habit of routing difficult work back to the expert. The expert gains more experience while everyone else gains less.

This is not evidence that colleagues are lazy or that the expert is deliberately hoarding knowledge. People usually choose the fastest, safest path available—especially under pressure. Leaders must change the system so developing broader capability becomes easier than repeatedly borrowing one person’s brain.

Lessons for managers

  • Track dependency, not only performance. Ask which services, decisions, and recovery activities stop when one person is unavailable.
  • Create protected transfer time. Knowledge sharing will not happen if every available hour is consumed by operational work.
  • Pair people on difficult work. The expert should guide and observe while another capable employee performs the task.
  • Test absence deliberately. Run important procedures without the usual expert and treat every gap as a process defect.
  • Protect time off. Calling someone on vacation should trigger a review, not another celebration of dedication.

Lessons for organizations

  • Identify single-person dependencies as operational risks with owners and mitigation dates.
  • Include current documentation and demonstrated backup capability in readiness reviews.
  • Reward experts for multiplying capability, not merely absorbing more work.
  • Fund succession and cross-training before a resignation turns them into emergency projects.

Key takeaways

  • An indispensable employee can signal a fragile operating model.
  • Repeated expert rescues hide weaknesses in documentation and capability.
  • Knowledge transfer requires protected time and real practice.
  • Time off is not genuine when employees remain the emergency procedure.
  • The goal is not to make experts less valuable; it is to make their value scalable.

Discussion question: Which service in your organization becomes vulnerable when one particular person is unavailable?