Technical leadership should reduce dependency on technical heroes

Most technical teams know somebody who can fix almost anything.

They have been there for years.

They know which systems are fragile.

They remember why a strange configuration exists.

They know which supplier to call.

They know the undocumented command that fixes the problem.

When something breaks, people say:

Ask them. They know how it works.

That person is valuable.

The dependency is not.

Technical leadership should aim to make expertise easier to share rather than making the organisation dependent on technical heroes.

Expertise and dependency are different things

Deep expertise is good.

Experienced engineers often understand patterns that are difficult to capture completely in documentation.

They know what normal looks like.

They recognise failure modes quickly.

They understand the history behind design decisions.

The problem appears when essential operational knowledge exists only in one person’s head.

If that person is unavailable, the organisation suddenly discovers that what looked like expertise was also a single point of failure.

Technical systems should be resilient.

Technical knowledge should be treated the same way.

Documentation is part of engineering

Documentation sometimes gets treated as administration that happens after the “real” technical work.

That mindset is expensive.

If a system matters enough to design, deploy and maintain, it usually matters enough to document.

The documentation does not need to describe every possible detail.

It should answer the questions someone else is likely to need.

What is this service?

What does it depend on?

Who owns it?

Where is it managed?

How is it monitored?

How is administrative access obtained?

What would somebody check first if it failed?

Which suppliers or support agreements are involved?

What unusual decisions were made and why?

Useful documentation captures operational context, not just configuration.

Standards reduce memory

Standardisation is another way to reduce dependence on individuals.

If every switch is configured differently, every building has a different naming convention and every system has its own support process, engineers have to remember more.

If common patterns exist, the organisation can reason about unfamiliar systems more quickly.

Standard naming.

Standard configuration templates.

Standard monitoring.

Standard change processes.

Standard handover.

Standard documentation structures.

None of these removes the need for expertise.

They allow expertise to operate more efficiently.

An engineer can focus on what is genuinely unusual instead of rediscovering how every environment was assembled.

Cross-training matters before somebody leaves

Knowledge transfer often begins too late.

An employee resigns.

A handover document is requested.

Several years of operational knowledge are suddenly expected to fit into a few weeks.

That rarely works.

Cross-training should be part of normal operations.

Engineers should understand services outside their immediate specialism.

People should occasionally work through recovery procedures they did not write.

Projects should include handover while the project is happening.

Changes should create opportunities to explain the design.

The aim is not for everybody to know everything.

The aim is for the organisation to avoid situations where nobody else knows anything.

Leaders should ask different questions

Technical leaders also influence dependency through the questions they ask.

Instead of being satisfied that a problem was solved, ask:

Could another engineer have solved it?

Was anything learned that should be documented?

Did the incident reveal a monitoring gap?

Was the recovery process obvious?

Are we relying on knowledge that exists only with one person?

Should this configuration become a standard?

What would happen if the current owner were unavailable tomorrow?

Those questions move the conversation from immediate technical success to organisational resilience.

The hero pattern can hide weak systems

Technical heroes are often created by weak operating models.

Poor monitoring means somebody needs intuition.

Poor documentation means somebody needs memory.

Inconsistent systems mean somebody needs years of local knowledge.

Weak escalation means somebody needs personal supplier relationships.

Manual processes mean somebody has to remember when things happen.

The heroic engineer is frequently compensating for structural problems.

They deserve credit for doing so.

But leadership should still fix the structure.

Make experts more valuable, not less important

Reducing dependency does not reduce the value of experienced people.

It increases it.

An engineer who documents a complicated system, trains colleagues and creates a repeatable standard has multiplied their knowledge.

Their value is no longer limited to the incidents they personally attend.

Their expertise becomes part of the organisation.

That is one of the differences between technical ability and technical leadership.

A strong engineer can solve difficult problems.

A strong technical leader also makes the organisation less dependent on one person being available to solve them.

The goal should never be to eliminate expertise.

It should be to ensure expertise strengthens the system rather than becoming another single point of failure.