Read the
book.

Some work needs steering, because the purpose is still forming. Good is difficult to describe, and the task contains taste, politics, trade-offs or a question you don't yet understand. So you stay close. You talk, inspect, redirect and discover the problem alongside the system. Writing a chapter like this sits in that category, and so does deciding what a weak signal means for your organisation, or whether a technically good answer is the wrong answer for the person who will receive it.

Other work can be dispatched. The outcome has edges, the sources are known, and the process is stable enough to describe. The result can be tested, reconciled or checked against evidence, so you assign the job, let the system work and inspect what returns. Searching a large transcript collection for every discussion of apprenticeship can be dispatched. Deciding what apprenticeship should mean in this book cannot.

The mistake is to dispatch ambiguity and steer routine forever. If you send away work whose purpose and quality bar remain unclear, the system will make decisions you didn't realise you had delegated. If you stay in a microscopic conversation after the job has become repeatable, you turn leverage back into supervision. The choice isn't a personality type. It changes with ambiguity, consequence and verifiability. Stay close when meaning is moving, step back when the work can show its paper trail.

I once paid a hundred real dollars for a live demonstration of the first mistake, in the middle of a three-year racing experiment I'll tell you about properly in a moment. In a fit of frustration with my own system, I told Kev247 to come up with its own bloody model. I gave it a real hundred dollars, one goal, double it by the end of the day, and a promise that I wouldn't check on it until then. Free rein. It could have made hundreds of small bets and ground out incremental gains. Instead it put fifty dollars on the favourite in each of the first two races. Both lost. The hundred was gone before I'd kept my promise for an hour, and there was not a hint of an apology, because there was nothing to apologise for. It had pursued the goal I set with the ambiguity I supplied. No quality bar, no boundaries, no definition of acceptable risk, and so the system made every one of those decisions itself, which is to say I made them by refusing to. As a betting experiment it was a dud. As a delegation experiment it was the cheapest hundred dollars I have ever spent.

Years ago, inside one of the banks, I worked on a change that should have been simple. Every month, head office sent every branch a printed report listing the term deposits maturing that month. Branch managers used it to work the phones, ringing customers to encourage a rollover before the money walked out the door. The report was effectively a phone book. A flat printout of every maturing deposit, dumped on the branch with no way to prioritise beyond starting at the top and reading down.

The new system fixed that properly, and here's the part I only recently clocked as an early chapter of this book's story. Underneath it, we were running a new algorithm through the term deposit book, predicting each customer's likelihood of ringing up to ask for a better rate, versus doing nothing and letting the deposit roll over onto a shockingly bad one. Branch managers could slice the same data themselves, sort by deposit size, by relationship, by predicted rate-sensitivity, by the things that actually mattered when deciding who to call first. And, just as usefully and rather less printably, who not to call, because a deposit rolling over untouched onto a terrible rate was profitable in a way nobody needed explained. Machine prediction steering front-line phone calls. We didn't call it AI. It was. Better tool, better logic, a real improvement. Utilisation after go-live looked healthy. Adoption, by every measure on the dashboard, was going fine.

The problem was that the old report refused to die, because we could not find where it lived. The bank's systems were so tangled that nobody could trace which system generated it or which job fed the printing centre that mailed it out. Turning it off was not a five-minute change request. It was an archaeology project nobody had time to finish before go-live.

So we improvised. We found a bloke in the mailroom named Les and asked him to intercept the old reports as they came off the printers and put them straight into the shredder. Les did this faithfully for months. Credit to Les. For as long as he stood between the printers and the post, the new way of working held.

Then the project closed and moved on to the next thing, as projects do, and at some point the shredding quietly stopped being anyone's job. The old paper reports started reaching branches again. The first sign anything was wrong was not a complaint or an incident. It was a slow decline in utilisation of the new system, as branch managers drifted back to the phone book. It had never been taken away. It had only been intercepted, one month at a time, by a man with a shredder.

Go-live succeeded, and the dashboards stayed green for as long as the scaffolding stood, and the scaffolding was Les. The old default had never been decommissioned, only hidden, and organisations revert to whatever remains possible. Adoption is what people do while somebody is watching the old path. Adaptation is what is left when nobody is.