AI is amazing. You can answer questions. You can build new things. You have the power of a thousand PhDs at your fingertips.
But nothing is getting better…
Cycle time looks the same. Roadmaps slip the same. Everyone says they are feeling faster, but yet nothing arrives sooner.
Local gains do not move a system.
The two best ways to miss gains are spending time at a place that isn’t the constraint or automating a process that shouldn’t exist in the first place.
None of this is new and these problems existed way before AI (or cloud, or computers!).
You saved time in the wrong place #
The Goal (Goldratt, 1984). “An hour saved at a non-bottleneck is a mirage”. There’s no point speeding up writing code if the release process takes a quarter.
Amdahl’s Law (1967). A variant of the Goal from parallel computing “the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used”.
Parkinson’s Law of Triviality (1957) - Committees focus on what they understand rather than what matters (boilerplate, commit messages, meeting notes, argh!). AI makes optimising these things much easier to imagine than before, whether or not it’s actually a genuine constraint.
You automated stupidity #
Don’t Automate, Obliterate (Hammer1, HBR July-August 1990) - “Stop paving cow paths”. Applying technology to a bad process just builds a fast bad process. Reimagine it instead!
No Silver Bullet (Brooks, 1986). Accidental complexity versus essential complexity. AI is good at the accidental stuff, but the hard stuff is the essential complexity which is where your time goes!
Ironies of Automation (Bainbridge, 1983). Automation “can make the difficult parts of the human operator’s task more difficult”. AI writes code, humans find it harder to review code. And since they are no longer writing code they find it harder. Repeat.
MABA-MABA or Abracadabra (Woods and Dekker, 2002). The assumption you can automate part of a human’s work without changing the system is wrong. It changes who has to coordinate with whom and what they can see. Ten engineers plus agents, is not ten engineers of output plus agents. It’s a new system.
What to do instead? #
AI doesn’t change the underlying problem. You’re still dealing with a system.
All of the references above have similar solutions to the problem.
- Take a bit of work and understand how it flows through the system. Make sure to mark every point in the system where it got stuck and what it was waiting for.
- Add up the waiting time. Everything that isn’t moving is waiting. If a change with three hours of work took nine days to ship, then that’s about 96% of a working days’ time sitting still. Double the speed of the three hours work and you’ve saved ninety minutes. Fix the release process and you’ve saved much more.
- Focus on the most expensive queue; not the most irritating one.
- Before you automate it, ask whether it should even exist. Automating the wrong thing just makes it permanent and much harder to argue with.
- Whatever survives, automate it!
And then do it again because as soon as you do, the constraint will move somewhere else.
AI agents are a new thing; applying systems thinking to speeding things up isn’t.
Focus on the systematic approach and layer on some AI (where needed) and you might just see those improvements.
1 Author is called Hammer, he’s written a paper called Don’t Automate, Obliterate. There’s a really good pun in there somewhere, but I haven’t found it yet!