The bottleneck test

The false picture: "I do this because it needs me." Said sincerely, believed completely, and for most of the tasks on most people's lists, false. The belief survives because it is never tested, and this lesson is the test.

Four questions, asked of every task. Does it require my judgement, a decision only I can weigh? Does it require my authority, a commitment only I can make? Does it require my relationship with a person, trust that transfers to no system? Does it require my personal accountability, a signature that must be mine? A task that fails even one question has a claim on you. A task that fails none of the four is on your list for exactly one reason: no system exists to do it. That is a design finding, not a fact about the task. Write it down as one.

One more piece of craft, because the error runs in both directions. Process weight is proportional to uncertainty. A delegation system for a recurring two-hour task should not carry the ceremony of a two-month programme: a role card and a check may be its entire apparatus. Inflating process feels like diligence and is a defect: every unnecessary step is attention spent on the system instead of through it. Equally, a novel, high-stakes delegation deserves the full weight of trials and review. Weight follows uncertainty and failure cost, never habit and never anxiety.

The unit of delegation is the task as written, so how you write tasks now matters. A task defined by a verb and a vague noun cannot leave you, because no system, human or digital, can be held to it.

The strong version names the enquiry type, the material available, the output form, the check, and what escalates. Nothing about it required AI to exist; it is simply a task defined well enough to be given to anyone. That is the skill this level builds, and Level 1 gives the receiving end a name.

The course's position, stated plainly: the ceremony of a delegation scales with its uncertainty and its consequence, never with your enthusiasm for the system. Enthusiasm is the usual driver, in both directions. New delegators wrap ten-minute tasks in trials and templates because ceremony feels like competence, then abandon all process in month two because the ceremony exhausted them. The ladder below is the corrective: three sizes of task, three weights of process.

The programme row introduces a practice the earlier lessons have not needed: the budget checkpoint. Before a programme starts, agree a spend at which work pauses and reports, denominated in whatever is scarce, hours of run time, items processed, or your own review attention. At each checkpoint the delegation reports four lines and nothing else.

Four lines force a real decision at a planned moment, instead of a drift past the point where stopping was cheap. And one rule sits above the checkpoints: a hard budget stops work when it is reached. Not "flags", not "warns and continues": stops. A system that continues quietly past its budget has converted your cost control into decoration, and the fourth line exists precisely because "reason to continue" is a case to be made to you, not a default.

The failure runs in both directions and both are worth naming. Ceremony on micro tasks kills adoption: if reformatting a table requires a card, a trial and a verdict, you will stop delegating within a fortnight and conclude the method does not fit your work, when what did not fit was the weight. No ceremony on consequence is the opposite death, and a slower one: an unbounded programme with no checkpoints runs until its failure surfaces on its own schedule, which is how the incident cases you will meet in Level 5 begin. Neither failure looks like a failure on the day you commit it. The first looks like diligence and the second looks like trust, which is why the ladder is worth writing down where you will see it: weight is a property you assign from uncertainty and consequence, not a mood you inherit from the week.