The Technical Leader's Leverage

A technically strong leader can keep solving problems long after solving them personally has become the wrong default. The incidents get closed, the difficult design questions get answered, and the person answering them is visibly indispensable. It looks like commitment because it is commitment. It can also prevent the organisation from developing the capability it needs.

The chief engineer's operating model is a question about structure. This is a question about behaviour: when to intervene, what to hand over, and how to remain accountable without becoming the route through which everything must pass.

The cost of repeated rescue

A rescue can be necessary. If a service is failing and you are the person best placed to restore it, help restore it. The problem begins when the same class of incident keeps returning and the only reliable response is still your availability.

Each intervention has an immediate benefit. The deferred cost is harder to see: other people get less practice, the missing documentation remains missing, and the underlying design weakness competes poorly against tomorrow's urgent work. A successful rescue can conceal that cost precisely because it ends the visible problem.

Repetition is a reason to investigate. It does not automatically prove a failure of delegation. A team may be understaffed, the system may be unusually specialised, or the proposed handover may be larger than the available capacity. Establish which constraint you are addressing before telling people to take more ownership.

Give away decisions with enough context

Delegation needs an outcome, a scope of authority and a way to recognise when help is required. “You own this now” is incomplete if the person cannot change the design, obtain the necessary access, or negotiate the time to do the work.

Before handing over a responsibility, agree what success looks like and what must remain true. Name the decisions the owner can make, the people affected, the limits on cost or disruption, and the events that require escalation. Set a review point. Then allow the owner to choose an approach within those bounds.

NetWatch's documentation shows how much context a technical handover can carry. Its September design bundle linked the observed UI problems to mockups, a diagnosis specification and a suggested implementation sequence. It also labelled the mockup scenario as synthetic and the proposed sandbox explanation for missing process attribution as a hypothesis to test.^[1]

That distinction matters. A handover that separates observation, explanation and acceptance criteria gives the next person room to investigate. A handover that presents every suspicion as an established fact asks them to reproduce your assumptions.

This is a documented project artefact, not evidence that a particular person completed a successful delegation. The useful lesson is in what the handover makes inspectable.

Learning does not require avoidable damage

You do not need to accept a worse production outcome to develop someone else's judgment. Begin with work whose consequences are bounded: a reversible change, a staging exercise, a low-risk release, or a decision that can be reviewed before it affects users.

An experienced colleague may make a better decision immediately. A less experienced colleague may need pairing, access to an expert, or a smaller first responsibility. Both are compatible with real ownership. The leader's job is to provide enough support for the task, then reduce it as competence becomes observable.

Google's incident-response guidance explicitly recommends drills and practice in less critical situations, including controlled emergencies that do not affect customers. It also separates incident coordination from operational response.^[2] Those are useful ways to develop capability while keeping responsibility clear.

Consider an illustrative release handover. An engineer owns a change to a diagnostic report. The agreed constraints are that its figures come from the recorded evidence, it preserves the export format, and it makes no system changes. A reviewer checks the output against a fixture before release. The engineer can choose the implementation; a schema change or an unexpected write crosses the agreed boundary and triggers a discussion.

For a live incident, the arrangement would be different. The person with the relevant expertise may need to act immediately, under a named incident lead. The learning can happen through shared diagnosis and a later exercise. The middle of an uncontrolled outage is a poor place to improvise a lesson about autonomy.

FIGURE 5.1From incident response to wider responsibility

Scroll diagram horizontally →

Discomfort is information

Being needed provides a quick signal of value. Developing another person's judgment provides a slower one. It can feel like a loss of status to stop being the person who fixes the difficult case, especially when that ability earned your technical reputation.

But discomfort is not evidence that you are doing leadership correctly. It might reflect a healthy change in role. It might also reflect unclear expectations, insufficient support, or a risk you have not resolved. Ask which it is.

Research on software teams offers a more useful emphasis than celebrating discomfort. A survey of 217 practitioners across 38 teams found associations between psychological safety, clarity of team norms, and self-assessed performance and satisfaction. The study supports attention to those conditions; it does not establish that a particular delegation method causes better results.^[3]

Make it easy to say “I do not understand the constraint” or “I need help before this goes further.” If asking for help is treated as failure, people may conceal uncertainty until the cost of intervention is much higher.

Inspect the dependency on you

A calendar can reveal a pattern, but there is no universally correct allocation of time. A week dominated by tactical work may be appropriate during a migration or a serious incident. The question is whether that pattern persists and whether anything is reducing the dependency.

Look back over a month. Which decisions waited for you? Which problems returned after you fixed them? Which tasks did you take back before the owner had a chance to finish? Where did you intervene because a constraint was breached, and where did you simply prefer another implementation?

Choose one recurring dependency and work on it deliberately. That might mean pairing through a diagnosis, writing a decision record, improving a tool, changing an interface or securing more capacity. Agree how you will know the intervention helped: another person can perform the task, a decision no longer waits, or the same fault can be handled without an emergency call.

Measure the quality of that independence as well as its frequency. A lower escalation count alongside more rework is not an improvement.

Technical depth still matters

Delegation does not require abandoning difficult technical work. A leader still needs enough contact with the software to assess proposals, recognise a hidden dependency and challenge a reassuring explanation. Reviewing a consequential design, tracing an unfamiliar failure or building a small prototype can all serve that purpose.

The distinction is why you are doing the work and what it leaves behind. If an investigation ends with a fix that only you understand, the immediate result may be good but the dependency remains. If it also produces a test, a better interface or another engineer who can explain the failure, the same effort improves the next response.

Some of this work looks unremarkable: removing a duplicated system, making a development environment reliable, clarifying ownership, or improving a release procedure. Its value depends on the recurring friction it removes. It does not need to outperform every visible launch to be worth doing.

A broader measure of contribution

Technical contribution can operate at several levels: what you produce, what the team produces with your help, what the organisation can do independently, and which problems it chooses to address. These are overlapping forms of impact, not a mandatory ladder away from hands-on engineering.

The change for a leader is to take responsibility for the whole result. Sometimes that requires your direct expertise. Often it requires preparing someone else to act, providing the authority to do so, and resisting the urge to reclaim a decision merely because you would have made it differently.

The strongest evidence of progress is a difficult situation handled well by someone who once needed you to handle it. You can still help. You are no longer the only way through.

Sources

1. NetWatch, netwatch-next/HANDOVER.md and review/REVIEW.md, 3 September 2026, supplied local design bundle. See NetWatch evidence: design handover. Describes the artefacts, not a measured delegation outcome. ↩︎

2. Jennifer Mace, Jelena Oertel, Stephen Thorne and Arup Chakrabarti, with Jian Ma and Jessie Yang, “Incident Response”, The Site Reliability Workbook, 2018, especially “Main Roles in Incident Response” and “Drills.” ↩︎

3. Per Lenberg and Robert Feldt, “Psychological Safety and Norm Clarity in Software Engineering Teams”, 2018. Survey evidence with self-assessed outcomes; association does not establish causation. ↩︎