Delegation: Deciding What Goes to a Machine

Delegating to a person and delegating to a model share most of their structure. You decide what to hand over, you set the standard, you check the result, and you remain accountable.

One difference matters more than all the similarities. A person learns from correction and a model does not.

When you correct a colleague, the correction persists. Their next attempt is better, and the investment in explaining compounds. When you correct a model's output, the correction applies to that output. The next request starts from the same place, and the investment does not compound.

Two consequences follow directly.

Teaching effort should still go to people, because it is the only place it accumulates. A manager who spends their coaching time refining prompts and their delegation time on people has it exactly backwards.

And anything a model gets wrong repeatedly must be fixed structurally rather than conversationally. Better instructions in a reusable template, a changed workflow, a check in the process, or a decision to stop using it for that task. Correcting the same failure in each conversation is a cost with no end.

That framing makes the rest of this lesson tractable: the question is not can AI do this but does handing it over leave the team better off after verification.

The single most useful concept for delegation decisions: the time saved producing something is reduced by the time spent checking it, and for some tasks the second exceeds the first.

Call that difference the verification tax. Delegation pays only when the tax is smaller than the saving.

What makes the tax low. The output is easy to check: it either compiles, matches a source, satisfies a schema, or is obviously right or wrong on inspection. Errors are visible rather than subtle. And the checker is competent in the domain.

What makes it high. Verifying requires redoing the work, which is the killer case. The output is plausible-looking regardless of correctness, so checking means independent research. The checker lacks the expertise to judge. Or errors are silent, so the tax is not paid up front and arrives later as an incident.

The cases where delegation loses money are specific and identifiable. A summary of a long document you must read anyway to verify the summary. A calculation you must reproduce to trust. Research where each claim needs independent confirmation.

And note the trap: where nobody pays the verification tax, delegation looks free. It is not free, it is unpriced, and the cost surfaces later attached to someone else's name.

Four questions, in order, that resolve most cases.

First, what does being wrong cost? Where the answer is high and irreversible, the decision is essentially made: a human decides, with AI at most assisting the preparation.

Second, can the output be verified more cheaply than it can be produced? If not, delegation does not save anything, whatever it feels like.

Third, does someone competent actually check? A verification step assigned to someone who cannot judge the content is a formality, not a control.

Fourth, does doing this task build capability someone needs? If it does, the efficient choice and the developmental choice diverge, and that is a real trade to make consciously rather than by default.

What survives all four is a good candidate for delegation. What fails the first is a human decision. What fails the second or third needs the workflow changed before delegation makes sense.

Applying the four questions to a marketing team's actual work, to show how differently similar-looking tasks resolve.

TASK                        COST   VERIFY   CHECKER   BUILDS   VERDICT
                            WRONG  CHEAPLY  COMPETENT SKILL

Draft social copy variants  low    yes      yes       no       delegate
Summarise a call recording  low    yes*     yes       no       delegate
  (*transcript is the source, so checking is bounded)

Competitor research memo    med    NO       partly    yes      keep manual
  (every claim needs independent confirmation)

Segment analysis from data  high   yes      yes       yes      assist only
  (AI drafts, analyst verifies against the data)

Pricing recommendation      high   no       yes       yes      human decides

The two research-shaped rows are the instructive ones. Both look like classic AI use cases and both fail the verification test, because confirming a claim costs about what finding it cost. That is the pattern to watch for: tasks where the output is prose that sounds authoritative and where being wrong is not immediately visible.

The segment analysis row shows the middle option that gets forgotten. Not delegate or do not delegate, but AI produces a draft and a competent person verifies against the underlying data, which is cheap because the data is right there.

The largest gains and the largest failures both come from the same choice: whether AI is inserted into an existing process or the process is rebuilt around what is now cheap.

Bolting on means the workflow keeps its old shape and one step gets faster. The benefit is bounded by that step's share of total time, which is usually smaller than expected, and the surrounding process often absorbs the saving through queuing.

Redesign means asking what the process would look like if this capability had always existed. That question produces different answers: steps that existed only to compensate for a bottleneck that no longer binds, batching that was necessary because the work was expensive and is now pointless, and review stages positioned for the old error profile rather than the new one.

The caution, and it is a real one: redesign is riskier, slower, and much more disruptive to a team that is already coping with change. A manager who redesigns three processes at once produces chaos and no measurable improvement.

The practical middle is to bolt on first to learn where the capability actually helps, then redesign the one workflow where the evidence justifies it. Sequencing beats ambition here, because the information needed to redesign well only exists after some use.

And redesign the review stage explicitly. It is the part most often left in its old position, which is why the bottleneck from the previous lesson forms.

Teams need a shared answer to when AI use should be mentioned, and in its absence people improvise inconsistently, which erodes trust in both directions.

The unhelpful extremes are easy to identify. Disclose everything produces noise, since nobody annotates their spellchecker. Disclose nothing produces the situation where a colleague discovers after the fact that a document they relied on was generated, which damages trust disproportionately to the actual risk.

A workable principle: disclose where it changes how someone should treat the work.

That resolves most cases. A drafted internal email needs no note. An analysis someone will act on should say what was generated and what was verified, because the recipient's checking behaviour should differ. Work sent to a customer or a regulator follows whatever external rules apply, including the AI Act's transparency duties where relevant. And code should record it where it affects how the next person maintains it.

Two specifics worth deciding as a team rather than leaving implicit. Whether AI use is acceptable in work being assessed, such as a hiring exercise or a performance artefact, which is a fairness question and needs a stated answer. And whether declining to disclose is ever treated as misconduct, which it should be in the narrow case where someone actively claims authorship they do not have.

Write the norm down. Unwritten norms are enforced inconsistently and usually against the least confident person.

A recurring team conflict, worth pre-empting: is AI-assisted work held to the same standard as unassisted work?

The answer is yes, and stating it early prevents a slow drift that is hard to reverse.

The drift happens like this. Volume rises. Review capacity does not. Standards quietly relax to clear the queue, one accommodation at a time, and nobody makes a decision to lower the bar. Six months later the team's output is measurably worse and no one can point to when it changed.

Three things hold the line.

Say explicitly that the standard is unchanged, and that faster production means more review time available per item rather than less, which is the opposite of what queue pressure suggests.

Make the standard concrete rather than cultural. Written criteria for what acceptable means in this team's work, because an implicit standard is exactly what erodes under pressure while everyone believes it is being maintained.

And watch the leading indicator. Rework rate, downstream complaints, and defects found late all rise before anyone perceives a quality problem, and they rise while throughput metrics still look good.

One nuance worth allowing. The bar should differ by consequence, and it always did. What must not happen is the bar differing by production method, so that generated work is held to a lower standard because there is more of it.

If review capacity is the constraint, a manager's most consequential decisions are about protecting and expanding it.

Five moves, in rough order of how quickly they help.

Make review time explicit in workload planning. Where it is invisible, it is the first thing squeezed, and it is squeezed precisely when volume is highest.

Distribute review rather than routing everything to the most senior person. Peer review handles a large share of cases, and reserving the senior reviewer for the genuinely hard ones is both better use of them and more developmental for everyone else.

Reduce what needs deep review by narrowing where AI is used. If a category of work consistently requires expensive verification, that category is a poor delegation candidate, and the first lesson's framework says so.

Invest in cheap verification. Automated checks, source links, structured output with citations, and anything that lets a reviewer confirm rather than reconstruct. This is where tooling genuinely helps, and it is the lever with the longest payoff.

And protect deep work for the reviewer. A senior whose day is fragmented into review interruptions is not doing the work only they can do, and that opportunity cost is real even though it appears on no dashboard.

The general principle: adding production capacity to a system constrained by review makes the constraint worse. That is not an argument against AI, it is an argument for spending some of the gain on the bottleneck.