May 10, 2026 · By Denis N.
The Delegation Problem: Why "Nobody Does It Right" Is a Process Issue, Not a People Issue
Every small business owner has, at some point, said this sentence: "I'd love to delegate, but nobody does it right."
Sometimes out loud, to a friend over a beer. Sometimes silently, while redoing a piece of work a team member just handed in, asking yourself why you bothered asking them in the first place. Sometimes in a moment of frustration that's already been rehearsed enough times to feel like the truth: nobody does it right, so I'll just do it myself.
And here's the thing: you're not wrong about the experience itself. You really did delegate that task, they really did do it differently from how you would have done it, and you really did end up taking it back to fix it. And the cumulative weight of all the times this has happened is one of the reasons you're still doing tactical work at 9pm on a Tuesday.
What's wrong is the diagnosis.
"Nobody does it right" is the description of a symptom presented as if it were the cause. In almost every case I've seen up close, the cause isn't the people. It's the process, or more honestly, the absence of one. Most of what reads as a hiring failure is actually a handoff failure: an outcome that was never defined, a decision boundary that was never drawn, a feedback loop that closes only when something visibly breaks.
This post is about the gap between those two readings, and about what changes when you start treating delegation as a process design problem rather than a personnel one. If you've ever read my earlier post on whether you're the bottleneck in your own business, this is the companion piece. That one was about the symptom, this one is about the specific mechanism inside it.
What's Actually Happening When You Take a Task Back
When a delegated task comes back wrong and you decide to fix it yourself, three things are usually happening at the same time, and only the most visible one of them feels like the problem.
The visible thing is the output: the work isn't right, the deadline is closing in, and the fastest path to a usable result is your own hands on the keyboard. Reaching for the keyboard in that moment is a reasonable response, but underneath that surface, two quieter things are going on at the same time, and those are the ones that guarantee the same situation will repeat next month with a different task.
The first quiet thing is that you never defined the outcome, you defined the activity. "Draft this proposal," "handle the supplier follow-up," "manage the install": these sound like assignments, but they're really categories of work, not finished states. The owner is treating "this needs to get done" as if it were the same instruction as "this is what done looks like," and from where they're sitting those feel identical. The team on the other side of the handoff can only act on the first one, because the second one was never sent.
When work goes out shaped like that, a name for a bucket of activity with no description of the finished state, what comes back is whatever the person on the receiving end thought "good" looked like, calibrated against their own context, their own past employers, their own assumptions about what you want. There's no fair way to grade the result against your standard, because your standard was never out loud.
The second quiet thing is that "fixing it yourself" is, accidentally, a form of training. You're teaching the team something every time you take a task back, but you're not teaching them what you think you are. You think you're teaching them the standard, but what you're actually teaching them is that their version doesn't matter, because it'll be overwritten anyway. After enough cycles, capable people stop putting full effort into delegated work, not because they're lazy but because they've correctly read the system: the reward for trying hard is having your work redone in front of you, and the reward for handing in something rough is the same outcome, with less wasted effort.
Asana's 2025 State of AI at Work report puts a number on the upstream version of this: 84% of workers report unclear task ownership. That stat usually gets read as a teamwide communication problem, but in a small business it's almost always pointing at one specific gap, the moment of handoff between owner and team. If ownership is unclear at that moment, everything that happens after it is downstream of the same root cause.
So when you find yourself saying "I just need to do it myself," the real question isn't whether your team is capable. The real question is what was missing from the handoff that put you back in this position. Almost always, the answer is one of three things, and most owners are running into all three at once without separating them out.
The Three Invisible Failures Behind "Nobody Does It Right"
These three failures aren't about the people you hired but about what the people you hired were given to work with. If even one is in place, you'll get back work that needs redoing, and if all three are in place at once (which is the typical case), you'll convince yourself, reasonably but incorrectly, that the problem must be the team.
Failure 1: You Never Defined What "Right" Looks Like
A few years ago I was running a procurement project at a bank, selecting and buying a new information system for one of their internal departments. At one point in the project I needed a technical specification drafted, the kind of mid-level document vendors would use to give us rough cost estimates. I pulled in an analyst who'd written this kind of spec on other projects, walked him through the business requirements I'd gathered at the kickoff meeting, told him what we needed, answered his questions. It felt like a clean handoff.
A week later I checked in. The spec wasn't ready, which didn't worry me much — first drafts always slip a few days. When I followed up at the end of week two and it was still "in progress," I asked to see what he had so far. What he sent over went much deeper than I'd expected: an extremely detailed breakdown of every system function, with diagrams, full use cases, the works, on its own terms a careful and competent piece of work. The problem was the stage we were at. We needed enough detail for vendors to price the project, not a build-ready specification, and the underlying requirements weren't locked yet, which meant a chunk of those careful diagrams was going to be redrawn anyway.
I had to rework his draft down to the scope it should have had in the first place. Not because he'd done a bad job, but because he'd done the wrong job very well, and the reason he'd done the wrong job was sitting on my side of the kickoff meeting. I'd told him what to write but not how much, not for whom, not what "good enough at this stage" looked like, because in my head, those things were obvious. They weren't obvious to him, and there was no reason they should have been.
That's Failure 1 in a sentence: you handed off the task carrying a fully-formed picture of "right" in your head, and you assumed the picture transferred along with the task itself. It almost never does, because pictures don't transfer. Only the words you actually say out loud do, and those words usually contain a fraction of what's in your head.
The fix here isn't a thirty-page operations manual; it's a single paragraph that names the outcome, names the audience, and gives one example of "good enough at this stage" alongside one example of "not done." Most of the calibration problems that show up later are problems you could have prevented with five minutes of writing before the kickoff meeting.
Failure 2: You Delegated the Task Without the Decision Boundaries
Even if "right" is defined, work involves decisions on the way to right. The materials don't fit the spec: substitute or check first? The client asks for something not in scope: agree, or escalate? The supplier slips a day: push back, or accept it?
When the decision boundaries aren't drawn, the safe play for any team member is always the same: bring it to the owner. Which is what you experience as "they can't make a decision without me," and which is, again, a process gap rather than a capability one.
There's a textbook version of this failure mode in The E-Myth Revisited. Sarah, a baker who'd built a small bakery into something that needed help, hired an employee called Elizabeth and handed her the books, the keys, and the day-to-day operations on the basis of trust. There were no documented decisions about what Elizabeth could authorise, no written standards, no operational handover beyond verbal explanation. It worked, in the way these arrangements work, until Elizabeth left. At which point Sarah discovered she didn't have a delegated business; she had an Elizabeth-shaped hole in her business, and no system that could be handed to a replacement.
The phrase Michael Gerber uses for this is delegation by abdication — handing off the work without handing off the operating instructions. From the outside it looks like trust, but from the inside it's an absence of structure that the team is quietly working around every day, escalating things they shouldn't have to and freezing on things they're allowed to handle but were never told they were allowed.
The fix here is mechanical and takes about an hour. For any task you keep finding yourself pulled back into, write down the decisions associated with it and split them into three buckets: decide and proceed, decide and tell me afterwards, check with me first. That third bucket should be smaller than feels comfortable, and if it isn't, you haven't actually delegated. You've outsourced the typing while keeping the thinking, which is the configuration that produces the most rework and the least relief.
Failure 3: You Gave Feedback on the Output, Not the Process
The third failure is the one most owners don't notice they're committing, because it feels like the responsible thing to do. The work comes back not quite right. You fix it, maybe pointing out what was wrong while you fix it. The output is correct, the deadline is met, and the team member presumably learned something from watching you correct it.
What they actually learned is what the correct version of that specific deliverable looks like. They did not learn the process that would have produced it. Next month, a different task with the same underlying gap shows up, and the same kind of failure happens, with a different surface but the same root cause underneath.
This is the pattern Elsbeth Johnson, a senior lecturer at MIT Sloan, names in her recent HBR piece on why even experienced leaders struggle to delegate (with an open-access summary on the MIT exec ed site for those without HBR access). One of her findings is the gap that shows up when leaders confuse helping with deciding: making the decision for someone, or doing the work for them, doesn't build their capability. It builds their dependency on you. Every time you fix the output without rebuilding the process, you've reinforced the dependency. The team gets faster at signalling "I'm stuck" and slower at being unstuck independently, because the second one was never the path that paid off.
The fix is to separate two questions when work comes back imperfect. First, does the output need to ship today? If yes, fix it, but do that work visibly broken into a process the team can later replicate, not as a five-minute owner sprint with the team watching. Second, what would have had to be different upstream for this output to come back ready? That conversation is the one that compounds. The first question buys you today; the second buys you the next twelve handoffs.
The 20-Minute Fix That Solves 80% of Delegation Failures
If the three failures above describe your situation, the actionable starting point isn't an operations manual or a redesigned org chart. Both of those are real projects, and they belong on a longer time horizon. The unblocking move is much smaller, and most owners can do it in twenty minutes per task.
Pick one task you keep finding yourself pulled back into, and resist the temptation to make a list of five. The one that came back wrong most recently is usually the right candidate, because the friction is fresh in your head and you can still name what was missing without having to reconstruct it.
For that task, write a single page that contains three things, and only three things.
The first is what "done" looks like for this specific task at this specific stage. Aim for a paragraph at most, concrete enough that a competent person could grade their own output against it before handing it to you. Wherever possible, include a worked example: a previous version of this output that hit the standard, and if you have one, a previous version that missed it. Worked examples carry information that abstract criteria don't, because they show the standard being applied rather than just stated.
The second is the decision boundary, in three buckets: decisions the person can make and proceed; decisions they should make, proceed with, and tell you about afterwards; decisions that need a check before they move. Almost every first attempt at this exercise loads the third bucket too heavily, because the third bucket is where the current default sits, and putting a decision there feels safer than letting it through. A useful test: if a decision in your "check first" bucket has a clear rule attached to it (under $X, approve; over $X, escalate), it doesn't belong there. It belongs in bucket one with the rule written next to it. The post on reducing admin time in a small business covers how to default your approvals so they stop landing in your inbox in the first place.
The third is the check-in cadence: when you'll talk about this task next, what the team member should bring to that conversation, and what you'll be looking at. The point of naming the cadence in advance is that it removes the temptation to "just check in real quick" between scheduled moments, which is the behaviour that, more than anything else, signals to the team that the boundaries you wrote down don't actually apply.
That's the whole document, and it should fit on one page or two at most. It is explicitly not an operations manual, and you should resist any urge to make it one, because the goal here is to be unblocked on this task with this person right now, not to build infrastructure. The infrastructure version exists and is worth building eventually, but it's a different project on a different timeline, and trying to do both at once is how owners end up with neither.
The reason this works is that most failed delegations don't fail from absence of system; they fail from absence of clarity at the handoff moment. A one-page document forces you to articulate the things that were silent, and the act of writing them down often surfaces gaps in your own thinking that you didn't know were there until you tried to write them out. That's the actual value of the exercise, and it's the part you can't get from reading about it.
Three Questions That Tell You Whether It's a Process Problem
If you're not sure whether the issue with delegation in your business is the people or the process, three questions will get you to a defensible answer faster than any longer assessment.
1. For the last task you took back to fix, did the person have a written description of what "done" looks like, or were they working from a verbal explanation you gave at handoff?
If the answer is "verbal," you have a Failure 1 situation regardless of how the work came back, and the diagnosis is almost certainly process. The team member is being asked to render an output that lives in your head into a deliverable that lives outside it, with a translation layer that consists of whatever they remembered from a conversation that may have happened days or weeks ago. Even an experienced team member with strong intent will produce variance under those conditions, and you have no fair way to grade what comes back because the standard wasn't written down to grade against.
2. In the last ten escalations to your inbox, how many had a documented rule that should have answered them without your input?
Walk through them honestly. Not "could in principle have been documented" but "would have been answered if a written rule existed and the team had access to it." If the count is six or higher, you have a Failure 2 situation, and the team's behaviour you're reading as "they can't make decisions" is actually them correctly inferring that no rule exists, so the safe move is to ask. They aren't avoiding decisions; they're routing around an information gap that you control.
3. When you fixed a delegated task in the last month, did you change anything about the process for next time, or only the output for this time?
This is the question most owners answer with a long pause, because the honest answer is usually "only the output." Fixing the output is the responsible thing to do for the deliverable in front of you, but if it isn't paired with a process change, the same kind of failure is queued up to happen again in three to six weeks on a different task. If you've been fixing outputs without adjusting upstream conditions for any length of time, the pattern you're calling "nobody does it right" is one you've been actively, if unintentionally, maintaining.
If two or three of these answers expose gaps, the diagnosis is process. The team you have can almost certainly do the work, given the missing pieces. The remaining question is which of the three failures to fix first, and the rule of thumb is to start where the most recent and the most painful failures have clustered, because the friction tells you where the leverage is.
When It Really IS a People Problem (And How to Tell)
Most of what owners diagnose as a people problem turns out to be a process problem on closer inspection, but not all of it. Sometimes the issue really is the person, and a process fix won't change that. The skill is being able to tell which one you're looking at, because the cost of misdiagnosing in either direction is real: you fire someone whose performance was being hidden by a missing process, or you keep someone who would underperform in any system.
There's one diagnostic question that resolves most cases. If you replaced this specific person with a similarly experienced professional, gave them the documented description of "done," the decision boundaries, and the check-in cadence, would they succeed? If yes, you have a people problem and the system is ready for a different occupant. If no, you have a process problem and the next hire will fail in the same way.
Two specific signals point at people problems rather than process problems. The first is a values or culture mismatch: the person clearly understands the standard, can articulate it back to you, and still chooses to work outside it. The system is intact; the operator has decided not to use it. The second is a capability ceiling: instructions are clear, the work has been demonstrated, the tools are in place, and the person consistently produces output below the standard despite effort and time. This second case is harder to diagnose honestly, because it's tempting to keep adding instruction in the hope that the next clarification will be the one that lands. If three serious clarifications haven't moved the output, additional clarification probably won't either.
These cases exist, and they need different solutions than process redesign. But they're rarer than the language of "nobody does it right" implies, and the only way to tell which kind of problem you're holding is to do the process work first and see what's left.
Where the Cost Actually Lands
The compound cost of getting this wrong isn't dramatic on any given day. It shows up as one more task you took back, one more evening that ran later than it should have, one more decision you adjudicated that didn't need to reach you. None of those individually feel like a structural issue, which is why most owners carrying them don't recognise the shape of the problem they're in.
In the TIMWOODS framework of operational waste, this pattern lives in the Skills category — the systematic underuse of capability, which in a small business almost always presents first as the owner doing work that someone else could do, and only later as a team that's slowly disengaging because their work keeps being overwritten. That second part is the one that compounds: every undocumented handoff adds a small amount of process debt that the next handoff inherits, and after enough months of accumulation, you end up with a team that has correctly inferred that effort isn't the path to outcome and a business that runs only because you're personally compensating for the gaps.
The good news, if it's good news, is that the same pattern that compounds against you can compound for you once the documentation starts. The first one-page document is mostly a relief. The third one starts to give you back hours. By the time five or six core tasks are written down with their boundaries and cadences, the "I'd love to delegate but nobody does it right" sentence becomes harder to say with conviction. The work coming back is closer to what you wanted, the escalations are fewer, and the evidence has shifted under the diagnosis you started with.
See Which Handoffs Are Quietly Pulling You Back In
This article names the failure modes. HiddenDrain points at the specific ones in your business — which tasks keep boomeranging, which decisions you're still adjudicating, and where the next one-page fix will buy back the most hours. Six to eight questions, free, in under 10 minutes. No signup required.
Written by Denis N. — process improvement specialist based in Yerevan, Armenia. PMP and ACP certified. Eight years applying lean methodology across service teams in IT, retail, and banking.