The project was pitched as reducing our change lead time, and it succeeded at exactly the thing it measured. Raising a change request used to mean a form, three emails and a spreadsheet. Afterwards it meant a pull request template that opened a ticket, notified the approvers, collected their sign-off in the tool and attached the evidence automatically. Genuinely good work. Lead time from request to deployment did not move at all.
The reason is that the delay had never been in the paperwork. It was in the weekly board meeting that approvals waited for, and we had not touched that. Before, a request sat in a spreadsheet for an average of four days waiting for Thursday. After, it sat in a queue in a nicer tool for an average of four days waiting for Thursday. We had removed about twenty minutes of human typing from a process whose cost was measured in days, and then reported a success.
What made it worse is that automation made the wait invisible. The spreadsheet was embarrassing. People looked at it, complained about it, and used the complaint as leverage. The new system looked professional, every state transition was logged, the dashboard showed healthy throughput, and the four days became a normal property of the system rather than an irritation anyone was motivated to fight.
I have seen this pattern enough times now to treat it as the default failure mode. Automation is applied to the part of a process that is annoying to a technical person, which is rarely the part that is slow. Nobody automates the waiting, because waiting is somebody else's meeting.
The thing I now insist on before building anything is a crude timeline of the existing process with real durations on it, taken from the data rather than from people's impressions. Where does the work actually sit, and for how long, and what is it waiting for. If the longest bar on that chart is a human decision point, no amount of tooling around it will help, and the honest recommendation is to change who decides and when, which is a political conversation rather than an engineering one.
Automating the cheap half of a slow process does not make it faster. It makes it tidy, and tidy is much harder to argue with.
– Serguey Shinder
Top comments (0)