The Delegation Test

What the five questions are asking

Stakes, undo, checking, answering, voice. The first asks how far the task can fall; the second, whether a fall can be caught; the third, whether you would even see it fall. The fourth asks who is standing underneath when it does, and the fifth whether the task is still itself once someone else has done it.

Two of the five are not like the others. Whether a task can be undone, and whether it can be checked, are facts about how the work is set up rather than what the work is, and a setup can be redesigned: a draft instead of a send, a sandbox instead of the live system, a test, a source to compare against, a second reader who knows the field. That is why the verdict ends with what would change it, and why it lets you try the change. Often the wisest answer to “should I hand this over?” is “not yet, and not like that”.

Three rules override the arithmetic. Each answer scores nought, one or two, so five make a score out of ten: two or less is “Delegate freely”, up to six is “Delegate, then verify”, and seven or more is “Keep the human hand”. But a task with even one answer at the far edge never earns “Delegate freely”, however mild the other four. A task that nobody could check stays in the human hand whatever its score, undoable or not: handing it over would not be delegating, only hoping. And a task made checkable by a redesign goes no further than “Delegate, then verify”, because the checking it now allows is yours to do. A total is kind to the gravest risk in a list; a verdict should not be.

The lines are a judgement call. The test is a prompt for your own thinking, not a substitute for it, which is rather the point.