Your tech lead keeps every hard problem because it's faster. What's the cost, and what should they do?

A bus factor of one, a bottlenecked team and stalled growth (and attrition) for mid-level engineers. They should delegate outcomes with context at an agreed autonomy level, add checkpoints for risky work, and pair as navigator rather than taking it over.

What's the difference between delegating a task and delegating an outcome?

A task specifies the steps ('write these scripts'); an outcome specifies the result and constraints ('migrate the ledger with zero downtime and no reconciliation differences') and lets the person choose how.

How do you delegate high-risk work safely?

Choose a level like 'consult' or 'advise', agree checkpoints (design, first PR, rollout plan), pair on the riskiest part, and keep the person as owner rather than reclaiming the work.

Mentoring and Delegation — The Tech Lead Handbook

Scenario

Example team: the payments tech lead keeps every hard problem — reconciliation, the ledger migration, performance work — because "it's faster if I do it". Two mid-level engineers ask in 1:1s for bigger challenges. One leaves for a company where she'll "own something".

What you see on the team

The lead is the only one who understands critical systems (bus factor of one).
Mid-level engineers stuck on small tickets.
Delegated work handed back half done, or redone by the lead.
"Delegation" that means giving instructions step by step.

The common mistake

Delegating tasks instead of outcomes, at the wrong level of autonomy — either micromanaging or throwing people in without support.

Why it happens

Doing it yourself is faster this time. Delegation costs effort upfront: explaining context, reviewing, accepting a different approach. Leads also fear being blamed if delegated work fails. Delegation also isn't binary; Management 3.0's Delegation Poker describes seven levels, from "I tell" to "I delegate", which helps match autonomy to the person and the risk.

The playbook

Delegate outcomes, with context. "Ledger migration with zero downtime and no reconciliation differences" — not "write these five scripts".

Choose the level explicitly, based on experience and risk:

Level	Meaning	Use when
Tell	I decide and explain	Urgent, high risk, new person
Consult	You advise, I decide	High risk, growing expertise
Agree	We decide together	Shared ownership
Advise	You decide, I advise	Experienced, moderate risk
Delegate	You decide, I'm informed	Fully trusted area

Support without taking over: agree checkpoints (design review, first PR, rollout plan), be available for questions, pair on the hardest part as navigator.

Mentor deliberately: for each engineer, know one skill they're building this quarter and give them work that exercises it.

Accept different solutions that meet the outcome, even if you'd have done it differently.

What to say

Delegating the ledger migration:

"I'd like you to own the ledger migration end to end. The outcome: zero downtime, no reconciliation differences, done by end of quarter. You decide the approach; I'd like to review the design and the rollout plan, and I'm happy to pair on the dual-write part. What would you need from me to feel set up to succeed?"

Trade-offs

Delegation is slower at first and may produce a different approach; that's the cost of building capability.
High-risk work needs more checkpoints, not less delegation.
Over-delegation without context feels like abandonment; agree the level explicitly.

Signals it's working

More than one person understands each critical system.
Engineers present designs for work they own.
Delegated work rarely comes back to the lead half done.
People describe growth in specific skills in their 1:1s and reviews.

Key points

Delegate outcomes with context, not step-by-step tasks.
Choose the level of autonomy explicitly, from "tell" to "delegate", based on experience and risk.
Support with checkpoints and pairing, without taking the work back.
Know what skill each engineer is building and give them work that exercises it.