The conversation happened on a Tuesday, two weeks after launch.
“I thought we were building this to scale,” he said. A good engineer. Senior. The kind you bring into a room when the scope is fuzzy.
“We are,” someone else said.
“Then why did we optimize for speed, not capacity? Why is everything hardcoded?”
Nobody had a good answer. I’d made the decision in a design meeting the week before. The team wasn’t there. The trade-off was simple enough: build something that worked now, and refactor when we hit the wall. Scale would come after product-market fit. Months away.
He’d built what was asked. He’d done it well. He just didn’t know why it was asked for it that way.
Nobody had done anything wrong. We’d simply delegated without delegation actually happening.
The Task Is Not the Delegation
Most leaders think delegating means handing someone a task and a deadline.
“I need the quarterly budget by Friday.” “Can you run point on the migration?” “Please draft the org changes proposal.” These are asks. They’re not delegations. They’re assignments. And they’re missing the thing that makes delegation actually work.
Delegation is when someone else can make decisions about that work in your absence. When they understand not just what to do, but why it matters, what constraints bind it, what would make you regret the decision, and when to escalate versus when to decide on their own.
When that doesn’t transfer, they execute the task. They don’t own the outcome.
The engineer builds. The project manager hits the milestone. The ops team deploys. Everyone did what they were asked. The result still doesn’t match what you decided, because the decision criteria stayed in your head.
This is the delegation illusion. It feels like you’ve handed something off. You haven’t. You’ve just created distance between yourself and the execution.
What Actually Transfers
Here’s what you communicate when you delegate: the conclusion and the deadline.
“We need to migrate the database by Q2.” “Build this feature with a focus on mobile.” “Hire for the backend team.” These are clear. They’re memorable. They’re also incomplete.
What doesn’t transfer: the constraint you were weighing, the tradeoff you’d already decided against, the thing that would change your mind. The boundary between what’s in scope and what you explicitly put aside.
When you spend two hours in a design meeting wrestling with a choice, your brain integrates all those conversations. You know, without having to re-examine it, what would disqualify an option. You know what success looks like because you’ve already rejected the alternatives.
The person who receives the task doesn’t have that. They have a brief.
And so they solve it well, given their brief. Which is almost never the whole problem you were solving.
I’ve seen teams build the technically correct solution so effectively that it became unusable at scale. I’ve seen features shipped that matched the spec and violated the business model. I’ve seen migrations executed perfectly on time that broke the thing they were supposed to preserve.
None of those people were incompetent. They solved the problem they understood. The problem they actually needed to solve was different.
The Authority Gap
The second failure point is subtler.
When you delegate, you’re supposed to be delegating and stepping back. But most delegation is actually: “Do this. I’m going to stay involved so you don’t screw it up.”
That doesn’t work. Because now the person executing has all the responsibility and none of the authority. They can’t make the call when something diverges. They have to check.
And so the execution stays bottlenecked to you.
“Should we use X or Y?” “Do I escalate this issue or handle it?” “This change would break what you said we’d avoid, but it would save two weeks. What do you want?”
You’ve created a relay system. They’re executing. You’re the decision layer. Nothing’s actually been handed off.
Real delegation means giving someone a decision space, not just a task. It means they can move within the boundaries you’ve set without checking back. It means they can resolve edge cases without waiting for you.
When that doesn’t happen, you haven’t delegated. You’ve created a proxy. And the proxy is slower than you doing it yourself.
The Practice
Two things, before you hand something off.
First: explain the criteria, not just the goal. “We need 50% faster response times” is a goal. The criteria are: “We’re optimizing for latency at the cost of memory, not the reverse. The acceptable bandwidth is X. We’re willing to accept Y trade-off but not Z.”
That takes five more minutes. It saves weeks. Because now when the engineer faces a choice you didn’t predict, they can make it the way you would.
Second: make sure they understand the boundaries of their authority. Where can they decide? Where do they need to check with you? “You own the technical approach completely. You escalate to me if the scope changes, or if you need to cut a corner you think I wouldn’t accept.”
This sounds like more process. It’s not. It’s clarity. It moves faster than the back-and-forth of a proxy relationship.
Then actually step back. Don’t check in constantly. Don’t override decisions because you’d have done it differently. The whole point of delegation is the person you’re trusting gets to be wrong, and wrong is cheaper than bottleneck.
Delegation ends when the other person can explain the decision criteria, not just the task.
Not the goal. Not the deadline. The reasoning. The boundaries. The choices you made before you handed it off.
Until that transfer happens, you haven’t delegated. You’ve just made someone your proxy, and you’re still carrying the decision.
Resources & Further Reading
Radical Candor by Kim Scott (St. Martin’s Press, 2017) — Chapter 4 on delegation: “Giving them the space to be great, not the instruction manual.”
Implementation Intentions: Strong Effects of Simple Plans by Peter Gollwitzer, American Psychologist, 1999 — The research basis for criteria transfer. When specific decision boundaries are stated, execution improves.
ZenOne also produces trance music. The mixing arc behind his productions is at zenonemusic.substack.com.