Delegation as the business grows: what to let go first

The practical question is not 'can someone else do this as well as me?' For most tasks an owner has done for years, the honest answer is no, and waiting for yes means never delegating anything. The question is whether someone else can do it 80% as well, and whether the 20% gap costs less than what you would do with the hours.

Stated that way it sounds like an easy trade, and in practice it is not, because the gap is visible and specific while the freed time is abstract. You will see the slightly clumsier email to the customer. You will not see, in the same concrete way, the pricing review you finally had time to do. This asymmetry is why owners who intellectually accept delegation still take tasks back.

It helps to decide in advance what the freed hours are for, and to name it. 'Someone else handles dispatch so I can spend Tuesday mornings on supplier terms' survives the first clumsy dispatch. 'Someone else handles dispatch so I have more time' does not, because when the clumsy dispatch happens there is nothing on the other side of the scale.

Some things genuinely stay with the owner, and being clear about which ones prevents both halves of the usual mistake — hoarding everything, or handing over something that cannot actually be handed over.

The reliable test is whether the decision changes what the business is rather than how it runs. Pricing strategy, which customers or segments to pursue, whether to take on debt, who to hire and who to let go, and anything that commits the business past the point where it could reasonably change its mind. These are not held back because nobody else is capable. They are held back because the consequences land on the owner regardless of who made the call, and authority without consequence is an unstable arrangement.

Everything else is a candidate, including things that feel identity-defining. Plenty of owners hold onto the work they are personally best at long after it has become the least valuable use of their day, because being good at it is part of how they think about themselves. That is a real cost and worth naming honestly, but it is a different reason from 'nobody else can do this', and confusing the two keeps a business small on purpose without anyone deciding to.

The most common broken handover gives someone responsibility for a result while keeping every decision needed to produce it. Someone owns customer satisfaction but cannot issue a refund. Someone owns the schedule but cannot say no to a request. Someone owns purchasing but needs approval for every order.

This is worse than not delegating, and not only because it fails. It teaches the person that ownership here is nominal, which is a lesson they carry into the next thing you try to hand them. It also produces exactly the evidence that justifies taking the task back: they did not handle it well, because they could not.

So the handover has to include the decisions, and the honest way to bound them is by limit rather than by category. 'You can issue refunds up to this amount without asking' is workable. 'Use your judgement, but check with me on the important ones' is not, because the person cannot tell which are important until after they have guessed wrong. A written limit also gives them somewhere to stand when a customer pushes, which is worth more than the latitude itself.

Explaining a task you know well is unexpectedly hard, because the parts that took you longest to learn are now the parts you do not notice doing. You will describe the sequence accurately and omit the judgement, and the judgement is most of it.

The method that works is deliberately slow and takes about four passes. They watch you do it and take their own notes. You do it while they ask questions. They do it while you watch and stay quiet unless something is about to become expensive. They do it alone and you review the output rather than the process. The temptation is to compress this into one demonstration and a document, which reliably produces someone who can handle the standard case and stalls on the first exception.

One detail matters more than it looks: have them write the procedure, not you. They are the only person in the building who can still see which steps are not obvious, and that vantage point disappears within about a month. The document they produce will be better than yours, and writing it is also how they find out what they have not understood yet.

Once someone owns a task, they change it. They will reorder steps, drop something you thought was essential, and add a check you never bothered with. The instinct to correct all of this is strong and mostly counterproductive.

The distinction worth holding is between different and worse. Different means the outcome is met by another route, which is what ownership actually looks like and often surfaces improvements — the person doing a task daily sees waste the person doing it occasionally never noticed. Worse means the outcome is not met, or a risk you were carrying deliberately is now uncovered. Only the second one needs intervention, and it needs it quickly and specifically: name the outcome that is not being met, not the step that changed.

This is also where a documented process earns its keep. If the reason a step exists is written down — this check exists because of the compliance deadline, this call happens because this supplier does not read email — then someone can change the process intelligently. Without that, every deviation looks equally arbitrary, and the owner ends up either policing steps or ignoring drift, both of which are worse than the alternative.

It does not reduce total work in the short term. Training someone costs more hours than doing the task yourself for the first month or two, sometimes three, and businesses that delegate during a crunch usually conclude that delegation does not work. It works; it just has to be paid for before it pays out, which means starting when things are merely busy rather than when they are on fire.

It does not survive an unclear standard. If you have never articulated what good looks like for this task, the person cannot hit it and you cannot fairly tell them they missed. A lot of what feels like a capability problem in a new owner of a task is an unstated standard, and the quickest diagnostic is to try writing the standard down. If you struggle, they were never going to guess it.

And it does not transfer the outcome. You can hand over the work, the decisions and the accountability for doing it well, and if it goes badly the consequence still arrives at your door. That is not an argument for keeping everything. It is an argument for staying close enough to notice early — reviewing outputs, not hovering over steps — which is a genuinely different activity from doing the task yourself.