Most organizations still manage work as if the world were a set of independent tasks. If every team gets "20% faster," the organization should get 20% faster. If you add capacity, throughput should rise. If you automate a function, the business should feel it immediately.
That mental model breaks the moment work becomes a chain: step A feeds step B feeds step C, with mandatory handoffs and unavoidable variability. In chains, speed is not additive. Delays propagate. A small slowdown early becomes a large queue later. A "speedup" in the wrong place becomes inventory. The system is governed by its constraint, and the constraint is indifferent to your intentions.
Theory of Constraints teaches this with a story that is deliberately unglamorous: a troop hiking in single file. On paper, their average pace should predict their progress. In reality, they fall behind. The line stretches, collapses, and stretches again. The leader tries the obvious fixes--push harder, shorten breaks, tell the fast kids to move faster. Nothing works. Eventually it becomes undeniable that the troop moves at the pace of the slowest hiker. In the film the slow kid is called Herbie. When Herbie slows down, everyone behind slows down. When Herbie speeds up again, the gaps don’t magically disappear; they turn into waiting later. Put Herbie at the front so the system’s pace is visible, then lighten his pack so he can walk faster, and the troop’s throughput changes dramatically--not because everyone improved, but because the constraint did.
That story is manufacturing. It is also software. It is also "white-collar work." It is any operation where outcomes depend on dependent steps under uncertainty.
Once I internalized that, I started seeing a repeating managerial failure mode: people optimize what is easy to count instead of what governs flow. They measure local activity instead of end-to-end delivery. They reward being busy instead of finishing. And when results disappoint, they add more coordination because it feels like control.
AI is going to amplify this failure mode.
AI makes it cheap to create work products--drafts, plans, code, analyses, customer replies. It increases the arrival rate of "work" into an organization. If the constraint is where AI accelerates, you feel leverage. If the constraint is elsewhere, AI mostly manufactures inventory: started-but-not-finished work that piles up in front of the real bottleneck.
Inventory in TOC is not only physical goods. It is anything "done locally" but not yet converted into delivered value. In a factory, it’s work-in-progress. In a software organization, it’s half-integrated features, PRs waiting on review, designs waiting on approval, deployments waiting on environments, "almost done" projects waiting on a change window. Inventory looks like progress until you realize it’s also delay, risk, and cognitive load.
A CEO recently wrote a clean, practical version of this idea from outside tech. David Heacock runs Filterbuy, a U.S. air-filter manufacturer and e-commerce business. His point wasn’t that AI replaces plumbers or factory workers. His point was that many practical businesses are throttled by the administrative drag around the real work: scheduling, dispatch, estimates, invoicing, follow-ups, forecasting. Remove that drag and the same skilled crew can move more value through the system. The work itself doesn’t change; the scale does.
I agree with him because it’s a constraint story. If dispatching is the constraint, elevate dispatching. If forecasting errors are the constraint, elevate forecasting. You don’t win by making the non-constraint shinier. You win by changing the governing limit.
The Phoenix Project made the same argument in IT form. People remember it as a DevOps parable, but its deeper lesson is about flow: dependent work plus variability creates queues, hidden inventory, and long lead times. Teams can be fully utilized and still deliver little, because utilization is a local metric and delivery is a system property. The book’s villains are not "bad engineers." The villains are local optimizations: starting too much work, batching too much change, treating firefighting as normal, and mistaking ticket throughput for business throughput.
This is where many AI programs are heading right now: toward the illusion of progress. When AI makes the front of the pipeline faster--writing, producing, answering, generating--leaders see activity and dashboards improve. Resolution time drops. Tickets close faster. Output rises. Then, later, the organization realizes the business is worse off.
Nate Jones describes a version of this through Klarna. The headline numbers were seductive: huge volumes of customer conversations handled by AI, faster resolution, savings celebrated. Then the backlash arrived: generic answers, robotic tone, poor judgment on edge cases, reputational damage, customers angry, leadership forced to rebuild what they cut. The important framing is that the agents didn’t "fail." They succeeded at the wrong goal. They optimized for what was measured and rewarded--fast resolution--while undermining what the business actually needed--trust, retention, lifetime value, relationship quality.
This is not an "AI isn’t nuanced" story. It’s a local-optimization story. It’s the same mistake as pushing the fast hikers to walk faster while Herbie still governs the troop’s pace. Or, in factory terms, it’s running upstream machines at full speed while the bottleneck station is already overloaded, guaranteeing that work-in-progress piles up and lead time worsens.
What Klarna missed wasn’t "better prompts." Klarna missed intent.
Nate calls the missing layer "intent engineering": turning goals, trade-offs, and decision boundaries into something operational so autonomous systems optimize for what the business truly cares about, not what is easiest to count.
I use different language for the same idea. I think in terms of outcomes, success signals, and decision rights. I think in terms of Mission Command (auftragstaktik): in complex, chaotic environments, you cannot micromanage every move; you must clarify intent and constraints so decentralized actors can make good decisions. If you don’t, people operate on vibes, and the only "clarity" you get is whatever shows up on a dashboard.
Agents make this requirement harsher, not softer. Humans can sometimes fill in gaps with tacit judgment and culture. Agents can’t. If the only crisp thing you give an agent is "close tickets quickly," it will close tickets quickly. That is not intelligence; it is obedience. When the organization then acts surprised by the outcome, it is really surprised by its own underspecification.
I’ve watched the same pattern inside software organizations, just with different vocabulary. In a recent assignment, building a production-ready API façade was not the slow part. The slow part was converting "done code" into production value: environment access, deployment pathways, infra-team gating, ownership ambiguity, consensus rituals, calendar latency, and the general absence of anyone who could say "yes" quickly inside a bounded context. The result was predictable: upstream capability produced inventory--more "ready" work--while the system’s drumbeat remained unchanged. The organization experiences this as "that’s just how long it takes." TOC says: no, that’s how long your constraint takes, and you are refusing to manage it.
This is where Drum–Buffer–Rope matters in practice.
The drum is the pace set by the constraint. In many modern organizations, the drum is not engineering output; it is the sustainable rate at which the organization can safely absorb change into production without chaos. The buffer protects that drumbeat from variability--enough ready-to-ship work to keep the constraint fed, but not so much work-in-progress that everything becomes a swamp. The rope is the discipline that prevents upstream overproduction: don’t release work into the system faster than the constraint can finish it.
Klarna’s case is what happens when you cut the rope, worship the wrong dashboard, and then act shocked that the system optimized locally. If your KPI is resolution speed, you will get resolution speed. If your KPI is cost savings this quarter, you will save cost this quarter. And if the actual business constraint is trust and retention, you will quietly damage the thing that governs your long-term throughput.
The uncomfortable conclusion is that "AI strategy" is usually not a model question. It is a management question. It’s about whether leadership understands the difference between local efficiency and global throughput, and whether they can express intent with enough precision that humans and agents can act without creating downstream damage.
Organizations that get this right will look almost boring from the outside. They won’t brag about chatbots. They will do the unsexy work: identify the true constraint, stop overproducing inventory upstream, encode intent and boundaries so agents optimize for real outcomes, and replace meetings-as-control with mechanisms-as-control--verification, feedback loops, and clear decision rights inside bounded contexts.
Organizations that get it wrong will also look boring, but in a different way: perpetually busy, perpetually "transforming," drowning in work-in-progress, and confused about why capability didn’t translate into outcomes. They will keep buying faster hikers, and will keep ignoring Herbie.