Delegation: saying what done looks like before work starts
The missing step between 'please handle this' and disappointment two days later: outcome, constraints, check-ins, and what authority they actually have.
· 5 min read
The missing step between handing over and disappointment
The common failure of delegation is not that the wrong person was chosen or that they did not try. It is that the handover consisted of a task name and nothing else. 'Can you handle the supplier quotes' transfers a topic, not a piece of work, and the person receiving it has to invent the rest: what counts as finished, how many suppliers, by when, what to do if one of them asks for a commitment, whether price or delivery time matters more.
They will invent those answers, because they have to in order to start. Two days later the work arrives built on a different set of assumptions from yours, and the natural reading is that they did it wrong. In almost every case they did the job they were actually given, which was a job with the specification missing. This matters because the diagnosis determines the fix. If you conclude the person cannot be trusted with this kind of work, you delegate less next time and the problem compounds. If you conclude the handover was underspecified, the fix is a conversation that takes about ten minutes.
The outcome: what done actually looks like
Start by describing the finished thing rather than the activity. 'Research suppliers' is an activity and could run forever. 'A one-page comparison of three suppliers with price, lead time and minimum order, so we can choose on Friday' is an outcome, and it is checkable by both of you.
The detail that does most of the work is naming the form the output takes and who it is for. A comparison built for you to skim before a decision looks nothing like one built to send to a client, and neither is obvious from the phrase 'compare suppliers'. Where you can, say what you expect to do with it — 'I'll use this to pick one and then negotiate' tells them the price detail matters and the polish does not, which is a judgement they cannot reach on their own. If you genuinely do not know what done looks like, that is worth admitting out loud, because it changes the task into an exploratory one with a different success condition: 'spend two hours and come back with what you found and what you think the options are'.
Constraints: budget, time, and who they may talk to
Constraints are the part most often left out, because they are obvious to the person who has been holding the task and invisible to the person picking it up. The budget available. The deadline, and whether it is a real deadline or a preference. Whether they can spend money, and up to what. Who they may approach — and specifically whether they can contact a client, a supplier or a senior colleague directly, which is the constraint most likely to cause genuine embarrassment if left unstated.
There are usually one or two that are not obvious at all and cause the most damage when discovered late: a supplier you are already in a dispute with, a client who must not be told about a change yet, a colleague who should hear about this from you rather than from a query. These are political rather than practical constraints, they are entirely invisible from the outside, and they are the ones worth stating explicitly even when it feels like over-briefing. Someone who blunders into one of these has not made a mistake; they were sent into a room without being told who was in it.
Check-in points, not surprise inspections
An agreed check-in is the difference between catching a wrong turn early and discovering it when the work is finished. The framing matters, though: a check-in set up in advance as part of the plan is a normal part of the work, whereas an unscheduled 'how's it going' arriving on day two reads as a lack of confidence, and often is one.
The most useful check-in is early and small — a conversation after the first fraction of the work, when the approach is visible but little has been invested in it. For a week-long task, that is a short conversation the first morning, where they say how they intend to go about it and you get to say 'that's right' or 'not that way' at the point where changing course costs nothing. Late check-ins are much weaker, because by then correcting the approach means discarding real work, and both of you will feel the pull to accept something not quite right rather than waste it. Agree the points at handover and then leave the space between them alone, which is the half of the arrangement that actually builds trust.
Authority: what they can decide without asking
The clearest way to state authority is by naming the decisions rather than describing a general level of seniority. Can they commit to a price? Change a delivery date? Tell a client no? Approve an expense, and up to what amount? Most delegation is vague here, which produces one of two predictable failures: someone escalates every small decision to you, which is slower than doing it yourself, or someone commits to something you would not have agreed to, which is worse.
A useful shape is three explicit bands: decisions they make and simply tell you about afterwards, decisions they check with you before making, and decisions that are not theirs at all. That takes about a minute to say and removes the guesswork entirely. It is also worth saying what happens when something falls outside all three, because it will — the honest instruction is that unfamiliar situations come to you rather than being resolved on judgement, and that doing so is not a failure. Someone who has been told they should be able to handle things will guess rather than ask, and the guess is where the real cost sits.
Why 'use your judgment' without context is not delegation
'Use your judgment' is a reasonable instruction to somebody who has the context to exercise judgement with, and an abdication to somebody who does not. Judgement is not a general trait; it is the ability to weigh a specific set of trade-offs, which requires knowing what the trade-offs are. Somebody who does not know that this client is unusually price-sensitive, or that the deadline is soft but the budget is not, cannot exercise judgement about it however capable they are.
So the phrase is best used with the trade-off attached: 'use your judgment, and if it comes down to price against delivery time, protect the delivery time' is genuine delegation, because it hands over the decision and supplies the basis for making it. Delegation done this way costs about ten minutes at the start and is the only version that gets cheaper over time — each handover in an area you have briefed before needs less, because the context accumulates in the person rather than being re-supplied each time. Skipping the ten minutes is what makes delegation feel permanently more expensive than doing the work yourself.
Common questions
Is it faster to just do the task myself?
For a one-off task, often yes, and pretending otherwise is how delegation gets a bad reputation. The calculation changes for anything recurring, because the briefing cost is paid once while the time saved repeats. If a task genuinely occurs only once and takes less time than explaining it, doing it yourself is the correct answer rather than a failure of nerve.
How do I delegate without seeming like I am dumping work?
Say why this person, and say what happens to the output. Work that arrives with no explanation reads as offloading; the same work framed as 'this needs doing properly and it feeds into the pricing decision on Friday' reads as responsibility. The difference is whether they can see where their work goes.
What if the work comes back wrong despite a clear brief?
Establish which part of the brief was misread before deciding anything about the person. Ask how they interpreted the goal — often a specific sentence was ambiguous in a way that was invisible to you and obvious to them. If the brief genuinely was clear and the work still missed, that is useful information, but it is only useful once you have ruled out the cheaper explanation.
Should I delegate a task I have never done myself?
You can, but you cannot specify it as tightly, and the honest move is to say so. Frame it as figuring out the approach together rather than delivering to a standard you have not defined, and expect the first check-in to be about method rather than progress. Pretending to a specification you do not have is what produces work that fails against a standard nobody stated.
Related pages