What delegation is, and what it is not
Delegation means giving someone else responsibility for an outcome, along with enough authority to achieve it. That is different from simply dumping tasks, and different from assigning steps that you still control in detail. A delegated task has an owner who decides how to do the work within agreed limits.
People who are good engineers often find delegation hard. They know how they would do the work, can often do it faster themselves, and worry about quality. These feelings are understandable, but a team where one person does everything has a ceiling on what it can achieve, and colleagues miss the chance to grow. Delegating technical work well is a skill that can be practised.
Decide what to delegate
Not every task is a good candidate. A few questions help:
- Is it something only I can do? If a task needs your particular authority or knowledge, keep it, or plan how to transfer that knowledge.
- Is it a good learning opportunity? A task slightly beyond someone’s current experience can help them grow, if support is available.
- What happens if it goes wrong? Tasks with serious consequences for safety, cost or customers need closer oversight and sometimes a qualified reviewer, whoever carries them out.
- Is there time? Handing a new task to someone just before a deadline gives little room to learn.
Tasks with low risk and clear boundaries are usually the best way to start building trust in both directions.
Match the work to the person
Look at the person’s skills, current workload and interest. Someone experienced in a subject can work independently with a short brief. Someone newer to it may need a more detailed outline, an example to follow, or a colleague to ask. Matching does not mean always giving people the work they already know; a mix of familiar and stretching tasks tends to work better than either alone.
Be honest about workload too. Giving a task to the person who never says no leads to overload. Ask whether they have capacity and what would need to move if they accept.
Give context, not only instructions
A task description such as “update the config loader” leaves out the most useful parts. People do better work when they know:
- Why the task matters and who uses the result.
- What constraints apply, such as deadlines, compatibility needs, performance limits or safety rules.
- What is already known, including earlier attempts and dead ends.
- Who to ask for questions about the surrounding system.
Context lets the person make sensible choices when the unexpected happens, which it will. Instructions without reasons force them to guess or come back with every question.
Define what done looks like
Many delegation failures are really disagreements about completion. One person thinks “done” means the code works on their machine; the other expected tests, documentation and a review. Before work starts, agree on what finished means. For example:
- the behaviour or output expected,
- tests or checks that must pass,
- documentation or notes that should be updated,
- who reviews the result and when,
- the date by which an update or a result is needed.
Writing these down as acceptance criteria avoids guesswork and gives the owner a clear target. If the task is exploratory, say so, and define done as a recommendation or a short report rather than a finished solution. Be clear too about the decisions the owner can make alone and those they should check with you first.
Check in without micromanaging
Handing over a task does not mean disappearing. The aim is to stay informed at a level that fits the risk and the person’s experience. Some approaches:
- Agree checkpoints at the start. For example, a quick look at the approach before the work begins, and a progress conversation partway through a longer task.
- Ask open questions. “What is the hardest part so far?” invites more information than “Is it going OK?”.
- Look at outcomes, not activity. Counting hours or watching every commit tends to signal distrust.
- Be reachable. Make it easy to ask for help early, before a small problem becomes a large one.
- Resist taking the task back. If you see something done differently, ask about the reasoning before correcting it. If the result is workable, accept it even if you would have chosen another path.
Micromanagement usually shows up as frequent unrequested checks, rewriting work that was acceptable, or deciding details that belong to the owner. If you notice yourself doing these, ask whether the cause is a lack of trust, unclear expectations or personal anxiety, and address that directly.
When things go wrong
Sometimes a delegated task goes badly. Start by looking at the setup: was the brief clear, did the person have the information and time, were the checkpoints useful? Then talk about what happened in a spirit of learning, using the principles of constructive feedback. If the result is not good enough, agree on concrete steps to fix it. Responsibility for the outcome still partly rests with the person who delegated.
Avoid reacting to one failure by never delegating that kind of work again. Instead, adjust the support, shrink the scope, or add a checkpoint.
Recognise the work
Credit people for what they accomplish, publicly where appropriate. Delegated work that is quietly absorbed into the delegator’s own record discourages people from taking it on. Acknowledging contributions also helps colleagues build a record they can use later, for example in a portfolio of their own work.
A short checklist
Before handing off a task, try to answer these in a couple of sentences:
- Why does this task matter?
- What does done look like?
- What can the owner decide alone?
- When will we next talk about it?
- Who can they ask for help?
Teams, risks and responsibilities differ across organisations and industries, so adapt these ideas to your own situation and follow any rules that apply to safety-related or regulated work.