Who Gets Blamed When You Kill the Pilot?

Everyone agrees, in principle, that you should stop the work that is not paying off. In practice, it’s much harder to execute. In the last piece, we walked through four moves for getting your AI decisions back in the right hands, and the fourth—the stop—is the one that seems to be the most difficult. This piece is about why, and about how to make it happen without a casualty.

The reason is not that the evidence is unclear. By the time a pilot should be stopped, most of the people around it can already see it. The reason is that the stop has a name attached to it, and that name reads as failure. Stopping the project a colleague championed feels like a verdict on them. Stopping the one you championed feels like admitting you were wrong, in public, with a budget number beside it. So the stop that everyone can see is needed never gets owned, and the work keeps its funding by default.

It becomes a zombie: still alive on the books, still drawing budget and attention, kept running because ending it is harder, for the people involved, than letting it go on.

This is expensive in the obvious way: the budget that keeps flowing to work that will not pay off. It is expensive in a way that is easier to miss: a portfolio that cannot stop things cannot really start them either. When killing a bet is a career risk, people stop making real bets, and you end up with a pipeline that is at once crowded with zombies and starved of nerve. The capacity to stop on purpose is what makes it safe to try in the first place.

The fix is not more courage. Courage runs out, and heroism isn’t sustainable structure. The fix is to take the blame out of the decision, the way we covered last time: agree the criteria for stopping before the work begins, and give the stop a named owner.

When the line was drawn in advance and signed by everyone, the person who calls the stop is holding the group to a line the group drew together. The stop then reads as the test working rather than as a person failing. The work did not let anyone down. It reached a condition the room agreed to before anyone was attached to the answer.

This is not a new idea in innovation, even if it is fraught with difficulty. Rita McGrath has spent years making the case for intelligent failure and what she calls failing by design: the skill is not in avoiding failure, it is in stopping early and cheaply, on purpose, and taking the lesson with you.

A stop made on time, against criteria you set, is one of the most valuable things a portfolio can do, because it returns the capital and the people to the bets that deserve them. It is also where Cost of Failure pays you back. At OUTCOME we make the case for measuring what you spend before you stop, and the stop is the moment that measure turns from a record of money gone into capital you can redeploy.

Every zombie you end on time is budget handed back to the work that is earning it.

AI raises the stakes on all of this. The cost of a pilot that should have stopped now accumulates at the speed of AI, and some of what an unowned system does cannot be taken back. The structural stop from the last piece, where a consequential action cannot execute until a named person accepts it, is the same discipline applied to the fastest version of the problem.

Pre-agreed criteria tell you when to stop a program; a structural stop makes sure a system cannot run past the moment a human should have said no.

None of this makes the politics disappear. A determined sponsor can still fight a stop, and any criterion can be argued with. But setting the line in advance moves that argument to where it belongs: to the start, when no one is invested in the answer yet, instead of to the moment of the kill, when everyone is. That is an argument you can win.

This “series” of articles started with a worry: that the Chief AI Officer is about to relive the Chief Innovation Officer’s hardest decade, in fast-forward. Where we can avoid repeating history is by focusing on the structural elements.

Innovation already has excellent culture, leadership and process disciplines. What we now know is there is more at play that we can problem-solve against to change the trajectory of how the story plays out for both innovation and AI professionals.

AI will not wait for it, so do not wait to build it.

Take your most obviously stuck pilot—the one everyone privately knows should end is a good one—and ask two questions:

1. Was there ever a line that would have stopped it?
2. Who would have owned that call?

If the answers are no and no one, you have found where to start.