Topic 05 · Necessary But Not Sufficient
The tool worked. The system did not.
AI assistants, faster CI, a new platform, another observability stack. The technology is real. Throughput stays flat when the rules, the release of work, and the measures were built for the previous constraint. Installing the tool on top of those rules automates the waste, or moves the queue.
After Haystack. Six sections. The constraint and the rope are the ones from Flow.
01
Necessary, not sufficient
Goldratt’s argument about ERP, applied to anything sold as a transformation of delivery. The tool has to work. That is the necessary part.
A system only produces a lasting gain when the organisation also changes the policies and the measurements that were built around the old limitation. Two out of three is still not enough.
02
Three conditions
The technology is available. The process is redesigned around whatever the tool just released. The measures reward Throughput, not the local activity the tool made cheap.
In place
Technology
Missing
Process
Missing
Measures
Throughput
Still not sufficient
Necessary but not sufficient. Still missing a process change and a measurement change.
03
The queue moves
More code, same cycle time, leadership pleased by the activity. The constraint left coding. Nobody followed it.
Throughput 4 used outcomes / week
Coding is the long queue. Review is waiting on code.
Review is unchanged. More work is started because coding feels faster. Success is counted in commits. The rope does not move.
04
Old rules
Heavy review, large batches, utilisation, detailed estimates. Each one protected a real limitation. When the limitation shrinks, the rule can become the constraint.
Every change needs the same heavy review
Plan a large batch before anyone starts
Utilisation targets
A person still has to approve production
05
Make it sufficient
Treat the rollout as a change to technology, process, and measurement. Then look again. The constraint will not be where the vendor’s diagram left it.
- Name the constraint before you buy.
- If the technology works perfectly, where does the constraint move?
- Subordinate to that new place. WIP, pull, protection.
- Change the measures so local activity is no longer the win.
- After it is in, re-identify. Do not keep the old policy out of inertia.
06
The next tool, before you sign
If you cannot name the process change and the measurement change, the tool is likely to be necessary and not sufficient.
- The constraint it is supposed to address.
- The process and the measure that have to change for the gain to appear.
- If those sentences are empty, stop.
- After adoption: did valuable outcomes rise, or did the queue move?
- Remove the policy the technology has made obsolete. Keep the one that still protects Throughput.
This week
0/5
Cheat sheet
- The claim
- Technology is necessary. It is not sufficient.
- Three together
- The tool works. The process changes. The measures change. Any two still fail.
- Install only
- Old policies stay. Waste is automated, or the queue moves and looks like progress.
- Where it moves
- Faster coding usually exposes review, test, a product decision, or deploy.
- Fossils
- Many rules exist because of a limitation the tool just removed.
- After
- Re-identify the constraint. Do not leave the old policy in place out of habit.
Check yourself
5 questions. No timer.