New engineering managers often keep doing IC work because it’s familiar and it feels like “helping.” The cost is burned-out managers and underdeveloped reports. Delegation is how you scale your impact and grow your team. Here’s what to let go first and how to do it without dropping the ball.
Why Delegation Is Hard
- Faster to do it yourself (short term). Explaining and reviewing can take longer than doing. You have to invest now for payoff later.
- Quality anxiety. “What if they get it wrong?” So you check everything and become the bottleneck.
- Identity. If you’ve been the go-to technical person, letting go can feel like losing your value.
The shift is from “I do the hard stuff” to “I make sure the right stuff gets done well.” Delegation is the main lever for that.
What to Delegate First
1. Recurring, well-defined work.
Code reviews, routine ops, small features with clear specs. The outcome is clear; the main risk is consistency. Delegate these early and document standards so the bar is obvious.
2. Stretch tasks for growth.
Assign work that’s slightly above someone’s current comfort zone, with support. You’re not dumping—you’re giving them a chance to grow with a safety net.
3. Context and decisions you’ve already made.
When the “what” and “why” are clear, delegate the “how” and the execution. If you find yourself re-explaining the same context, write it down and delegate the next similar chunk.
4. Visible, meaningful ownership.
Give people ownership of a component, a flow, or a user-facing area. That builds accountability and motivation. Pair it with clear boundaries and check-ins.
What to Keep (For Now)
- Relationships and escalation. You own manager-to-manager or stakeholder conversations until you’ve delegated that relationship explicitly.
- Performance and compensation. Feedback, ratings, and comp stay with you unless you have leads who are accountable for that.
- Crisis and one-off big bets. When the stakes are high and the path is unclear, you may need to be in the loop or in the lead. Delegate more once the situation is stable.
You can move more of this over time as your reports grow; start with the obvious, repeatable work.
How to Delegate Without Micromanaging
Be clear on outcome and constraints.
“We need X by Friday; we can’t change the API contract.” Say what “done” looks like and what’s non-negotiable. Leave the rest to them.
Share context, not just the task.
Why does this matter? Who cares? What could go wrong? With context, they can make better decisions and you can step back.
Agree on check-ins.
“Let’s sync Tuesday and Friday so I can unblock you; otherwise you’re in the driver’s seat.” Frequency depends on risk and their experience. Reduce check-ins as trust builds.
Review outcomes, not steps.
Ask “what did you decide and why?” instead of “did you do it the way I would?” You care about results and reasoning, not that they mirror your process.
Accept different approaches.
If the result is good and the approach is reasonable, don’t override it because you’d have done it differently. Correct only when it’s wrong or when the approach creates real risk.
When to Step Back In
- They’re stuck and you can unblock quickly. Jump in to remove a blocker, then hand back.
- Risk is higher than you thought. You discover a critical dependency or a wrong assumption. Step in to correct course, explain why, and adjust how you delegate next time.
- They ask for help. “I’m not sure how to approach this” is a chance to coach or pair, not to take over. Help them think it through; leave ownership with them.
Delegation for engineering managers is about choosing what to let go first (recurring work, stretch assignments, execution), being clear on outcomes and check-ins, and stepping in only when necessary. When you delegate well, your team grows and you free yourself for the work only you can do.