Early in my management career, I had a team of six engineers and I was still the person who knew the most about every part of the system. When something urgent came up, I’d fix it myself. When a design decision needed making, I’d make it. When a PR needed reviewing, I’d review it. I was efficient, responsive, and completely unsustainable.

It took a holiday, a proper two-week break where I was genuinely unreachable, for me to see the problem. The team didn’t fall apart while I was away. But they didn’t move forward either. They’d been waiting for me on three separate decisions, and nobody felt empowered to make them without my input. I’d created a team that was dependent on me, and I’d done it by being “helpful.”

Why We Resist

Delegation is the skill that unlocks everything else in leadership, and it’s the one most new managers resist the longest. Especially those of us who came from IC roles where doing the work ourselves was faster and felt safer.

The resistance is understandable. When you delegate something, you lose control over how it’s done. The person you delegate to might do it differently than you would. They might do it slower. They might make mistakes you would have avoided. And if it goes wrong, you’re still accountable.

Fournier identifies the core issue clearly: trust and control are the main drivers of micromanagement. If you’re micromanaging someone, chances are you don’t trust that the task will be done right, or you want to tightly control the outcome so it meets your exact standards. Both impulses are natural. Both are destructive at scale.

The thing that shifted my thinking was a simple reframe: delegation isn’t about getting tasks off your plate. It’s about building capability in your team. Every time you do something yourself that someone on your team could learn to do, you’re making a short-term trade that costs you in the long term. You save an hour today and lose a team member’s growth opportunity.

Tasks Versus Outcomes

The most common delegation mistake is delegating tasks rather than outcomes. “Write the API endpoint for user authentication” is a task. “Make sure users can authenticate securely and the implementation follows our standards” is an outcome. The difference matters enormously.

When you delegate tasks, you’re still doing the thinking. You’ve broken the problem down, decided on the approach, and handed someone the implementation work. They learn to execute but not to decide. When you delegate outcomes, you’re giving someone the problem and trusting them to figure out the approach. They might do it differently than you would, and that’s fine, as long as the outcome is right.

This requires letting go of your preferred approach, which is harder than it sounds. I’ve caught myself giving “outcome” delegation that was really task delegation in disguise, “I want you to own the authentication system, and here’s exactly how I think you should build it.” That’s not delegation. That’s dictation with extra steps.

Adjusting by Context

Fournier provides a useful framework for thinking about when and how to delegate. She suggests a matrix based on two dimensions: how complex the work is, and how frequently it occurs.

Simple, frequent tasks should be delegated, these are the things that build routine capability. Complex, frequent tasks should also be delegated, but more carefully, with more support and check-ins. Simple, infrequent tasks you might just do yourself, the overhead of explaining them isn’t worth it. Complex, infrequent tasks are interesting, they’re often worth delegating specifically for the training value, even if it would be faster to do them yourself.

The other dimension I’d add is project stage. Early in a project, when the direction is still being set, tighter involvement makes sense. Once the direction is clear and the team is executing, stepping back is essential. And at the end, when you’re shipping and things are stressful, the temptation to jump back in is strongest, and usually the worst time to do it, because it signals that you don’t trust the team to deliver.

The Trust Equation

Delegation requires trust, and trust requires delegation. It’s circular, which is why getting started feels so difficult.

The way I’ve found to break the cycle is to start small. Delegate something with low stakes and clear success criteria. Give the person space to do it their way. Resist the urge to check in every day. When they deliver, and they usually do, even if it’s not exactly how you would have done it, acknowledge it. Then delegate something slightly bigger.

Each successful delegation builds trust in both directions. They trust that you’ll give them real work and real autonomy. You trust that they’ll deliver. Over time, the things you’re comfortable delegating grow, and the things you need to hold onto shrink.

The counterintuitive truth is that your team needs you to stop doing their work. When you hold onto tasks, you’re not just creating a bottleneck, you’re sending a message that you don’t believe they can handle it. That message is corrosive, even when it’s unintentional.

What to Keep

Delegation doesn’t mean abdicating. There are things that should stay with you: setting direction, making decisions that affect the whole team, having difficult conversations, representing the team to the rest of the organisation, and maintaining relationships with stakeholders.

The general principle I use is: delegate anything where someone else can get to 80% of the quality you’d achieve, and keep anything where your specific context, relationships, or authority are genuinely required. Most things fall into the first category. Far fewer fall into the second than you think.

Ajit Kambil makes the point that delegation is the single biggest key to protecting your time as a leader. Every task you hold onto is time you’re not spending on the things only you can do. And the things only you can do, strategy, people development, stakeholder management, are almost always more valuable than the things you’re holding onto out of habit or comfort.

The Letting Go

There’s a moment in every manager’s development where delegation stops being a technique and starts being a mindset. You stop thinking “what can I hand off?” and start thinking “what do I actually need to be involved in?” The default shifts from holding to releasing.

I’m not going to pretend I’ve fully made that shift. After 25 years, I still catch myself jumping into things I should leave alone. The IC instinct to solve problems directly is deeply wired, and it doesn’t disappear just because your title changed. But I’ve learned to notice it faster, and to ask myself the question that matters: “Am I doing this because the team needs me to, or because I need to?”

The honest answer is usually the latter. And that’s the signal to let go.