Services / Automation
Automate the process you have already fixed. Never the one you have not.
Automation multiplies whatever it is pointed at. Pointed at a good process it compounds; pointed at a broken one it produces broken outcomes faster and with less chance of anyone noticing. The order of operations is not negotiable.
The canon
The principles this rests on, named.
Each with who established it, so the claim can be checked rather than taken on our word.
Ironies of automation: automating the easy parts leaves the human only the hard parts, and out of practice at them.
Lisanne Bainbridge, Ironies of Automation (1983)
Forty years old and still the most important paper on the subject. It predicts exactly how an automated ops team fails when the automation breaks.
Theory of constraints: improving anything other than the bottleneck improves nothing.
Eliyahu Goldratt, The Goal (1984)
It tells you what to automate. Automating a step that is not the constraint produces a faster queue in front of the same bottleneck.
Make the process visible before you make it fast.
Toyota Production System; value stream mapping
You cannot automate a process nobody has written down. Mapping it usually reveals that half the steps exist only because of an earlier workaround.
Automation surprise: the operator must always be able to say what the system is doing and why.
Sarter, Woods and Billings, human factors literature
The failure mode of a silent automation is that it fails silently. Every automation we build reports what it did, in a place a human actually looks.
Idempotency and a manual override are requirements, not refinements.
Distributed systems practice
Anything that can run twice will run twice. If running twice sends two invoices, the automation is a liability rather than an asset.
Price against the cost it removes.
Value-based pricing; standard in operations consulting
Hours are the wrong unit for a thing whose value is the labour it deletes forever. This is also why we refuse to automate something that saves less than it costs to maintain.
Method
What actually happens, in order.
Every step, who does it, how long, how often, and what triggers it. On paper. Usually the map alone removes two steps.
One step is the bottleneck. Automating anywhere else changes the total throughput by nothing at all.
Remove the steps that exist only historically. Automating a workaround makes the workaround permanent.
Hours per month times the real loaded cost, minus maintenance. If the answer is small, we say so and stop.
Idempotent operations, a log, an alert on failure, and a documented manual path for the day it breaks.
The team is trained on what it does, how to read the log, and what to do when it stops. Bainbridge's irony, addressed directly.
What goes wrong
The failure modes nobody advertises.
The most expensive error in the category. The mistakes now happen at scale, silently, and are harder to trace.
An integration stops on a Tuesday and is noticed at month end. Everything downstream of it has been quietly wrong for three weeks.
One person understands the automation. They leave, and the business is running on something nobody can modify or safely turn off.
Real, visible time saved somewhere that was never the constraint, so total output does not move and the project is judged a failure.
When it breaks, the work simply stops, because the people who used to do it no longer remember how.
What we refuse
A studio is defined as much by this list.
- We do not automate a process the client has not documented.
- We do not build something whose maintenance cost exceeds its saving.
- We do not deliver an automation without logging, alerting and a manual fallback.
- We do not build on a tool the client cannot administer or afford at scale.
Measured, not felt
How anyone can tell whether it worked.
Hours removed per month, measured after the change, not estimated before it.
Error rate compared against the manual baseline.
Time to detect a failure, which should be minutes rather than weeks.
Whether the client's own team can modify it without us.