Every small business owner has been told to delegate more. Most of them have tried. The usual result is that the work goes across, comes back not quite right, and gets quietly reabsorbed, with a new conviction that it is faster to do it yourself.

It is faster to do it yourself, this week. It is also why the business cannot grow past the number of hours you personally have.

The good news is that bad delegation is rarely about the person you handed the work to. It is almost always about the handover: what went across, what did not, and what happened in the first fortnight afterwards. That part is learnable, and this guide is about it.

Step 1: decide what only you can do

Start with a week of your real work. Not a list of your responsibilities, the actual tasks: every call, email, order, invoice, fix and decision. Write them down as you go, or look back through your calendar and sent mail.

Then sort each one into 3 piles.

The middle pile is your delegation list.

Step 2: hand over the good work, not just the bad

The natural instinct is to delegate what you dislike. The problem is that a role built entirely from the owner's least favourite tasks is a role nobody stays in, and it teaches the team that "delegated" means "unwanted".

Look through the middle pile for things you are good at and someone else could learn: pricing a quote, handling a difficult customer, choosing the next supplier. Handing over one of those does 2 things at once. It frees you from something that takes real time, and it tells the person you trust their judgement.

Step 3: delegate the outcome, with the context and the authority

This is the step that decides whether the work comes back right.

A task handed over as an instruction, "send the Friday invoices", tends to come back as exactly that and nothing more. The same task handed over as an outcome comes back better, because the person can make the small decisions you would have made.

Every handover should carry 4 things.

  1. The outcome. What done looks like. "Every client with completed work this week has an invoice by Friday at 5, and anything more than 30 days unpaid is chased."
  2. Why it matters. "Cash is tight in the quarter before the busy season, and late invoices are the main reason."
  3. What they can decide. "You can agree a payment plan up to 60 days without asking me. Anything longer, check first."
  4. When you will check in. "Let's look at it together for the first 2 Fridays, then I'll leave it with you."

The third item is the one owners leave out, and it is the one that causes most of the trouble. Somebody who does not know what they are allowed to decide either checks in constantly or guesses. Both look like a reason to take the work back.

Step 4: write it down where the work lives

A handover that exists only as a conversation lasts about a week. After that, both of you remember it slightly differently.

Put it on the task. The outcome, the why, the limits and the check-in date go in the task's description, and the task is assigned to the person with a date on it. If it is recurring, make it a routine rather than a one-off, so there is a record of how often it actually happens.

That record matters more than it sounds. "I think the invoices have been slipping" is a feeling, and acting on a feeling feels like micromanaging. "The invoicing has happened 5 Fridays out of 6" is a fact, and it is an easy, neutral conversation to have.

Step 5: let them do it differently

This is where most delegation quietly fails. The person does the work, the outcome is fine, but they did it in a different order, used a different template or phrased the email in a way you would not. And you fix it.

Every time you do, you teach them that the real brief was "do it exactly as I would", which is not delegation. It is supervision with extra steps.

The rule is simple: if the outcome is right, the method is theirs. Correct outcomes, not methods. If a method is genuinely causing a problem, say what the problem is and let them find a different way.

Step 6: do not take it back

At some point the delegated work will go wrong, because work goes wrong. The client will get the wrong invoice, or the order will be short.

Your instinct will be to take it back. Resist it. Treat it as you would if you had made the mistake yourself: work out what happened, adjust the brief if the brief was the problem, and hand it straight back. Taking work back after a single mistake tells everyone on the team that delegation is provisional, and they will stop investing in anything you hand over.

The only good reason to take work back is that the role itself was wrong. That is a conversation about the role, not about the task.

A simple way to run this in a shared workspace

Delegation needs 3 things from whatever system the team uses: a task that can carry a proper brief, an owner and a date on it, and a way to see recurring work over time.

In an EvyOS shared workspace, a task can be assigned to a member with a due date, a priority, a description holding the brief and comments for the check-ins. Recurring responsibilities can be routines with their own record for each person, so you can see how often the work happens without asking. And the goal the work serves sits above it, so the person you hand it to can see why it matters without being told twice.

If you want a structure to start from, the delegate properly template installs a short plan for exactly this: working out what only you can do, handing the rest over with the context, and a rule about not taking it back. The Teams templates include onboarding a hire and running one-on-ones, which are the natural next steps.

The short version

Decide what only you can do. Hand over good work as well as dull work. Delegate the outcome with the why, the limits and a check-in date, and write it down where the work lives. Then let them do it their way, and do not take it back after the first mistake.

The first few handovers will feel slower than doing it yourself. By the third month they are the reason you have time to think.

Set up a workspace for your team, or see how EvyOS works for teams.