Find the Bottleneck Before You Automate Anything
Automating around a constraint just moves it somewhere worse. Find the real bottleneck first, fix ownership, and most of the tooling you were about to buy turns out to be optional.
Every team that asks me to "automate this" is really asking me to make a slow thing fast. The instinct is reasonable. The problem is that they've almost always pointed at the wrong thing. They want to automate the step that feels painful, which is rarely the step that's actually holding the system back.
So before I let anyone write a line of automation, I make them answer one question: where is the real constraint? Not the loudest step. Not the most annoying one. The single point that caps the throughput of the entire system. Until you've found that, you're not improving anything. You're just rearranging where the pain shows up.
Automating around a bottleneck just moves it
This is the part people resist, because it's counterintuitive. If your bottleneck is a two-day code review queue and you automate the deploy step instead, you haven't sped anything up. Work still arrives at the review queue at the same rate it always did. All you've done is build a faster road that dead-ends at the same traffic jam. Worse, now the jam is harder to see, because everything upstream looks healthy.
Theory of constraints has been saying this since the 1980s and it still holds: a system's output is governed by its single tightest constraint, and any improvement that isn't at that constraint is an illusion. Optimize a non-bottleneck and you don't get more throughput. You get more inventory piling up in front of the real one. In software that inventory is half-finished work, open branches, tickets in limbo, context that goes stale while it waits.
Most bottlenecks are accountability problems wearing a tooling costume
Here's what I find when I trace the constraint to its source: it's usually not a missing tool. It's a missing owner. The deploy is slow because nobody owns the release. The review queue backs up because review is everyone's job, which means it's no one's. The handoff between two teams stalls because the work lives in the gap between two org charts and falls to whoever happens to notice.
You cannot automate your way out of unclear ownership. If you point an agent or a pipeline at a process that no single person is accountable for, you've automated the confusion. It now runs faster and fails more quietly. The fix that actually moves the number is boring and human: name an owner, give them the authority to match the responsibility, and make the constraint visible enough that they can't ignore it.
- Map the flow end to end and measure where work waits, not where work is hard.
- Find the one step where the queue is longest, that's your constraint, everything else is noise.
- Ask who owns that step. If the answer is a team and not a person, that's the real problem.
- Fix ownership and visibility first. Only then ask whether automation removes the constraint or just feeds it faster.
- Re-measure. The bottleneck will have moved. Repeat. It never fully goes away, it relocates.
Where automation actually earns its keep
None of this is an argument against automation. It's an argument for aiming it. Once you've found the true constraint and put a clear owner on it, automation becomes surgical instead of speculative. You're not buying tools and hoping. You're removing a specific, measured limit, and you can prove it moved.
When I've done this well the results are dramatic precisely because they're targeted. Pointing LLM-powered data agents at a genuine processing bottleneck cut processing time by 90%, not because the model was magic, but because I'd already confirmed that was the constraint worth attacking. The same discipline took teams from low to elite DORA performance in about 90 days: find the constraint, fix the ownership around it, then automate what's left. This is the unglamorous core of AI-native transformation, the constraint thinking has to come before the tooling, or the tooling just makes a confused system confused at scale.
The shift worth making
As AI makes it trivial to automate almost anything, the scarce skill isn't building automation. It's knowing what not to build. The teams that win the next few years won't be the ones that automated the most. They'll be the ones that found their real constraint, put a name next to it, and pointed their leverage at exactly that. Everything else is motion. Find the bottleneck first. Then, and only then, automate it out of existence, and go find the next one.