You hired senior engineers to think, but you keep telling them what to do

This is how well-intentioned managers quietly block growth, trust, and retention.

Dec 23, 2025

👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

You hired senior engineers because you wanted people who could take ownership of work, not just code fast. People who’d been around long enough to spot the mistakes before they happen. People who could take a problem and run with it.

So why are you still telling them exactly how to solve every problem?

A hiring manager brings on an experienced engineer, pays them a senior salary, gives them a senior title - and then proceeds to hand them projects with every technical decision already made. The engineer becomes an expensive pair of hands. They write the code, sure. But they’re not really engineering anything.

Decision hoarding

There’s a specific failure mode I see in engineering managers, and it’s not that they’re bad at making technical decisions. It’s that they’re too comfortable making them.

When you came up through the IC track before transitioning to management, you got good at solving problems. Really good. You developed instincts about architecture, trade-offs, and implementation approaches. And now that you’re managing people, those instincts don’t just disappear. They’re still there, whispering the “right” answer every time a technical question comes up.

So you share that answer. You write specs. You explain how you’d approach the problem. You think you’re being helpful - giving your team the benefit of your experience, saving them from mistakes you’ve already made.

What you’re actually doing is stealing their growth opportunities.

Every decision you make for a senior engineer is a decision they didn’t get to learn from. Every time you prescribe the approach, you rob them of the chance to develop their own judgment. You’re not mentoring them. You’re just... using them as an extension of your own hands.

Then trust starts to fade

What thoughts appear inside the head of a senior engineer who’s being managed this way:

“Why did they hire me if they don’t trust my judgment?”

That question starts small. Maybe they assume they need to prove themselves first. Fair enough - they’re new to the team, the codebase, the domain. They’ll earn autonomy over time.

But then months pass. They’ve shipped features. They’ve fixed production incidents. They’ve demonstrated, repeatedly, that they know what they’re doing. And still, every project comes with the approach already pretty much decided. Every technical discussion ends with “here’s what we’re going to do” rather than “what do you think we should do?”

The question gets louder: “Do they actually respect my experience at all?”

And eventually, they start looking for a team that does.

If you’re enjoying this article, consider subscribing to get:

✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

What decision delegation should actually look like

Let me be specific about what I mean by delegating decisions, because it’s not the same as delegating tasks.

Task delegation sounds like: “We need to add rate limiting to the API. Use a token bucket algorithm with Redis for storage. Here’s the interface I want you to implement.”

Decision delegation sounds like: “We’re getting hammered by a few clients making too many requests. We need some kind of rate limiting. What approach would you take?”

The first version treats your senior engineer as an implementer. The second treats them as a problem solver.

Now, some managers hear this and panic. “But what if they make the wrong choice? What if they pick an approach that doesn’t scale, or that creates tech debt, or that doesn’t fit with our architecture?”

Good. Let them.

I don’t mean let them deliver disasters to production. I mean let them propose approaches, defend their thinking, and yes, sometimes be wrong. That’s how judgment develops. Your job isn’t to prevent all mistakes - it’s to create an environment where mistakes become learning opportunities rather than career-ending failures.

A graduated autonomy framework

If you’ve been hoarding decisions for a while, you can’t just flip a switch and hand over all technical decisions. That’s a recipe for chaos (and for your senior engineers to feel set up to fail).

Instead, think about graduated autonomy across four levels:

Level 1: Observe and recommend. For new team members or unfamiliar domains, have them shadow decisions and then tell you what they would have done. This builds their context without risking anything.

Level 2: Recommend, then execute. They propose the approach, you discuss it together, they implement. You’re still involved, but they’re driving.

Level 3: Execute, then review. They make the decision and implement it, then walk you through what they did and why. You’re available if they get stuck, but you’re not approving every step.

Most senior engineers should be operating at Level 2 for difficult or complex projects and Level 3 for more straightforward ones within their areas of expertise. You have to be setting the tone on what you expect between the two.

If you’ve had someone on your team though for six months and they’re still at Level 1, something’s wrong - either with your delegation or with your hiring.

The conversation you need to have

If you recognise yourself in this article, you need to actually do something about it. And that starts with a conversation.

Pull aside your senior engineers, one at a time and say something like:

“I’ve been thinking about how I’ve been delegating work, and I’m worried I’ve been too prescriptive about technical approaches. I want to give you more ownership over how we solve problems, not just execution. What areas do you feel like you should have more decision-making authority?”

Then actually listen. They might be polite at first - they’ve learned that pushing back on managers rarely ends well. But if you create genuine space for the conversation, they’ll tell you where they feel constrained.

And then you have to actually start letting go.

That means sitting in meetings where they propose an approach you wouldn’t have chosen, and be very careful about how to challenge it, or learn to say “let’s try it” instead of “actually, I think we should do it this way”. It means sometimes watching them make mistakes that your experience could have prevented, and letting those mistakes be learning moments rather than evidence that you need to take back control.

It’s hard. Your instincts will scream at you to intervene. But your job as a manager isn’t to make every decision right. It’s to build a team that can make good decisions without you.

The payoff?

I’ll be direct about the stakes here: senior engineers who feel like code monkeys will leave your team. Not immediately, maybe. The paycheck keeps them around for a while. But they’re already mentally halfway out the door, scrolling through job postings, taking recruiter calls they would have ignored a year ago.

And when they do leave, they’ll tell you it’s about compensation or career growth or wanting a new challenge. They won’t say “I left because you never let me make any real decisions”. That’s too awkward, too personal. But it’s often the truth.

The engineers who stay - who build their careers on your team, who become the institutional knowledge you desperately need - are the ones who feel genuine ownership over their work. Not just ownership of the code they wrote, but ownership of the decisions that shaped it.

Give your senior engineers decisions. Trust their judgment, even when it differs from yours. Let them be wrong sometimes, so they can learn to be right more often.

That’s how you keep them. That’s how you build a team that doesn’t need you hovering over every technical choice.

Which is what you wanted all along, isn’t it?