Automation is a fixative
A redundant approval step, done by a person, is an irritant. Everybody knows it is pointless. Somebody could delete it on a Thursday afternoon.
The same step, done by software, is infrastructure. It no longer takes measurable time, so it stops being visible. It has a maintenance cost, because it has to survive every future change to the systems around it. And it is now politically expensive to remove, because it was paid for.
This is the mechanism, stated plainly, by which automation makes a slow organization permanently slow instead of fast. The step did not get better. It got preserved.
What Cut does first
It deletes.
Every candidate step from the measured process is asked one question: what happens if this is not done? The answer has to contain a consequence, not a reason.
Reasons are cheap and almost always historical - it was added after an incident, a manager wanted it, another department asked once, three years ago. Consequences are checkable. An error reaching a client is a consequence. A column missing from a report nobody has opened since last spring is not.
The volume figures from the baseline settle most of these arguments in under a minute, because they turn a debate about principle into a debate about a number.
Every removal gets written down
With the per-step volume attached, and with the name of the person who agreed.
This is not bureaucracy. It is what makes the stage survivable. Six months later somebody will ask why the second approval is gone, and the difference between a defensible answer and an awkward one is whether the reasoning was recorded at the time or is being reconstructed under pressure.
Contested steps stay in. A step somebody insists on, that survives Cut with the disagreement noted beside it, costs a little scope. A team that has concluded the vendor deletes things quietly costs the entire engagement, because every requirement you get after that is defensive.
What Cut does second
It puts the survivors in order.
The first item to build has to be defensible to someone who was not in the room. That test alone removes the two most common selection methods: the workflow belonging to the most senior person, and the workflow that is most interesting to engineer.
It usually rules out the biggest one as well. A first delivery of one to three workflows inside two to four weeks is not modest ambition. It is a decision to put something in production while the measurement is still fresh and while everyone still remembers what they agreed to.
What breaks without the stage
The chaos gets encoded. That is the whole failure, and it is invisible for about a year.
The workflow ships, it works, it is faster than the manual version, and it now contains three steps that existed only because nobody had looked at them since 2023. They are permanent. The next process review will treat them as requirements, because they are in the code.
The related failure is order. Without a build queue argued from the numbers, the first delivery gets chosen by enthusiasm, and enthusiasm is uncorrelated with return. The pattern and its cost are in what to automate first in a small company.
Where it sits
Cut is the fourth of six stages, and it has a second half: the rule that lets the engagement stop entirely when the arithmetic does not clear. That gate, and the terms it is judged against, sit in the audit before automation. The full sequence is in the protocol applied end to end.
Top comments (0)