The Constraint Is Usually Somewhere Else
Most growth programs begin where attention is loudest rather than where throughput is limited. A short method for locating the binding constraint before spending against it.
The Constraint Series
Sequencing matters more than tooling when work becomes automated.
Automation is often introduced as a fix for inconsistency. It is closer to a multiplier of it. Whatever the process currently does — including the parts nobody agrees on — happens more often, faster, and with less visibility once it is automated.
Figure 1
Figure 1 — states of a business process
| State | Description | Ready to automate? |
|---|---|---|
| Manual | Performed from memory, varies by person | No |
| Standardized | Written, owned, repeatable | Yes, in part |
| Automated | Executed by software with defined inputs | Maintain |
| Visible | Measured, exceptions surfaced | Target state |
The useful move is rarely manual to automated. It is manual to standardized, then a narrow slice of the standardized work to automated, then visible.
A manual process with a five percent error rate produces a handful of problems a week, and a person usually catches them. The same process automated at fifty runs a day produces the same rate against a much larger base, with nobody watching the intermediate steps.
Figure 2
Defects per month at a 5% error rate, by run volume
20 runs/month (manual)
1 defects
200 runs/month
10 defects
1,000 runs/month (automated)
50 defects
1,000 runs/month at a 1% rate
10 defects
The error rate does not change. Only exposure does. Standardization lowers the rate; automation raises the base.
Source: Liquid analysis — arithmetic on a stated error rate, not measured client data
The last two bars are the whole argument for sequencing. Reducing the error rate before scaling volume produces a fifth of the defects at the same throughput — and the work that reduces the rate is standardization, not tooling.
Figure 3
What changes when a process is automated before it is defined
| Dimension | Before automation | After automation |
|---|---|---|
| Who can explain it | The person doing it | Whoever configured it, if still employed |
| Cost of a change | A conversation | A rebuild and a regression risk |
| Visibility of failure | Immediate and local | Delayed and aggregate |
| Accountability | Named person | Diffused into the tool |
| Vendor dependency | None | Structural |
Automate the repetition. Keep the judgment.
Done in the right order, automation removes administrative drag without removing accountability. Done in the wrong order, it produces a system nobody can explain and nobody owns.
References
Author
Founder
Alenn founded Liquid after working across startups, technology, analytics, operations, and marketing strategy. His research focuses on where growth is actually constrained and how operating systems change business outcomes.
Strategy · Systems · Growth · Decision Intelligence
Related services
Have a similar problem?
Related Research
Most growth programs begin where attention is loudest rather than where throughput is limited. A short method for locating the binding constraint before spending against it.
The Constraint Series
Tool sprawl is usually a symptom of undefined ownership. A framework for deciding whether a problem needs a purchase, a connection, or a decision.
The Operating System Series