Delegation Is Meant to Be Built, Not Assigned
Why the right person with the right task isn't always enough.
There’s a version of delegation failure that’s easy to diagnose: the wrong person, the wrong task, the wrong level of trust. Everyone can see it. Nobody disagrees on what went wrong.
The harder version looks nothing like that. The person is capable. The task is appropriate. The trust is real. Still, something breaks downstream. It doesn’t trace back to any single decision, because the failure wasn’t a decision.
The alignment never happened.
There’s a useful map for this. Jurgen Appelo’s 7 Levels of Delegation describes delegation not as a switch but as a progression: Tell, Sell, Consult, Agree, Advise, Inquire, Delegate. Each step builds something the next step depends on. By the time you reach Delegate, the person holding the work has enough shared context to make calls you haven’t anticipated, in ways that track with what you’d actually want.
The progression exists because ownership can’t transfer cleanly without the steps that build it. Someone might have the right title, the right experience, a track record of good judgment. They still might not have what they need to make good calls in the new context. The task transfers. The context doesn’t.
Not every delegation needs all seven steps. Leaders who’ve worked together for years skip levels all the time, and it works, because shared history fills the gaps.
Gaps get dangerous when that history doesn’t exist: when someone is new, when the problem is unfamiliar, or when the process itself is novel. The danger is that it doesn’t look like failure when it starts.
Here’s an example of that gap in practice.
I was handed the annual planning process a few months into the role. The output was a technology portfolio that the CPO and CTO presented to Finance and the rest of the C-suite. I had credibility from prior experience, so the handoff came with a prior-year artifact, the presentation date and the implicit message: we know you’ve done this before, own it.
I had. And so I did.
I designed the initiative prioritization process to be independent of staffing. My blind spot was that the CPO and CTO cared deeply about team continuity. In their model, an initiative that disrupted existing team composition carried a real cost, one that should inform whether it got greenlit. That assumption never came up in a conversation. I didn’t ask. They assumed I knew.
When the deliverables came in, nothing lined up:
Some teams treated their current staff as available to be assigned across initiatives.
Others read my instructions as incremental headcount only and left existing staff out entirely.
Some had a shadow sheet mapping every person to an initiative because keeping teams intact was how they thought about it.
The infrastructure lead couldn’t give me anything until he knew what the feature teams were building.
Everyone had acted in good faith. Still, the assumptions never got compared. My process had completely missed what mattered most.
The CPO and CTO had to scramble to get the artifact ready for the C-suite. Two days of Product and Eng SVPs untangling what should have been built into the process from the start. The part that still sits with me: the people who followed my instructions the best had the most rework to do.
That residue doesn’t get cleaned up when the deliverable gets fixed. It persists in ways that look like execution failure, when the actual cause traces back to a conversation that should have happened and didn’t.
The hardest delegation failures don’t start with the wrong person or the wrong task. They start in the window where shared understanding should have been built and wasn’t.
Don’t just delegate; build shared context collaboratively.
This is so poignant and such a great build from your previous post!