Delegating Badly Is Slower Than Doing It Yourself

The first time most people bring in outside help, it goes badly enough to put them off trying again. You're overloaded, you hand a piece of work to a freelancer, and what comes back isn't what you had in mind — so you spend hours fixing it, or explaining what you actually wanted, or quietly redoing it yourself. The conclusion drawn is usually that delegation doesn't work for this kind of work, that it's faster to do it yourself, and that nobody else will do it properly. And so the overload continues, permanently.

That conclusion is nearly always wrong, and the diagnosis is nearly always the same: the delegation failed at the briefing stage, not the execution stage. The work came back wrong because the instruction was incomplete — assumptions in your head that never made it into words, context you didn't think to mention because it's obvious to you, standards you'd know instantly and never articulated. A capable person given an incomplete brief produces something reasonable that isn't what you wanted, which looks like their failure and is usually yours.

This matters because delegation is how a service business stops being capped by one person's hours, and because the first attempt tends to determine whether anyone tries again. If your only experience of bringing someone in was a mess, you'll conclude it doesn't work — when what actually happened is that you skipped the part that makes it work, which is a specific, learnable set of practices rather than a talent for finding good people.

The other thing worth saying upfront: delegation genuinely costs more than doing it yourself the first time. Briefing properly, reviewing, and giving feedback takes longer than just doing the task, and people abandon delegation at exactly this point, concluding it isn't worth it. It isn't worth it — on the first project. It becomes worth it on the fifth, when the same person needs a fraction of the explanation. Here's how to get from the first to the fifth without giving up.

Key Takeaways

• Most delegation failures are briefing failures. The work came back wrong because the instruction was incomplete, not because the person was incapable.
• The first project costs more than doing it yourself. That's expected. The return comes from the fifth project, not the first — abandoning early guarantees you never get there.
• Start small and specific. A defined, low-risk first piece of work tells you what someone is like at a fraction of the cost of finding out on something important.
• Give context, not just instructions. People do better work when they understand the goal and the audience, because it lets them make good decisions you didn't anticipate.
• Build a repeatable process. Every time you brief someone, capture what you explained — it becomes the documentation that makes the next handover far faster.

Brief Properly, Because That's Where It Fails

The single highest-return habit in working with anyone else is briefing thoroughly, and it's the one people skip because they're already busy — which is precisely the trap. You bring in help because you're overloaded, so you send a two-line instruction to save time, and the two-line instruction produces something you have to fix, which costs far more time than the proper brief would have. Rushing the brief because you're busy is the reliable way to make yourself busier.

A good brief includes what you'd need if you were receiving it cold: the goal of the work and what it's for, who the audience is, the specific deliverable and its requirements, any constraints, the deadline, and — crucially — examples of what good looks like. That last element is enormously effective and routinely omitted. Showing someone two or three examples of work that hits the standard you want communicates in seconds what paragraphs of description struggle to convey, particularly for anything with a quality or style dimension.

The subtle failure is unstated assumptions. When you've done something many times, an enormous amount of knowledge becomes invisible to you — conventions you always follow, decisions you make without noticing, standards you'd recognise instantly and have never articulated. None of that transmits automatically, and its absence is why capable people produce work that's technically fine and somehow wrong. This is the same problem as writing a vague project brief for a client engagement, with the same fix: specificity about the goal, the audience, the constraints, and what success looks like. [BACKLINK PLACEHOLDER → suggestion: internal link to article #96, how to write a project brief / the same specificity that prevents rework on client projects]

Start Small and Choose for Reliability

The sensible way to begin with anyone new is a small, well-defined, low-stakes piece of work. A contained first project tells you a great deal — how they interpret a brief, how they communicate, whether they hit dates, what their work is actually like — at a fraction of the cost of discovering those things on something that matters. Handing a critical, complex project to someone unproven is where most delegation disasters originate, and it's entirely avoidable.

When choosing who to work with, weight reliability heavily alongside skill. The most talented freelancer who misses deadlines and goes quiet for days will cost you more in management and anxiety than a solidly competent one who does what they said, when they said. You're not just buying output; you're buying the removal of something from your plate, and that only happens if you can trust the work will arrive without supervision. Dependability is what makes delegation actually reduce your load rather than convert it into a different kind of work. [BACKLINK PLACEHOLDER → suggestion: internal link to article #97, why clients rehire the reliable, not the talented / dependability is worth more than brilliance in ongoing relationships]

Evaluate the same way a good client would evaluate you: look at actual work, ask about relevant experience specifically, and pay attention to how they communicate during the hiring conversation, since that's a direct sample of what working with them will be like. Someone who asks good questions about your brief before starting is showing you something valuable — it usually predicts fewer surprises later, because they're checking their understanding rather than assuming it. [BACKLINK PLACEHOLDER → suggestion: internal link to article #77, why the most impressive candidate is the wrong hire / evaluate real work and how someone actually communicates]

Give Context, Set Expectations, Review Properly

Beyond the specific instruction, give people the context around it: what the client is trying to achieve, who the work is for, why it matters, how it fits into the larger thing. People given only tasks execute tasks literally; people given understanding make sensible decisions in the situations your brief didn't anticipate — and there are always situations your brief didn't anticipate. Context is what converts someone following instructions into someone solving the problem, which is the difference between help that reduces your load and help that returns every ambiguity to you.

Set the working expectations explicitly, too — how you'll communicate, what response times look like, when they should flag problems, how feedback will work, and what happens if something slips. Most friction in these relationships comes from unstated norms rather than from anyone behaving badly, and stating them takes minutes. Being clear that you want to hear about problems early rather than at the deadline is particularly worth saying, since people often hide difficulties hoping to resolve them, and early warning is what lets you actually manage the situation.

Then review the first work carefully and give specific feedback, because this is where the relationship becomes efficient or stays expensive. Vague reactions produce guessing, exactly as they do when clients give them to you — so name what worked, what didn't, and what specifically to do differently. Feedback that's precise and delivered early compounds fast: someone told clearly what to change on their first piece often needs almost no correction by the third, whereas someone left to infer your preferences will keep missing indefinitely. [BACKLINK PLACEHOLDER → suggestion: internal link to article #94, how to handle client revisions / specific feedback converges, vague feedback spirals]

Accept the Cost Curve and Build the System

Delegation is a slow investment that pays off later, and understanding the shape of that curve is what stops people quitting halfway. The first project takes longer than doing it yourself, because you're briefing, reviewing, correcting, and explaining. The second is somewhat better. By the fifth, with the same person, most of the explanation is unnecessary — they know your standards, your clients, and your conventions — and the work arrives largely finished. The return on the initial cost arrives entirely in that later period, which is why quitting after a disappointing first attempt guarantees you never see it.

This also argues strongly for continuity. The investment you make in briefing someone is specific to that person, so cycling through different freelancers means paying the expensive first-project cost repeatedly and never reaching the efficient stage. Finding a few people who work well and building long relationships with them is far more valuable than always taking whoever's cheapest or most available, because the accumulated shared understanding is the entire point.

Meanwhile, capture what you explain. Every time you brief someone, you're articulating knowledge that currently lives only in your head, and writing it down converts a repeated explanation into a document you send once. Over time this becomes real process documentation — how your work gets done, what your standards are, what the conventions are — and it's what makes each new person faster to bring up to speed than the last. It's also the concrete mechanism by which a business stops being dependent on one person doing everything, which is otherwise a permanent ceiling. [BACKLINK PLACEHOLDER → suggestion: internal link to article #63, you're the bottleneck in your own business / documenting what only you know is how the bottleneck opens]