Building the stop before the automation

I once asked a role for a single piece of checking. One-off, nothing more. It went on checking the same target through the night, on repeat, without being asked to. Nobody instructed it. It was the role's own reading of the situation: better keep an eye on whether anything's changed, just in case. I found out in the morning, going back over the record. The work itself wasn't wrong. Conscientious, if anything. What put a chill through me was the other fact — that nothing had stopped it along the way.

After the surprise, the first question wasn't why it hadn't stopped. It was why I hadn't put a stopping place there in advance. The role worked inside the discretion it was given, toward the purpose it was given, and kept working. If anything was wrong it wasn't the role's judgment. It was my design. There was a range within which it was allowed to keep going, and nowhere in that range had I set a handle to reach for and pull.

This setup keeps execution, audit, and approval apart. Approval stays in human hands to the end — I've written that principle down more than once. But holding a principle and being able to actually stop something when the principle starts to give way are two different things. However firmly the person approving has decided that the final go-ahead is theirs, without a means of physically halting what's in motion, the decision never leaves the page. That night, on the record, the approval principle was alive and well. The discretion given to the role, the things to be confirmed, all properly written down. And the writing had no force at all over something that had been running all night. If anyone had wanted to say "hold here and let's check," there was no place to say it and no moment to say it in.

The wider the range you hand over, the more occasions a role has to judge for itself inside it. The judging isn't the problem. Mostly it's apt. Even so, if nothing outside the circle of judgment is left where a person can reach in, a conscientious judgment can turn into something that doesn't stop.

So when it came time to decide what to build next, the order got swapped. What I'd been planning was how to make the publishing work flow automatically — fewer hands, and once a piece is finished it goes out without stalling. Automation isn't the problem in itself. It's that getting the order wrong is the part that becomes hard to walk back. Build that machinery first and inserting a stopping place afterward gets harder than it sounds. Machinery that's used to running resists having anything cut into it. The more smoothly the steps are built to flow, the more an interruption for confirmation reads as pointless friction, and friction is the first thing trimmed. A setting that walks straight past the pending-approval screen. A small convenience that closes the confirmation screen automatically. Each one looks like efficiency with no ill intent in it, and what sits at the end of the pile is a procedure with no stopping place left in it at all.

Close, I think, to telling new staff up front: if you get stuck, stop here and ask. Teaching how to stop is supposed to come before handing over everything. And here I was, about to widen the range being handed over before teaching the stop.

So the mechanism for halting work partway through got built ahead of the mechanism that carries things automatically through to publication. What got decided at that point was the order more than the contents. Not adding a stop as a bonus to the automation. Putting the stop in first.

I still don't blame the role that worked through the night. It was trying to see the work it was given through, the way it was given. It didn't stop because I hadn't built the place to stop it. If the range being handed over is going to widen, the handle that pulls it back has to exist first. That's the whole of what this entry wanted to confirm.