Delegation is the most powerful tool in your role as an Engineering Manager.
When done well, it creates a win-win scenario. It helps your team members grow while freeing you up to focus on higher-leverage work.
Yet most people are terrible at it. I certainly was. And if I’m being honest, I still catch myself making delegation mistakes from time to time.
Delegation sounds simple in theory. Just assign the work to someone else and watch it happen, right?
Not quite.
In reality, if you’re expecting an immediate return, delegation will always feel like the wrong choice. It is a long-term investment that actually feels inefficient in the short term.
I learned this the hard way
About four months into my first Engineering Manager role, I noticed a ticket about a vulnerability on a Linux machine owned by my team.
I saw that it was just a library upgrade. Easy peasy I thought. I’ll just do it myself. What could possibly go wrong?
I ran the upgrade commands. A few minutes later... BAM. Alerts started flooding our Slack channel: missing “no data” for server XYZ
As it turned out, the monitoring agent depended on this library to send data. I barely knew how it worked. Worse, I had another meeting starting in five minutes.
So instead of calmly assigning the work to the right person, I was frantically trying to find someone (literally anyone) who understood the system well enough to fix the mess I had just created.
Technically, I delegated the work. I just did it after creating the problem. That incident, along with several others during my first year as a manager, taught me three rules about delegation that I still follow today.
Rule #1: Don’t wait too long to delegate
Most new managers delegate only when they’re already overwhelmed. They keep tasks on their plate because it feels faster to do them themselves. Until one day they look up and realize they’re drowning in work.
I’ve seen this pattern with managers, tech leads, and senior engineers alike. One conversation with a lead engineer made this crystal clear:
Me: “Why are you working late?”
Them: “Because I had to finish this thing.”
Me: “Why didn’t you ask for help? Joe was available.”
Them: “Well, Joe doesn’t know how to do it. Do you really want me to delegate when the deadline is tomorrow?”
No. The time to delegate isn’t now. It was three weeks ago.
The best opportunities for delegation happen when nothing is on fire. When workloads are manageable, identify small, low-risk tasks and hand them over. Invest the time to teach someone. Let them make mistakes when the consequences are small.
Because when the critical project arrives, you’ll already have someone capable of helping.
Rule #2: Don’t delegate too early
After hearing Rule #1, many managers swing too far in the other direction. They forward every request the moment it lands in their inbox.
That’s a mistake I once made.
An infrastructure team reached out to me asking to onboard my team’s CUJs (Critical User Journeys) to a new portal. At first glance, it sounded straightforward. So I immediately assigned it to a senior engineer on the team.
Over the next few days, he kept mentioning blockers: “I’m stuck on this”, “I need inputs here”, etc. I nodded along and assumed he’d figure it out. Then one Friday afternoon, we sat down together for an hour to see what was going on.
I realized I barely understood the task myself. What looked like a simple migration involved a surprising number of technical decisions, ownership questions, and tradeoffs.
Since then, I’ve followed a simple principle: Never delegate confusion.
Many of the tasks that reach a manager are ambiguous. Before assigning, you need to know what you’re actually asking someone to do. Your job isn't necessarily to solve the problem, but you do need to bring some clarity.
- What problem is being solved?
- What are the constraints?
- What does success look like?
Without that understanding, it’s difficult to guide someone when they get stuck. You can do this distilling together with the person you’re planning to delegate to.
Rule #3: Don’t expect the work to go smoothly
This was probably the hardest lesson for me.
After spending weeks training someone on the release process and explaining the next task clearly, I subconsciously expected
a) it will get done without further questions or issues, and
b) the outcome will look exactly like it would have if I had done the work myself.
In my mind, the handoff was complete. I could move on to other things. But I learned that’s not how delegation works. When you delegate, you’re transferring ownership to another human being not creating a clone of yourself.
People will approach problems differently. They’ll make decisions you wouldn’t have made. They’ll ask questions you didn’t anticipate (and that’s a good thing because they might see things you missed). Sometimes they’ll make mistakes too.
But initially to me, any issue they faced felt like an extra thing I had to deal with, despite all the promise of delegation. Now I don’t see delegation as a silver bullet.
My job is to see a project through. I shouldn’t expect to disappear and leave someone unsupported. I should create guardrails, provide context, and stay available for coaching even after delegating it.
Final Thoughts
After a few months in management, you’ll see that there is no other choice but to delegate. Because the people around you are assigning more work than you can do alone.
So you must learn to delegate effectively to scale yourself. Find the sweet spot that works for you and your team. It often looks like this:
- you understand the problem well
- you hand over ownership before it becomes urgent
- you assign it to someone who is at least 80% ready
- you stay involved
That’s how you avoid taking down production monitoring five minutes before your next meeting.
Rule 1 is the one that stings. The version I have landed on is keeping a bench: people vetted and onboarded before there is work, paid only when work is assigned. It costs nothing to hold, and when something catches fire there is already someone who knows the system. Your library-upgrade story is the other half of it: the tasks you only think are easy are the most dangerous ones to keep.