The Mintable
The word "delegate" makes it sound simple. Hand the task to someone else. Move on. But anyone who has tried it knows that's not how it goes. You either find yourself checking in too often and annoying people, or you step back completely and get burned when something falls apart three weeks later.
The problem isn't that delegation is hard. The problem is that most people skip the part that makes it work.
What you're actually delegating
Delegation isn't just handing off a task. You're handing off ownership — which means the person needs to understand not just what to do, but why it matters, what success looks like, and what authority they have to make decisions along the way.
When those things are clear, people can actually run with something. When they're not, you end up with a version of the task that doesn't match what you had in mind, followed by a frustrating revision conversation where the person feels like they did it wrong and you feel like you would have been better off doing it yourself.
The three things to clarify before you hand off
The outcome, not the process. Tell someone what done looks like, not exactly how to get there. If you specify the process, you haven't delegated — you've assigned steps. Steps you'll have to monitor. Outcome-focused delegation leaves room for the person to figure out the how, which builds their judgment and often produces better results than your original process would have.
The boundaries of their authority. What can they decide on their own, and what do they need to bring back to you? This is the part most managers skip. Without it, people either over-escalate (constantly asking permission for things they could handle themselves) or under-escalate (making decisions that had downstream effects they didn't account for).
The check-in rhythm. Not a cadence of status updates — a mutual agreement on when it makes sense to connect. If the project is two weeks long, maybe once mid-way through and then a review at the end. This gives you visibility without micromanagement, and gives them the space to actually work.
The trust problem
A lot of delegation failure comes down to trust — or rather, a manager's discomfort with uncertainty. You can't know exactly what someone is doing if you're not doing it yourself. That discomfort is real, but acting on it by hovering is the most reliable way to create the outcome you're trying to prevent.
People who feel micromanaged stop thinking for themselves. They optimize for telling you what you want to hear rather than telling you what's actually happening. That's worse for you than the uncertainty you were trying to avoid.
The antidote is building trust incrementally. Start with smaller things. See how they handle them. Use that as a basis for trusting them with bigger things. Don't hand someone a mission-critical project with no visibility and call that delegation — that's abdication.
When to take it back
There are situations where it's right to step back in. If someone asks for help and you don't provide it, that's not delegation — it's indifference. If a decision has escalated in scope or risk beyond what was originally scoped, it's reasonable to re-engage. If things are going badly wrong and the timeline doesn't allow for recovery without intervention, get involved.
But when you do step back in, be explicit about why. Don't just take the work back without acknowledging what's happening. "I'm stepping in here because the timeline moved up and we can't absorb a miss at this stage" is a very different signal than silently resuming control, which feels like a performance judgment even when it isn't.
What delegation actually buys you
The reason to delegate isn't just to free up your time, though it does that. It's to develop your team. Every time someone figures out a hard thing on their own, they get more capable. Every time you take it back from them before they can, they stay exactly where they are.
Your job as a manager is to build a team that needs you less, not more. Delegation is how you do that.