Delegate Without Lowering the Bar
Updated: 5 days ago
Engineering Leadership · Part 2
Most people's mental model of delegation is "I do it, then you copy how I did it" — which isn't delegation, it's supervised typing, and it scales to exactly zero. Real delegation is handing someone the outcome and letting them own the path, which feels like a quality risk right up until you learn to do it well. This walks through delegating without lowering the bar: defining outcomes instead of steps, making the stakes clear, and — the hardest part — not snatching the work back the moment it wobbles.
Delegation isn't "I do it; you copy." It's "you own it; I support you." Mastery takes years.
Step 1: The Delegation Spectrum (10 min)
Five levels of delegation:
Do exactly this — you specified every detail
Investigate and recommend — they propose; you decide
Decide and inform — they decide; tell you
Own it — they decide; you trust
Mentor it — they own; you only check in
Match the level to:
The person's experience
Stakes of the work
Your tolerance for variance
Don't default to level 1 for everything. People grow when you delegate higher.
Step 2: Define Outcomes, Not Steps (15 min)
Bad:
"Build a search API. Use Elasticsearch. Index every minute.
Cache for 30 seconds. Return 50 results."
Better:
"Build a search API. Goals:
- Sub-500ms search responses
- 95%+ accuracy for typo'd queries
- Scales to 1M docs
You decide the implementation."
Outcomes give people room. Steps make them robots.
Step 3: Make Stakes Clear (5 min)
- "This is exploratory. Try things. Fail fast."
- "This goes to a customer next week. Be careful."
- "This is for the 10x scale plan. Build for that."
Different stakes; different rigor.
Without stakes context, people optimize for the wrong thing.
Step 4: Set Check-Ins, Not Standing Reviews (10 min)
"Quick async update by Friday. If you're blocked, ping me sooner."
Not:
"Daily standup. Weekly review. Sign-off at every milestone."
Light-touch check-ins for trusted engineers. Heavier for new / risky work.
Over-checking signals lack of trust. Under-checking misses problems.
If delegated work keeps falling short, the issue may be performance rather than delegation; see Handle Underperformance.
Step 5: Don't Take It Back (15 min)
Engineer hits a snag. They escalate to you.
Tempting: take it over.
Better: help them solve it.
"What have you tried? What's your guess? Try X for an hour; check
back if it doesn't work."
Taking work back undoes the delegation. They learn to escalate everything.
Exception: genuine emergency. Take it; debrief later about why escalation didn't catch it earlier.
Step 6: Inspect Work, Not People (10 min)
Review:
Design docs before they build
PRs (skim, comment on critical)
Final outcomes vs. goals
Don't:
Pair-program every line
Track time
Sit behind them
You're inspecting the work; not surveilling. Different.
Step 7: Disagree Without Overriding (15 min)
You delegated. You see them choose X. You'd choose Y.
Options:
Let them try X. Maybe X is right.
Share your concern, but defer.
Override and require Y.
Default to 1 or 2. Override (3) only when:
Stakes are very high
You have strong, specific evidence
You'll own the cost of being wrong
Overriding is the slow-acting poison of delegation.
Step 8: Praise the Work (5 min)
When delegated work ships:
Credit the owner publicly
Don't claim it yourself
Acknowledge the learning
People who deliver and get credit deliver more. People who deliver and see credit absorbed elsewhere stop trying.
Step 9: Adjust Over Time (10 min)
New hire? Level 1 / 2 delegation.
After 3 months: level 3.
After a year: level 4.
For specific senior people: level 5.
Re-evaluate quarterly. Don't keep someone at level 1 for years; they leave.
Step 10: Reflect on Your Own Patterns (5 min)
Notice:
Do you only delegate boring work?
Do you take back the hard stuff?
Do you delegate to the same person?
These patterns starve the team. Self-aware delegation is a long-term skill.
What You Just Did
Delegation: spectrum, outcomes vs. steps, stakes, check-ins, don't take back, inspect work, disagree without overriding, credit, adjust, reflect. The hardest tech lead skill.
Common Failure Modes
Step-by-step instructions. People become robots.
Take back at first sign of trouble. Trust erodes.
Override with the right answer. They stop bringing options.
Praise yourself; absorb credit. People stop trying.
Same level for everyone forever. Underutilized seniors leave.
Continue the Engineering Leadership path
Previous — Part 1: The Tech Lead Transition
For the reasoning behind this step-by-step guide, read Delegation That Actually Works: Teaching Your Team to Decide.
Part of the Engineering Leadership learning path.
