How to Delegate Tasks: To People and to AI Assistants

To delegate a task, hand over an outcome rather than a list of steps, say how much authority goes with it, and agree up front how and when you will check. In practice that is five things written down: the outcome, the context the other person cannot see, the limits, what done looks like, and when you will next talk. Most delegation that goes wrong fails on one of two points: the level of authority was never said out loud, or the person delegating took the work back at the first wobble. The same handover works for an AI assistant, with one addition: a plain list of what it must not do.

What to delegate, and what to keep

A useful test from the Society for Human Resource Management’s article on delegating to develop employees↗ (opens in a new tab): “Real delegation is assigning responsibility for outcomes along with the authority to do what is needed to produce the desired results.” If you cannot give the authority, you are not delegating; you are asking for help. That is fine, but call it that.

• Delegate work that repeats: the weekly report, the vendor renewal, triaging new bug reports. Once someone else owns it, it stays off your list.
• Delegate work someone else can do as well as you, or better. Your time is the scarcest resource on a small team, and the person closest to the detail often has the better answer.
• Delegate work that stretches someone. The human resources office at Grand Valley State University↗ (opens in a new tab) puts it as “assigning tasks based on team members’ strengths and development needs.” A task a little beyond someone is how they grow.
• Delegate what is urgent but not important to you. That is the third box of the Eisenhower matrix.

Keep the work that only you should do: hiring decisions and performance reviews, anything involving someone’s confidential information, and decisions that are hard to reverse, which the decision-making framework post calls one-way doors. Keep, too, the explaining of why the work matters. You can hand over the task; you cannot hand over the reason for it.

Four levels of delegation

The same task can be handed over at very different levels of authority. Say which one you mean, every time. The most common source of friction is a person who thought they could decide handing work back to a manager who expected to be asked first, or the reverse.

1. Do exactly this. The steps are known and the person follows them. Use it for new people, risky work and anything with a compliance rule. Check-in: at the end.
2. Research and recommend. Find the options, compare them and say which you would pick and why. You decide. Use it when the call is yours but the legwork is not. Check-in: when the recommendation is ready.
3. Decide and tell me. The person makes the call and lets you know what they chose, so you are never surprised. Use it for most day-to-day work with someone you trust. Check-in: a short note after each decision.
4. Own it. The outcome is theirs, including how it is done and whether it is still worth doing. You hear at the agreed milestones, or when something is off track. Check-in: at milestones only.

Levels are not fixed to a person. The same colleague can own the release notes and be at level two on pricing. Move someone up a level when the last few handovers went well, and say that you are doing it.

A handover template

Write the handover down, even for a colleague sitting next to you. A written handover is something both of you can point at later. The Office of Personnel Management’s guidance on performance planning↗ (opens in a new tab) makes the case for involving people in planning: it “helps them understand the goals of the organization, what needs to be done, why it needs to be done, and how well it should be done.” The template covers those four and adds the level.

Outcome:    [the end state, in one sentence]
Why:        [who needs it and what it is for]
Context:    [what you know that they cannot see; what was tried]
Level:      [do exactly this / recommend / decide and tell me / own it]
Limits:     [budget, what not to change, who not to contact]
Done when:  [2-5 statements someone else could check]
Check-in:   [when, and in what form: a message, a call, a comment]
Stuck?      [who to ask, and when to stop and ask]

Outcome:    The hosting contract is renewed before it lapses on the 15th.
Why:        If it lapses, the customer site goes down.
Context:    Last year we paid monthly. The provider offered an annual
            discount in their email of August 28 (forwarded).
Level:      Decide and tell me.
Limits:     Stay within this year's budget line. No new provider.
Done when:  - Renewal confirmed in writing
            - The invoice is in the finance folder
            - The renewal date is on the team calendar for next year
Check-in:   A message when it is signed. Call me only if the price
            goes over budget.
Stuck?      Ask Dana in finance about the budget line.

Notice what is missing: the steps. At level three the person picks the steps. If you find yourself writing them, either the task belongs at level one or you are not ready to let go of it.

Delegating to an AI assistant

An AI assistant takes the same handover, split across two places. The outcome, why, context and done-when are the problem, written once. The approach, once it is known, is the plan, which the assistant can write first so you can catch a wrong turn before anything changes. How to scope a single card so an agent can finish it is covered in detail in giving an AI agent a task it can finish; this section is about the delegation around it.

The level needs more care with an assistant than with a person. Research and recommend suits it very well. Do exactly this suits it when the plan is written. Decide and tell me should be limited to reversible, low-stakes choices. Own it is not a level to give an assistant: it will not notice that a task has stopped being worth doing, and it cannot answer for the result the way a person does. Anthropic’s guide to building effective agents↗ (opens in a new tab) describes the pattern to aim for: agents “can then pause for human feedback at checkpoints or when encountering blockers.”

Then add the list a colleague would not need, because an assistant takes the shortest path to done unless told otherwise:

• Do not deploy, publish, send email or spend money.
• Do not change tests or checks to make them pass.
• Do not touch anything outside the named area; file a new task instead.
• Do not decide questions of behavior, wording, price or policy; ask one specific question and stop.
• Do not mark the work tested unless you ran the check.

Written limits are a request. Where the tool allows it, back the important ones with settings the assistant cannot talk its way past. In Claude Code, for example, permission rules↗ (opens in a new tab) “are evaluated in order: deny, then ask, then allow,” so a deny rule on deploy commands holds whatever the instructions say.

Delegating on a fenbs board

On fenbs the handover lives on the task. The Problem box holds the outcome, why, context and done-when; the Plan box holds how it will be done and is rewritten as the work teaches you something. fenbs has no assignee field, so when you delegate to a person, name them in the first line of the note, and History records who filed and moved each task.

For an AI assistant there is a direct equivalent of do exactly this. On a task with a plan, a person with All Access presses “Let AI do this” and can add a limits line such as “web only, no API change.” Any connected assistant can then take it with fenbs_next_approved_task, work to the plan inside the limits, fill in Testing and move it to Completed, or give it back with a reason. If the title, problem or plan changes after approval, no assistant takes it until a person approves it again. Standing limits that apply to every task, such as “never deploy on a Friday,” go on the Decisions and rules page as rules, which every connected assistant reads first.

Checking the work without taking it back

The same SHRM article has the line to remember: “You are delegating, not abdicating.” Checking is part of delegating. Taking the work back is not.

• Check against the done-when you agreed, not against how you would have done it. A different route to the same result is a result.
• Ask before you fix. “How did you handle the annual discount?” teaches more than a silent correction and keeps the owner in charge.
• Hand problems back with specifics: which done-when statement is not met, and what you saw. Then let the person fix it.
• Keep check-ins to the schedule you set. Unplanned checking reads as distrust, and it drags the level down without anyone saying so.
• For an assistant, ask for evidence you can read in a minute. On fenbs, Testing records Tested, Partly tested, Failed or Needs owner check, and a task an assistant finishes from the pre-approved queue says “AI done · check it” until a person presses “I’ve checked it.”

If you take a task back, say so, say why, and treat it as information about the level rather than the person. Usually the fix is a lower level next time, or a clearer done-when, not doing it yourself forever.