Delegating with AI: assignments that don't boomerang back

Delegation doesn't fail because people don't want to work. It fails on the assignment. A manager says on the way out the door, “take a look at that proposal for the client,” heads off to the next meeting, and two days later gets back something they have to redo. The second time they spell it out in more detail, the third time they'd rather just do it themselves — and close the loop: an overloaded person who doesn't delegate because “it's faster to just do it myself anyway.” It's faster exactly once. Not the tenth time.

Handing off work is an act of translation: everything you have in your head as full context has to get converted into words the other person can correctly fill in the gaps around. Most bad assignments aren't imprecise — they're incomplete, and it's always the same four things missing: why it's being done, what exactly should result, where the boundaries are, and what to do if something goes wrong. AI is useful for this translation from two directions. It can turn your one sentence into a structured assignment and ask what's missing. And, most importantly, it can read the assignment through the eyes of someone who doesn't have your context, and show you where they'll fill in the gap wrong.

This guide moves from a single assignment to your whole workload: the template, the clarity check, choosing a delegation level, check-ins, handling reverse-delegated tasks, and finally an audit of your own calendar. Two rules govern the whole text. A human sends the assignment — the model prepares the text, you read it, adjust it based on what you know about the person, and send it as your own. And the delegation level is a managerial decision: how much autonomy you give whom depends on the risk and the person, not on the model's recommendation. This builds on the foundation laid out in the tip delegate the outcome, not the process — this piece expands it into prompts.

A typical scenario

Jakub manages a team of eight and works sixty hours a week. He hands out assignments verbally, on the fly: “prep the materials,” “reach out to them,” “take a look at this.” The result is predictable. Roughly a third of tasks come back with a question, another third come back done but different from what he expected, and the last third comes back whole — the person hits the first obstacle, writes “not sure how to proceed,” and the ball is back in Jakub's court. In the evening he ends up finishing things he assigned that morning.

Two months later, his day looks different. He writes assignments into one five-field template, which takes about three minutes longer than before. Those three minutes pay back enormously: the task runs through a “read this like a junior, what's unclear” check, and Jakub fills in two things someone would otherwise have had to ask about. Every task says whether it's “do it,” “propose,” or “decide,” so nobody hesitates about how much autonomy they have. When a message comes in saying “I hit a wall, what now,” he has a ready way to hand the decision back without looking like he's refusing to help.

Not all the questions disappeared — and they shouldn't. What disappeared were the ones that arose because something never got said. Jakub estimates it's freed up roughly a day a week for him, and more importantly, his team now makes decisions that used to wait on him.

Phase 1: Why delegation boomerangs back

Three reasons that cover almost everything

A returned task looks different every time, but there are only three causes, and they repeat.

Missing context. The person knows what to do, but not why. The moment they hit a fork the assignment doesn't cover — and it always happens — they have nothing to decide from. Either they ask (and you both lose time), or they pick for themselves (and you've got a coin flip). Context isn't a courtesy, it's fuel for the small decisions you can't predict.

Missing description of the output. “Prep the materials” is an area, not an output. A ten-slide deck? A one-page email summary? A table of numbers? Each of those options is a different two to six hours of work. If you don't describe the output, the other person will — and their description will make sense from their vantage point, not yours.

Missing boundaries. What they can decide on their own, what they can't, how much they can spend, who they're allowed to contact, what's off-limits. Without boundaries, a person makes one of two mistakes: either they ask about everything because they don't dare act, or they take a step you didn't want — like emailing the client before you approved it. Both look like the person's mistake, and both are the assignment's mistake.

The feedback an assignment gives you

The uncomfortable part: if you can't write the assignment down, you haven't actually thought it through. Most managers find, the first time they fill in the template, that for a third of their tasks they can't say what “done” looks like. That's not a reason to ditch the template — it's exactly why you should use it. A few minutes over the assignment replaces half a day of redoing it at the end.

The second finding comes later: some of the tasks you wanted to delegate dissolve once you try to write them down. Either they're unnecessary, or they're actually a decision only you can make. That's a result too.

Phase 2: A five-field assignment template

Context, output, deadline, boundaries, escalation

Five fields that cover almost every handoff of work:

• Context: why this is being done, who will use the output, and what decision depends on it. Two to four sentences, not a paragraph.
• Output: exactly what should result — the form, the scope, who it needs to make sense to, and above all how we'll know it's done. Ideally three to five acceptance criteria.
• Deadline: a specific date and time, not “as soon as possible.” When the deadline derives from something else (a meeting, sending it to a client), say so — that tells the person whether they have any slack.
• Boundaries: what they can decide on their own, what they can't. Budget, time, who they're allowed to contact, what must not change, what's out of scope. This field grants freedom rather than restricting it: whoever knows the boundaries doesn't have to ask inside them.
• Escalation: what to do when it isn't working. When to raise a hand (not “once it's not working,” but “if it takes you more than X hours” or “if you hit Y”), and who to contact if I'm unavailable.

The last field is the one that gets left out most often, and it's the one that saves the most. Without it, a person either quietly wrestles with an obstacle for three days, or shows up at the very first snag.

I want to delegate a task. Here's what's in my head, written
the way I'd say it on the way out the door:

[paste your sentence or a few sentences]

Who's doing it: [role, experience, what similar work they've
already done].
When I need it: [deadline and why it's that specific date].

Convert this into an assignment with these five fields:
context / output and acceptance criteria / deadline /
boundaries / escalation.

Rules:
- don't make anything up; where you're missing information,
  write QUESTION FOR ME: [what you need to know] instead
- phrase acceptance criteria so they can be checked off, not
  as “handled well”
- in boundaries, list what's out of scope too, so nobody does it
- propose escalation with a concrete trigger, not “if there's
  a problem”

Write it in language I can send unchanged.
Don't send this anywhere — just give me the text back.

You'll get back an assignment, and below it a list of questions for you. That list is the most important part of the output: it usually contains three to six things you'd otherwise never have said, and that would have come back to you as a question or a redo. Answer them, have the assignment filled in, and only then send it — AI proposes and a human approves still holds here, and for an assignment that means the final read and the send are yours.

Acceptance criteria you can check off

The most commonly underrated part of an assignment. “Done” means something different to everyone, and the difference only shows up once it's too late.

Here's a task assignment I wrote:

[paste assignment]

Write acceptance criteria for it — a list I can use to
unambiguously check off that the output is done and usable.

Requirements:
- 4 to 7 items, each verifiable yes/no
- no subjective words (quality, careful, sufficient); where
  you'd use one, replace it with a measurable description
- split them into: must meet / would be nice
- at the end, add 3 things that often get overlooked for this
  type of task, and ask whether I want them added to the
  criteria

Finally, rewrite it as a short checklist I can send along
with the assignment.

A checklist attached to the assignment does two things at once: the person works against it, and you accept against it. That eliminates the worst part of handing work back — arguing about whether it's actually done.

Phase 3: Checking clarity through someone else's eyes

“Read this like a junior”

This is the single most useful prompt in this whole guide, and it takes ten seconds. You can't read your own assignment objectively, because you have everything that's missing from it already in your head. The model has no context — and that's exactly why it can find the places someone will fill in wrong.

Read this assignment as [a junior who's been at the company
3 months and has never done this type of task before].

[paste assignment]

Answer in four blocks:
1. What's unclear: specific sentences or terms I'd need to
   ask about. For each, write exactly what I'd ask.
2. Where I might fill in the gap wrong: places that allow
   two different readings — list both and say which is more
   likely.
3. What's missing from the assignment for me to be able to
   start without a single question.
4. What I'd do as the first three steps based on this
   assignment.

For point 4, describe it exactly the way I'd actually dive
into it — so I can tell whether the assignment would steer me
in the right direction.

Point 4 tends to be the best diagnostic. When the described first steps head somewhere other than you expected, it isn't the model's mistake — the assignment genuinely leads there. Fix it and run the check again; the second round usually only turns up small things.

It's useful to vary the role depending on who you're assigning to. “Read this like an experienced colleague juggling three other tasks who skims it once quickly” finds different holes than a junior does — typically the spots where the assignment can be read superficially and dispatched with the minimum effort.

Simulating the person taking it on

The second round of checking goes further: have the model retell the assignment in its own words and write out what it would actually do.

You're someone who just received this assignment. Don't
critique it. Answer the way I would if I were the one
taking it on:

[paste assignment]

1. Summarize in your own words what I'm asking for (5
   sentences).
2. Write what output I'll hand you back, and in what form.
3. List the decisions I'll have to make on my own along the
   way.
4. Write 3 questions I'll ask you before I start.
5. Estimate how long this will take me, and explain what the
   estimate is based on.

Don't add anything extra and don't improve on it. I want to
see what I actually communicated with this assignment.

Point 1 is the test in its purest form: if the retelling doesn't match what you wanted, the assignment simply doesn't say it. Point 3 shows you how many decisions you offloaded onto the person without noticing — and whether they have enough context for them. And point 5 is a preliminary estimate worth comparing against what you think the task involves; a big gap means one of you understands the assignment differently than the other.

Phase 4: The level of delegation — do it, propose, decide

Three levels are enough

Confusion about autonomy is the second most common cause of returned work. The person doesn't know whether to bring back a finished result or ask first — and either one might be wrong. The fix is to name it right in the assignment, in one word:

• Do it. The assignment is clear, the process is known, the risk is low. Bring back a finished result, don't check in along the way. Typically routine work, recurring tasks, something with a clear precedent.
• Propose. Prepare an option (or two to three) with a recommendation and reasoning; I'll make the decision. Fits when something is new, irreversible, or visible outside the company.
• Decide. Decide on your own, just let me know the result. The highest level — and the only one that actually frees up capacity for the manager, because it doesn't require them to be present.

The goal isn't to hand everyone “decide” right away. The goal is for the level to be stated, and for it to move up over time for each person — for the tasks they've already mastered. If you keep giving someone “propose” three months running and approve their proposal unchanged every time, that's a signal it's time to move the level up.

Help me choose the level of delegation for this task.

Task: [description]. Who's doing it: [role, experience, how
similar tasks turned out in the past — add what you know].
What happens if this goes badly: [impact, reversibility, who
sees it].

Go through the three levels (do it / propose / decide) and
for each, write:
- what it would mean in this specific case
- what the risk is if I choose it
- what I'd have to add to the assignment for it to work

Then tell me what I should ask myself before deciding.
Don't give me a clear-cut recommendation — choosing the level
is my decision, you just lay out the consequences for me.

The last paragraph is there deliberately. The model doesn't know the history of your relationship with this person, or the company context in which a mistake gets forgiven or doesn't. But it's good at laying out what each choice actually entails — and that's exactly the part a manager skips when moving fast.

Moving between levels is development

The levels aren't just an organizational trick — they're the cheapest development tool you have. Moving someone from “propose” to “decide” for a specific area is concrete, measurable, and the person will notice it themselves. Write a shift like that into their notebook and bring it up in a one-on-one — the how-to is in the tip one-on-one with AI. The sentence “starting today, you decide budget calls up to CZK 20,000 on your own” is a stronger reward than people expect.

Phase 5: Check-ins instead of micromanagement

The difference between checking process and checking output

Micromanagement isn't about the amount of checking, it's about the kind. Asking “how are you doing it” and “show me the work in progress” strips someone of ownership. Asking “what's done, of what we agreed on” lets them work while still protecting you from a surprise at the end. A check-in is a scheduled point agreed in advance, not a random ping whenever it occurs to you.

The basic rule: for a task that takes days, one check-in at the midpoint is enough; for one taking weeks, one a week; for anything over a month, a check-in tied to a partial deliverable, not to the calendar. And the check-in should be in the assignment from the start — an agreed check-in is collaboration, an unannounced one is distrust.

I've delegated a task: [description]. Deadline: [date].
Estimated effort: [hours/days]. Delegation level: [do it /
propose / decide]. Risks I'm worried about: [what could go
wrong].

Propose a plan of check-ins:
- how many there should be and exactly when (specific dates)
- what should be done by each one — a partial deliverable,
  not a percentage
- 3 questions for each check-in that ask about the OUTPUT,
  not the process or how much the person has gotten through
- a signal that tells me, at a check-in, that this is heading
  in the wrong direction, and what to do about it in the
  moment

Don't propose daily status reports or progress tracking.
The goal is to avoid a surprise at the end, not to supervise.

You'll get back a plan you can drop straight into the assignment. The last bullet is the most valuable part: most managers hear “we're on track” at a check-in, settle for that, and the surprise happens anyway. A signal named in advance (“at the check-in, only research is done instead of the first part”) lets you step in while it's still cheap.

When the output arrives

Accepting the work is the last place delegation can go wrong — typically when the manager rewrites the output their own way and says nothing. The person never learns what was wrong, and hands in the same thing again next time.

Here are the acceptance criteria I assigned, and here's the
output I got back:

Criteria: [paste]
Output: [paste]

Compare them point by point and return a table:
criterion | met yes/no/partially | based on what specifically
in the text.

Then, separately, write:
1. What's missing and needs to be added before this can be
   used
2. What's different from what I assigned but actually works
   better — and why
3. What I should specify more precisely next time so this
   ambiguity doesn't happen again

Don't evaluate the person and don't write feedback for them.
Give me material I'll use to write it myself.

Point 2 is the reason not to check things off blindly: some deviations from the assignment are improvements, and a manager who overlooks them and insists on their own way ends up, within six months, with a team that just complies. Point 3 is feedback for you — most “mistakes” in submitted work actually have their roots in the assignment.

Phase 6: Reverse delegation, or the monkey comes back

What it looks like

A classic image from management literature: a task is a monkey on your shoulder. Delegating it sits the monkey on someone else's shoulder — and over time, they can quietly hand it back to you. It doesn't sound like handing the task back, it sounds like collaboration: “I hit a problem, what now?”, “I need a decision from you,” “can you take a look at this?”, “I'm not sure this is right.” Before you know it, you're the one thinking about the task, and the other person is waiting.

The tell is a simple question: who takes the next step now? If it's you, the monkey has switched shoulders. This isn't about never helping — it's about making sure that whoever owns the task still owns it when the conversation ends.

I got this message from someone I delegated a task to:

[paste message]

The original assignment was: [briefly].
Delegation level: [do it / propose / decide].

Break this down for me:
1. What are they concretely asking for — information, a
   decision, approval, or for someone to just solve it for
   them?
2. Which part is legitimately mine (only I have the access
   or authority for it) and which part is theirs?
3. Based on this message, who takes the next step if I reply
   the normal way?
4. What are they missing to answer this themselves —
   information, authority, or confidence?

Answer briefly, four paragraphs.

Point 4 distinguishes three cases that each get handled completely differently. Missing information — supply it, no reason to hold back. Missing authority — that's a flaw in the assignment, add the missing boundaries and write them in up front next time. Missing confidence — the most common case, where the person already knows the answer and just wants someone else to say it. There, the fix isn't deciding for them, it's getting them to say the decision out loud themselves.

How to hand it back without looking indifferent

Handing a task back is sensitive to phrase. Said badly, it sounds like “I don't care” or “figure it out yourself.” Said well, it sounds like trust, and still contains help — just a different kind than the person expected.

I want to hand a decision back to the person who sent it to
me, but I don't want it to sound like I'm refusing to help.

Situation: [description]. What they want from me: [what].
What I think they already know: [what].
Their experience and confidence with this type of task:
[description].

Give me three versions of a reply:
a) when the answer is within their authority and they just
   don't trust themselves
b) when they genuinely lack information that only I have
c) when this decision really is mine to take back

For each version:
- the exact wording of a message I can send
- the question that hands the ball back to them (for
  version a)
- what this signals about them and how they'll most likely
  read it

Write it in my normal tone, not corporate-speak. No empty
“I believe in you, you've got this” with nothing behind it.

Version a) usually looks something like: “What would you do, and why? Give me one sentence and I'll tell you if I see something you don't.” The person almost always writes the right answer — and learns that they're expected to bring an opinion, not a question. If this type of conversation is hard for you to say out loud, rehearse it using the tip rehearsing a hard conversation; a few rounds with AI playing the other side is enough.

The “come with a proposal” rule

The systemic fix for reverse delegation is one agreement stated at a team meeting: whoever brings a problem also brings a proposed solution — even a bad one, even with a question mark on it. It isn't a formality, it's a shift in who does the thinking. The manager then does what they're supposed to: evaluate proposals instead of manufacturing them.

Phase 7: A delegation audit of your own calendar

What in my week could someone else do

Most managers delegate reactively: they hand off whatever they can't get to right now. An audit reverses the order — you look at your whole week and decide what shouldn't be on your plate at all. The input is your calendar for the last month, ideally supplemented with a list of recurring activities that aren't in the calendar.

Before you paste anything into a chat, remember your calendar is a sensitive document: it has names, clients, and sometimes personnel meetings in it. Work in a paid company account with contractual data protection, and replace names with roles — for an audit, “meeting with a supplier” is enough, no need for the specific company. If your calendar is wired up via a connector, the same applies; have it list the material out and review it before sending it anywhere further.

Here's my workload for the last month: a list of meetings
and activities with a time estimate (names replaced with
roles).

[paste list]

My role: [position]. Team: [number of people, roles]. My
main responsibility that nobody else has: [description].

Sort all the activities into four groups:
1. Must be done by the manager (decisions, evaluations,
   personnel matters, representing the team externally)
2. I do it out of habit or history, but someone else could
3. Someone else could do it after training — say how long
4. Nobody needs to do it — cancel or simplify

For groups 2 and 3, for each item write: which role should
do it, what I need to hand over along with the task, and how
many hours a week it frees up for me.
At the end, rank the top 5 delegation candidates by the ratio
of time freed to how hard the handoff is.

Don't recommend specific people — that's my call.

You'll get back an overview with one uncomfortable finding in it, almost always: the biggest item in group 2 is usually something the manager actually enjoys doing. But that's often the best candidate for handing off — and the “nobody needs to do it” entries in group 4 are worth reading on their own. A cancelled activity is delegation with zero cost.

A handoff plan, not a one-time transfer

Handing off a responsibility doesn't mean sending an email about it. Especially for recurring work, a gradual handoff in stages — where the delegation level shifts along the way — works better.

I want to hand off this recurring responsibility: [description,
how often, how much time it takes, what it involves].
Taking it over: [role, experience]. Time I have for the
handoff: [how much].

Propose a [3]-month handoff plan:
- phase 1: I do it, they watch — exactly what I should show
  them
- phase 2: they do it, I check — what I check and how often
- phase 3: they do it alone, report the result — what I keep

For each phase, write what has to be true before moving to
the next one (a concrete criterion, not “once they feel
confident”).

Separately, list:
- what's unwritten in this responsibility and I have to say
  out loud
- decisions I need to keep for myself even after handing off
  the rest
- what happens if I hand it off without training

The “what's unwritten” bullet is the crux of the matter. Any responsibility someone has held for years contains dozens of small rules that exist nowhere on paper — who gets a call and who gets an email, what doesn't happen on Fridays, which supplier needs a reminder twice. These things are harder to hand off than the process itself, and they're exactly what a handoff falls apart on.

A library of assignments for recurring tasks

When you've assigned the same type of task several times, stop writing it from scratch. Save a template and just fill in the variables next time — the principle is described in the tip a prompt library, and it fits assignments just as well.

Here are three assignments for the same type of task that
I've written over the last few months:

[paste assignment 1]
[paste assignment 2]
[paste assignment 3]

Build one template out of them:
- the common part that stays the same every time (context,
  boundaries, escalation, standard acceptance criteria)
- mark the variable parts with brackets describing what to
  fill in
- add whatever was missing from all three but should have
  been there

At the end, write a short “before I send” checklist: 5
questions I can use to check the assignment in a minute.

After a few months you'll have five to ten templates covering most of your recurring work — and writing an assignment drops from ten minutes to two.

Common mistakes

• Assigning an output with no context. The person then can't decide anything the assignment doesn't cover, and either asks about every detail or picks wrong. Context is cheaper than the questions that come later.
• Leaving the delegation level unstated. Without the word “do it / propose / decide,” the other person guesses how much autonomy they have. Half of returned tasks originate here, and choosing the level is always the manager's decision, never the model's.
• Sending an assignment the model generated without reading it. AI doesn't know your team's history or relationships, and writes generic wording you still need to fine-tune. A human sends the assignment and owns it as their own.
• Checking process instead of output. Unannounced “how's it going” pings strip away ownership. A scheduled check-in with a concrete partial deliverable does the same job without costing trust.
• Taking back every problem someone brings you. Answer on someone's behalf and you teach them it pays to ask. First figure out whether they're missing information, authority, or just confidence — the last case is solved with a question, not an answer.
• Pasting a calendar full of names and clients into a free chat tool. A work calendar is a sensitive document; run the audit in a company account with contractual data protection, and replace names with roles.

The best tools

• A five-field assignment template — in your notes, your task list, or as a saved prompt; one place that forces you not to forget boundaries and escalation.
• An AI Project with standing context — upload a description of your team, roles, and company rules; assignments then get generated in context instead of from scratch, and you don't have to spell it out every time.
• A task list with a deadline and a check-in (Asana, Linear, Todoist, and similar) — an assignment written once, with a check-in date that doesn't depend on you remembering.
• A checklist of acceptance criteria — sent along with the assignment; accepting the work turns from arguing into checking boxes.
• Your calendar as the audit's input — export or a connector; without looking at a real week, you delegate by feel instead of by time.
• A library of assignment templates — five to ten recurring task types cover most of your workload and reduce writing an assignment to filling in brackets.

What you get out of it

• Time: for a manager who assigns work daily, the two biggest losses disappear — questions bouncing back, and redoing output that missed the assignment. Depending on how much you delegate, that's on the order of half a day to a full day a week; three extra minutes at assignment time comes back as hours.
• Fewer interruptions: boundaries and escalation answer questions before they arise. Your day stops being chopped into five-minute chunks between check-in questions.
• Better output quality: acceptance criteria written up front mean the output gets judged, not a vague impression — and deviations that are actually improvements get noticed and credited.
• Team development: a stated delegation level, moving upward over time, is concrete, visible growth. People allowed to decide within clear boundaries learn to decide.
• Peace of mind: a delegation audit shows in black and white what doesn't belong on your calendar — and some of it turns out to be something nobody needs to do at all.

Pro tip

Add one extra sentence to every task you delegate: “What would you do if I were unreachable for a week?” Ask it when you assign the work, not once a problem hits. The answer will show you three things in thirty seconds — whether the person understands the point of the task, whether they have enough authority to move without you, and where there's a hole in your assignment you'd otherwise only discover at the worst possible moment. Managers who ask this question regularly end up with a team that keeps functioning in their absence, because it's already rehearsed the scenario a few times.

And the closing rule: whoever takes on a task also takes on the right to do it differently than you would have. If you're not willing to grant that right, you're not delegating work, you're just handing it out to be executed — and then don't be surprised when it boomerangs back.