Table of Contents

Most automation projects I get called into are described as speed problems. Something takes too long, so make it faster. That description is usually right about the symptom and wrong about the order to fix things in.

The failure mode

A support team answers “is this item in stock” by consulting a figure that the warehouse updates once daily. Average response time is around a day, and leadership wants it faster. The obvious move is to automate the answer.

Automating it makes the response instant. It also makes it wrong more often, and wrong in a worse way.

Before automation, a rep answering after some delay had a decent chance of noticing that the number looked off, checking, and caveating the answer. That judgment was invisible and unrecorded, but it was doing real work. Automation removes the human from the loop and simultaneously removes the correction, so a stale figure now reaches the customer immediately, with the implicit authority of a system.

In a medical supply context the customer may be a practitioner making a substitution decision. Fast and wrong is not a smaller version of slow and right. It is a different failure with a different cost.

The ordering

The sequence I now hold to:

1. Make the underlying state observable. Whatever the automation will read, ensure it reflects reality at the moment of the read, not at the moment of the last batch job.
2. Verify against reality. Sample the automated answer against ground truth before anyone depends on it. Measure how often it is wrong and how wrong.
3. Then reduce latency. Once the answer is trustworthy, making it fast is straightforward and safe.

Step one is unglamorous, frequently reveals that the data problem is larger than assumed, and is the step under the most pressure to skip because it produces nothing demonstrable.

Where the pressure comes from

Steps one and two are invisible to stakeholders. Step three demos well. A project that spends six weeks on data plumbing and two on the interface looks, from outside, like a project that spent six weeks doing nothing.

The counter I have found effective is to instrument the error rate early and report it. “The current process gives the wrong stock figure 18% of the time” reframes the work as correctness rather than delay, and correctness is defensible in a way that plumbing is not.

What this does not argue

It does not argue against automation. In the case above, the automated system ended up handling the majority of routine inquiries and freeing the team for genuinely complex ones, which was the correct outcome.

It argues only that the order is fixed. Trust, then speed. Reversing them produces a system that is confidently wrong at scale, and confidently wrong at scale is difficult to walk back, both technically and with the customers who were told the wrong thing quickly.