Learning Center / Directing an Outcome with Software

Course 3 · Lesson 5 of 5

The failure mode

A tour is booked for eleven dates. The flights, the hotels, the venue contracts and the deposits all get handled on schedule, mostly by machinery, with a weekly summary arriving on Mondays. In week six, somebody books a flight to the wrong airport. It is the cheaper airport, ninety miles from the venue, and the booking was confirmed by a system that had been told to book the cheapest option inside the date window.

The work was done. The list was followed exactly. Nobody looked at the four bookings that week, so nobody noticed, and the mistake was discovered on the morning of the show.

Silence is the failure

The failures that hurt are not the ones where something stops. A system that stops is loud, and loud is easy. The expensive failure is the one that keeps working, slightly wrong, for months.

It looks exactly like success from the outside: schedules met, records written, nothing flagged. The only way to tell the difference is to look at the work itself, and looking is the thing that stops happening once everything runs smoothly.

There is a name for the condition. It is work that is done and unwatched, and it is the natural end state of any delegated process that nobody ever inspects.

Why it happens

Nobody decides to stop looking. Three ordinary things happen instead.

*The early checks stop once the work looks fine.* The first month gets reviewed because it is new. The sixth month does not, because nothing has gone wrong yet.

*The material stops being readable.* Summaries replace the underlying items. A summary line that says eleven bookings confirmed is true whether or not one of them goes to the wrong airport.

*Attention moves to whatever is loud.* There is always something urgent, and quiet work loses every contest with it.

Three habits that hold it off

*Keep a small number of things visible on purpose.* Not everything. Two or three. For a fleet, that might be: vehicles off hire today, services overdue, damage claims open. Read them at the same time each week. The point is that the reading is a habit rather than a response to a problem.

*Look at the artefacts, not the summaries.* Open one booking, one reconciliation, one renewal, and read it properly. A person who reads two real items a week will catch most drift, and will learn the shape of what normal looks like, which is what makes the odd one visible.

*Be suspicious of a clean sheet.* Recurring work has exceptions in it. A report with none, week after week, is either describing something very simple or describing something that is no longer being looked at by whoever produces it.

When it does go wrong

Two useful actions, in this order.

First, look at the record and find out what actually happened, including how long it has been happening. The second half of that question is the one people avoid, and it is the one that determines the size of the problem.

Second, change the description rather than the person. If the wrong airport was booked because the rule said cheapest inside the date window, the rule was the defect. Machinery does faithfully what it was told. A rule that produces a bad result on a real day is a bad rule, whatever it said in the abstract.

The part a person is for

An outcome is a state somebody is responsible for. Software can carry the machinery that holds the state up. It cannot hold the responsibility, because responsibility is not a thing that can be transferred to a system.

Which is why the last lesson of this course is the same as the first. A person has to decide what matters, describe it precisely, keep a few things in view, and sign where signing is needed. That is not an unfortunate remainder to be engineered away. It is the part of the work that was always worth doing, and it is the part that stays.