1. What delegating is, and what it is not
Handing over work is more than passing on a task. As soon as you delegate, you also give away room to act, while the outcome still sits on your plate. That combination makes delegating difficult and powerful at the same time. This chapter draws the line: what exactly is delegating, and when are you in fact doing something else?
After this chapter:
- Can you explain in your own words what delegating is, and how it differs from giving an instruction or dumping work.
- Do you know the three elements you hand over: the task, the authority and the resources.
- Do you know which five kinds of resources and which four preconditions you set out in advance.
- Do you know the difference between responsibility for execution and ultimate responsibility, and what that means when something goes wrong.
- Recognise the moment when a delegated task quietly wanders back to your desk.
Task, authority and resources
Delegation means deploying someone else to achieve your results. You entrust a task to another person, together with the authority and the resources that go with it. What you keep yourself is the ultimate responsibility for the result. Those three words contain the whole definition: task, authority, resources. Take one away and you are left with something other than delegation.
With the task we mean the work itself plus the result you want to see in return. So do not stop at "send out the customer survey". You also say when you want it finished and what the outcome will be used for. With the authority we mean the room to act and decide for oneself. Without that room your colleague has to come back to you for every step, and you are still the one steering the work. And the resources are everything needed to carry out the work: a budget, a number of hours, access to a system, the right information and sometimes the help of a third colleague.
Resources are the element most often forgotten. Your colleague is given the task and the freedom, but the hours are not added and the budget stays vague. In that case you are really handing over a problem rather than work.
Giving an instruction, delegating and dumping
A lot of work that is called handing over turns out, on closer inspection, to be something else. On the surface the three forms look alike: work moves from your desk to someone else's. The difference lies in what goes with it.
At giving an instruction only the task is handed over. If you say "could you enter these twenty invoices the way I've just shown you", you are giving an instruction. The other person carries it out, you keep every decision in your own hands. That is perfectly good work, but it does not develop anyone and it hardly saves you any thinking. With delegation the task, the authority and the resources all three go with it, and you agree on how you will measure the result. With dumping you pass on something you do not feel like doing yourself: without explanation, without room and without resources. Your colleague senses that difference unerringly, even if you do not say it. The message gets through anyway, via your tone and your attitude.
Two conversations about the same task, the monthly progress report for the board.
Version A: "Could you just put the overview together this month? The format is in the folder, simply enter the figures, and send it to me before it goes out."
Version B: "I want to hand the progress report over to you, starting this month. You decide which figures go into it and how you structure it, as long as the board can see at a glance where we are falling behind. You may ask the team leaders for input yourself. Allow four hours a month. You can bring any questions to me, but you circulate it yourself."
In variant A you remain the owner and your colleague works as an extension of your hands. In variant B the task genuinely sits with him, with room to decide and with hours to go with it. The result may differ from what you would have produced.
Five kinds of resources
Authority without resources produces a colleague who is allowed to decide but cannot do anything. He may approach the supplier, but has no access to the contract. He may rewrite the script, but has not a single hour free in his week for it. These five categories come up almost every time.
- Time: a number of hours per week or a total for the job. Name the figure, and agree which other work gives way for it or goes to someone else.
- Budget: the amount he may spend without consulting you, and the limit above which he comes back to you. Without a figure, every expense turns into a question for you.
- Information: background, earlier agreements, minutes, figures, the names of the people who worked on it before. This is where it most often goes wrong, because you have the context in your head and he does not.
- Access: rights in systems, a place at the meeting, the shared folder, the mailbox, the key to the archive.
- Help: a colleague's hours, support from the office staff, or your own availability for questions.
In addition, there are four preconditions you nail down in advance. The deadline: a date, not "soon". The quality requirement: how will you know the result is good? Describe the end product as you picture it. The hard limits: what is absolutely not allowed, and what is not negotiable. And the feedback moments: when do you hear how things are going, and about what. You agree that last part in advance, so that checking does not become an intrusion but an appointment in the diary.
Ilse hands the supplier overview over to Bram. She says: "You get four hours a week for this, until 1 June. Last year's purchasing file is in the Purchasing folder, and I will add you to the system. Up to 2.500 euro you decide yourself, above that you call me. One thing is not negotiable: we do not switch to a supplier without an ISO certificate. We will speak for fifteen minutes every Friday."
Bram now knows what he has to deliver, what he is allowed to do, what he has at his disposal and when he reports back. Four questions that would otherwise all four have come back to Ilse.
Go through the resources by mentally carrying out the task once yourself. At every step where you think "then I'll just grab the file" or "then I'll email Jasper", you have found something your colleague does not automatically have.
The execution goes, the ultimate responsibility stays
Delegating splits responsibility into two parts. Your colleague is responsible for the execution: he does the work, makes the choices within the agreed framework and reports back to you. You remain ultimately responsible for the result towards your own management, towards the outside world and towards the rest of the team. Those two do not run in step, and that feels uncomfortable: you are judged on work that someone else does.
The distinction only becomes really tangible when something goes wrong. A wrong figure in the overview, a client who pulls out, a deadline that shifts: people come knocking at your door. At that moment you take the hit and stand behind your employee, even if you have a firm conversation with him in private. Anyone who drops their employee in public will find that no one follows them afterwards. So outwardly you defend the approach and the outcome, and internally you discuss what went wrong. You keep those two conversations separate.
Being ultimately responsible also means you keep watching. Not over your colleague's shoulder, but at the process: is it on schedule, do the assumptions hold, are the resources sufficient, has anything changed around the task? If the task threatens to go off the rails, correcting course is your job. Waiting until the deadline and then being surprised is not.
The task that wanders back
A delegated task has a tendency to come back. Your colleague drops by with "just a quick question", you think along with him, and by the end of the conversation you are the one sorting it out. Three of those moments and the task is back on your desk, while formally it belongs to him.
You break the pattern by putting every question back: "What would you do?" and "What do you need from me to carry on by yourself?" You help with the decision, not with the execution. Only if the resources or the authority genuinely turn out to be insufficient do you adjust the arrangement, and then you say so out loud: this is new, we will agree on it again.
Choose a task you have handed over to someone in recent months, and work through the elements:
- The task: which result had you agreed? Did your colleague know that precisely as well?
- The authority: what was he allowed to decide himself, and what did he have to come back to you for?
- The resources: how many hours, what budget, what information and what access have you handed over?
- Your conclusion: was this delegating, giving an instruction or dumping?
- Drift back: at what point did part of the task effectively return to you?
Finally, note in one sentence which element you will arrange better next time.
Summary
- Delegation consists of three parts, all three of which you hand over: the task, the accompanying authority and the resources.
- If the room to decide is missing, you are giving an instruction. If the resources and the explanation are missing too, you are dumping work.
- The five resources are time, budget, information, access and help.
- The four preconditions are the deadline, the quality requirement, the hard limits and the feedback moments.
- The execution goes to your colleague, the ultimate responsibility stays with you: you steer, keep an overview and stand behind the result externally.
- Watch for tasks that come back to you step by step. Put every question back with "what would you do?"
Which three things do you hand over when you delegate a task?
You ask a colleague to enter twenty invoices exactly as you have just demonstrated, and you check them yourself afterwards. What are you doing?
A task you have delegated goes wrong and your director takes you to task over it. According to this chapter, what does that involve?