Delegation: Just Let Go, You Control Freak
Giving your team autonomy without secretly undoing their work at midnight
You know what’s fun about being an engineering manager? Watching someone on your team struggle with a problem you could solve in twenty minutes, and having to just sit there and let them figure it out themselves.
You know what’s even more fun? Doing exactly that, going home feeling like a good manager who trusts their team, and then logging back in at 11pm to “just check on things” and maybe make a few tiny improvements that won’t hurt anyone’s feelings.
Welcome to delegation, the management skill that everyone says is important and almost nobody actually does well.
If you want the practical version of this, with fewer rants and more “what to actually do on Tuesday”, checkout the playbook: Delegating Work Without Micromanaging.
The Problem With Being Competent
Here’s the thing about engineers who get promoted to management: you were probably pretty good at your job.
You got promoted because you shipped things. You solved hard problems. You were the person everyone came to when shit was broken and nobody else could figure it out.
And now you’re supposed to stop being that person.
You’re supposed to let other people solve the problems, even when you can see exactly what they’re doing wrong. You’re supposed to give them space to figure it out, even when you could just tell them the answer. You’re supposed to trust that they’ll get there eventually, even when “eventually” means the project is going to be late.
This feels completely unnatural. Your entire career has been built on the idea that your value comes from your ability to solve problems. And now your job is to watch other people solve problems while you sit in meetings and pretend to understand what “driving alignment” means.
So you delegate. Sort of. You tell your team to handle something, and then you hover. You check in constantly. You offer “suggestions” that are really just instructions in disguise. You review every pull request like you’re grading a final exam.
And when they do something differently than you would have done it, even if it works fine, you can’t let it go. You have to say something. You have to make it better. Because better is better, right?
Wrong. Better is the enemy of done. And your need to make everything perfect is the enemy of your team’s growth.
The Midnight Code Review
Let’s talk about the thing you don’t want to admit you do.
You delegate a task. Your engineer picks it up, does the work, opens a PR. You review it and it’s fine. Not perfect, but fine. It works. It’s tested. It’s not going to break production.
But you can see ways to improve it. The variable names could be clearer. The function could be split up differently. There’s a clever optimization they missed.
So you leave comments. Lots of comments. And your engineer dutifully makes the changes, because you’re their manager and they want to make you happy.
Or worse, you approve the PR and then later, after it’s merged, you go in and “refactor” it. Just a little cleanup. Just making it better. No big deal.
Except it is a big deal. Because what you’ve just told your team is that their work is never good enough. That even when they think they’re done, you’re going to come behind them and fix it.
And now they’re going to start second-guessing everything. They’re going to stop making decisions because they know you’re going to change them anyway. They’re going to wait for you to tell them what to do instead of figuring it out themselves.
Congratulations, you’ve successfully trained your team to be helpless. This is the opposite of delegation.
What Delegation Actually Means
Real delegation is not “do this task exactly how I would do it and then let me review every detail.”
Real delegation is “here’s the outcome I need, figure out how to get there.”
It means defining the problem and the constraints, and then getting out of the way. It means accepting that there are multiple ways to solve a problem, and your way is not the only correct way.
It means letting people make mistakes. Small, recoverable mistakes that they can learn from.
It means distinguishing between “this is wrong and will break things” and “this is different from how I would have done it.” The first requires intervention. The second requires you to shut up and let it go.
This is hard for engineers. We’re trained to optimize. We see inefficiency and we want to fix it. We see a suboptimal solution and we can’t help but point out how it could be better.
But management is not about optimization. It’s about people. And people learn by doing, not by watching you do it for them.
The Autonomy Paradox
Here’s the paradox: the more you try to control how things get done, the less control you actually have.
When you micromanage, you become the bottleneck. Nothing can happen without your approval. Your team can only move as fast as you can review their work. And you can’t scale yourself.
When you delegate properly, you lose control over the details but gain control over the outcomes. Your team can move faster because they’re not waiting for you. They can handle more because you’re not the limiting factor.
But to get there, you have to be okay with things being done differently than you would do them. You have to trust that your team is competent, even when they’re doing something you wouldn’t do.
This is terrifying if your sense of self-worth is tied to being the smartest person in the room. If your value comes from being the person who knows all the answers, watching other people figure things out without you feels like being made obsolete.
But here’s the thing: you’re not being made obsolete. You’re being freed up to do the job you were actually hired for.
Your job is not to write the best code or design the perfect architecture. Your job is to make sure your team can do those things without you.
How to Actually Let Go
Okay, so how do you actually do this? How do you stop being a control freak and start actually delegating?
First, you have to get comfortable with good enough. Not everything has to be perfect. Most things just have to work.
Ask yourself: is this thing they’re doing wrong, or just different? Will it break production, or does it just offend my sense of aesthetic beauty? Is this a hill worth dying on, or am I just being precious about my opinions?
Second, you have to define outcomes, not processes. Tell people what you need, not how to do it.
Instead of “implement this feature using this specific architecture with these exact components,” try “we need users to be able to export their data as CSV, needs to handle up to 10k rows, should be reasonably fast.”
Then let them figure out how. And when they come back with a solution that’s different from what you imagined, resist the urge to tell them to do it your way.
Third, you have to be okay with people failing. Small failures. Contained failures. Failures they can learn from.
If someone is about to make a decision that will cause a small, recoverable problem, let them. They’ll learn way more from fixing their own mistake than from you preventing it.
If they’re about to make a decision that will cause a huge, expensive, unrecoverable problem, then yes, intervene. But be honest about whether the risk is actually huge or whether you just don’t like their approach.
The Trust Issues You Definitely Have
Let’s be honest: your inability to delegate is not about your team. It’s about you.
You don’t trust them to do it right. Or you don’t trust yourself to be valuable if you’re not the one doing the work. Or you don’t trust that you can let go of control without everything falling apart.
Maybe your team has given you reasons not to trust them. Maybe they’ve dropped the ball before. Maybe they’re junior and genuinely do need more guidance.
Or maybe they’re perfectly competent and you’re projecting your own anxieties onto them.
Either way, you need to deal with your trust issues, because they’re holding everyone back.
If your team genuinely isn’t capable of handling what you need them to handle, that’s a different problem. That’s a hiring problem or a coaching problem or a performance problem. And you need to address it directly instead of just compensating by doing everything yourself.
But if your team is capable and you still can’t let go, that’s a you problem. And you need to work through it before you burn yourself out trying to do everyone’s job for them.
When to Step In (And When to Shut Up)
Here’s a rough guide for when intervention is actually necessary:
Step in when:
Someone is about to make a decision that will have serious, irreversible consequences
They’re stuck and actively asking for help
They’re going in a direction that conflicts with organizational constraints they don’t know about
The timeline is critical and there’s no time to let them learn by doing
Shut up when:
You just don’t like their approach but it will probably work fine
They’re doing something differently than you would but it’s not actually wrong
You have opinions about code style or architecture philosophy
You’re feeling anxious and want to feel useful by inserting yourself
Most of the time, you should be shutting up.
The Long Game
Delegation is an investment. You’re trading short-term efficiency for long-term capacity.
Yes, you could solve that problem faster than your engineer can. But if you solve it for them, they don’t learn. And next time a similar problem comes up, they’ll need you again.
If you let them solve it, even if it takes longer, they learn. And next time, they can handle it themselves. And the time after that, they can teach someone else.
This is how you scale. Not by working harder or longer hours, but by building a team that doesn’t need you for every decision.
And yeah, it’s hard to watch someone struggle with something you could fix easily. It feels wasteful. It feels inefficient.
But you know what’s really inefficient? Being the bottleneck for your entire team because nobody can do anything without your approval.
The Real Measure of Success
Here’s how you know if you’re delegating well: what happens when you go on vacation?
If everything falls apart because nobody can make a decision without you, you’ve failed. You’ve built a team that’s dependent on you, and that doesn’t scale.
If everything runs smoothly and you come back to find that half the things you thought were critical turned out to be irrelevant, you’ve succeeded. You’ve built a team that can function independently.
Your job is not to be irreplaceable. Your job is to make yourself unnecessary for the day-to-day operations so you can focus on the bigger picture.
And the only way to do that is to let go of the small stuff. Let go of the need to review every decision. Let go of the idea that things have to be done your way.
Let your team own their work. Let them make mistakes. Let them figure things out.
And when you feel the urge to log in at midnight to “just make a few tweaks,” close your laptop and go to bed.
Your team doesn’t need you to be perfect. They need you to trust them.
So stop being a control freak and let them do their jobs.