Automating a step that should not exist makes it permanent. Cut is the stage where steps get deleted, and where the build queue gets its order.
Contents6 sections
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.
Frequently Asked Questions
Why is automating a bad step worse than leaving it alone?
Because it converts a cost into an asset on somebody's mental balance sheet. While a human does the redundant approval, it is friction that everybody complains about and that could be removed in an afternoon by anyone with the authority. Once software does it, three things change: it stops being visible, because it now takes no measurable time; it acquires a maintenance cost, because it has to keep working through every future system change; and it becomes politically expensive to remove, because somebody paid for it. The step that was an irritant is now infrastructure. This is the specific mechanism by which automation makes slow organizations permanently slow rather than fast.
How do you tell an unnecessary step from one you do not understand?
You ask what happens if it is not done, and you require an answer with a consequence in it rather than a reason. Reasons are cheap and mostly historical: it was added after an incident, a former manager wanted it, another department asked once. Consequences are checkable. If the answer is that an error would reach a client, the step is load-bearing and stays. If the answer is that a report would be missing a column and the report has not been opened in a year, the step is scar tissue. The volume figures from Track do most of the work here, because they turn the question from an argument about principle into an argument about a number, and the number is usually decisive within minutes.
What if the team disagrees about a removal?
The step stays in, and the disagreement is written down next to it. This is not diplomacy, it is self-protection: the fastest way to lose a team's cooperation for the rest of the engagement is to delete something they told you mattered, and the second fastest is to delete it quietly. A contested step that survives Cut costs a little automation scope. A team that has decided the vendor removes things behind their back costs the whole project, because from that point every requirement they give you is defensive. The disagreements also age well - about half resolve themselves once the workflow is live and everyone can see what the step was actually protecting.
How is the build order decided?
By return against feasibility, using the matrix from Break refreshed with what the measurement actually showed. The first item has to be defensible to somebody who was not in the room, which rules out the two most common selection methods: the workflow whose owner is most senior, and the workflow that is most interesting to build. The largest candidate usually goes too. A first delivery of one to three workflows in two to four weeks is not a limitation of ambition, it is a deliberate choice to get something into production while the measurement is still fresh and while the team still remembers agreeing to it.
