The Constraint Has Moved: AI, the Theory of Constraints, and the Org Around Engineering
TL;DR: I have spent thirty years watching engineering be the constraint. Every other function in the business — security, risk, compliance, marketing, sales enablement, finance — was quietly sized and paced around the assumption that new capability arrives slowly. AI has broken the engineering constraint faster than anyone modelled, and Eliyahu Goldratt’s Theory of Constraints tells you exactly what happens next: the constraint does not vanish, it moves. It has moved into the org around engineering, and it is now exposing every function that was merely adequate in a slow-moving world. The board-level mistake is to keep investing in the thing that is no longer the constraint. This article is about finding the new one, and re-pacing the whole organisation to a faster drumbeat.
The one thing every board currently believes that is wrong
Ask most boards where their delivery bottleneck is and they will tell you, without hesitation, that it is engineering. It always has been. Product wants ten things, engineering can build three, and the entire discipline of roadmap governance grew up to manage that scarcity — prioritisation frameworks , capacity planning , WIP limits , the lot. I have written most of it down on this blog. When I argued that you should limit work in progress , I said plainly that “in software product teams, your constraint is almost always your development process,” and that everything else should subordinate to its pace. That was true when I wrote it, and for most of the thirty years before it. The unspoken premise underneath the whole discipline was: engineering is the constraint, so subordinate everything to engineering’s pace.
That premise is now, for a growing number of companies, coming apart — and the honest thing to do is to say so, and to work out what replaces it. Goldratt would have expected exactly this. A constraint is never a permanent property of a system; it is wherever the bottleneck happens to sit today. Elevate it — and AI has elevated engineering violently — and the constraint moves. The advice to subordinate everything to engineering was correct precisely as long as engineering was the drum. The moment that stops being true, the same Theory of Constraints that told you to protect engineering tells you to go and find where the constraint went.
I am not going to try to sell you a particular number for how much faster AI-assisted teams are. The honest answer is that it varies enormously by domain, and anyone quoting you a single multiplier is selling something. But I will tell you what I have now seen with my own eyes, more than once: teams standing up genuinely new capability — not autocomplete on existing code, new product surface — in days rather than quarters. When that happens, something breaks in the org that most leadership teams have never had to think about. The constraint moves, and it moves somewhere you were not watching.
Goldratt’s inconvenient theorem
The Theory of Constraints has one central, uncomfortable claim, and every board should have it tattooed somewhere visible:
An improvement at a non-constraint is a mirage.
Goldratt put it more sharply: an hour saved at a non-bottleneck is worth nothing, because the bottleneck still sets the pace of the whole system. You can make every non-constraint resource in your factory twice as fast and your output will not increase by a single unit. The only improvement that matters is an improvement at the constraint.
Sit with what that means in the AI moment. Your board has almost certainly approved spend on AI coding tools, and your engineering leaders are almost certainly reporting productivity gains. Both things can be completely true and completely worthless to the business — if engineering is no longer your constraint. You have poured investment into speeding up a resource that was not setting the pace. That is not a productivity win. It is, in Goldratt’s exact sense, a mirage. The units out of the end of the system — customers successfully using new capability — have not moved, because the thing actually gating them was never the code.
This is the single most important reframe I can offer a board right now. The question is no longer “how do we make engineering faster?” Engineering will get faster whether you help it or not. The question is: once engineering is fast, what is the new constraint, and are we investing there instead?
Where the constraint went: a capability that died in a week it took a week to build
Let me give you the sharpest example I have. Two teams at an organisation I know used AI tooling to build two brand-new capabilities in roughly a week each. Real capability, demonstrably working, genuinely valuable. By the old drumbeat this was a two-quarter programme, and it had arrived in a fortnight.
It never shipped. It died completely.
It died because the new capability needed a new hosting environment, and the security function and the risk-and-compliance function — both entirely competent, both perfectly good at their jobs — had been built for a world in which a new hosting environment showed up maybe once every couple of years. Their processes for assessing and signing off a novel environment were measured in months. They were not being obstructive. They were doing exactly what they were designed to do, at exactly the pace they were designed to do it. But they had become the constraint, overnight, without anyone deciding they should be, and the organisation had no mechanism to elevate them fast enough. The project sat in the buffer in front of the new bottleneck until it went stale and was quietly killed.
Read that failure carefully, because the temptation is to file it as “the security team was too slow” and move on. That is exactly the wrong lesson. The security team was appropriately paced for the old constraint. What changed was the drumbeat. When engineering was the pace-setter, a compliance process that took three months was invisible — it comfortably fit inside the eighteen months it took to build anything worth deploying. The instant engineering stopped being the constraint, that same three-month process became the thing that killed the company’s newest bet. Nothing about security got worse. Everything about its context changed. The organisation’s immune system rejected the transplant, not because it was faulty, but because it had never been asked to work at this speed.
The constraint you will meet constantly: go-to-market
The dead-capability story is the dramatic version. The version you will meet every single week is quieter and, in aggregate, far more expensive: your go-to-market functions are not running at AI speed.
Here is the pattern. Product and Engineering, newly unshackled, are making and shipping good bets faster than ever. And Product Marketing either does not exist as a function at all, or — more insidiously — it exists but is running on a completely separate roadmap from P&E. The sales team has not been trained on the new capability. Customer success does not know it is coming. The campaign calendar was locked six months ago. So the capability ships into a silence. Nobody is positioned to sell it, nobody is trained to support it, and the beautifully-built new surface acquires precisely zero users.
This is the feature factory failure, but supercharged by AI and relocated one function to the right. It is not that the team built the wrong thing. It is that “built” was never the finish line, and the rest of the organisation is still treating it as though it were.
The root cause is almost always structural, and it is one I care about enough to have built a company around: the go-to-market functions are on a different roadmap. Product & Engineering plan on one plane, marketing and sales enablement plan on another, and the two are reconciled — if at all — in a quarterly meeting that assumes a slow drumbeat. That reconciliation cadence was fine when engineering took two quarters to build anything. It is catastrophic when engineering takes two weeks. The separate roadmaps have to become one roadmap , and enabling the commercial organisation has to appear on it, as first-class work, resourced and sequenced alongside the build.
Outcome, not output — the product team as quarterback
The fix is not a process tweak. It is a change in what “done” means, and it belongs at board level because it is a change to how you measure the whole system.
If your product team is making good bets, then training sales, enabling customer success, and positioning the capability in-market are not someone else’s problem that happens after engineering’s problem is solved. They are part of the same bet, and they belong on the same roadmap. The outcome you commit to must not be “the functionality is built.” It must be “N users are successfully using the new functionality.” The moment you write the outcome that way, the whole go-to-market machine is pulled inside the boundary of the initiative, because you cannot hit a user-adoption number with a capability that sales cannot sell and customers do not know exists.
This is what I mean when I say the product team has to quarterback the rest of the organisation. In the old world, product handed a spec to engineering and the constraint did the rest. In the new world, engineering is fast, and the product leader’s job becomes orchestrating every other function — security, compliance, enablement, marketing, support — so that they arrive at the goal line at the same time as the code. The quarterback does not run the ball themselves. They make sure ten other people are exactly where they need to be when the ball arrives. That is the org-level leadership the AI era demands, and most organisations have no one playing the position.
Drum-buffer-rope: re-pacing the whole business
Goldratt’s operational model for running a system around its constraint is called drum-buffer-rope, and it is the cleanest way I know to explain to a board what actually has to change.
- The drum is the constraint. It sets the beat that the entire system marches to. Everything else subordinates its pace to the drum.
- The buffer is the protection you place in front of the drum so the constraint is never starved and never idle.
- The rope is the signal that ties the release of new work at the front of the system to the drum’s pace at the back — so you never dump more into the system than the constraint can absorb.
For thirty years the drum was engineering. The whole business was roped to engineering’s slow beat, and that was fine, because everything was paced to match. Security sign-off, compliance review, campaign planning, sales enablement, hiring — all of it comfortably fit inside engineering’s cycle time. The organisation was in balance, marching to a slow drum.
AI did not remove the drum. It moved the drum — to security, to compliance, to go-to-market — and it sped up the old drum position so violently that the rest of the organisation is now roped to a beat that no longer sets the true pace. That is the mechanical description of every symptom in this article. The dead capability: a drum that moved to compliance while the org was still roped to engineering. The zero-adoption launch: a drum that moved to go-to-market while marketing was still marching to last year’s beat.
The board’s job — and it genuinely is the board’s job, because no single functional leader has the authority to do it — is threefold:
- Find the real drum. Stop assuming it is engineering. Walk one of your recent bets end to end and find the function where the weeks actually pile up. That is your constraint. It is almost certainly not writing the code.
- Elevate the real constraint. Invest there. If security’s environment-assessment process is now the drum, that is where the money, the headcount and the process redesign belong — not another seat licence for the coding assistant. Elevating a non-constraint is the mirage.
- Re-rope the organisation to the faster beat. Put every function on the same roadmap and pace them to the new drum. This is where suboptimisation gets addressed head-on.
The real enemy is suboptimisation
I want to close on the idea that a board most needs to internalise, because it is the one that the org chart actively fights against.
The sum of local optima is not the global optimum. Goldratt again, and it is the deepest thing he ever said. Every function in your business is measured locally. Security is measured on incidents avoided, so it optimises for saying no, slowly and safely. Compliance is measured on audit findings, so it optimises for thoroughness over speed. Product marketing is measured on campaign performance, so it optimises for its own locked calendar. Every one of those local optimisations is rational, defensible, and exactly what you asked for — and their sum is an organisation that took a capability it built in a week and spent six months failing to ship it.
Suboptimisation is not incompetence. It is what you get by default when a system full of locally-efficient functions loses its shared drumbeat. In a slow-moving world it was survivable, because engineering’s slow beat gave everyone enough slack to reconcile their local optima in the gaps. AI removed the slack. There is no longer a comfortable eighteen-month cycle inside which everyone’s local process quietly fits. The gaps are gone, and the suboptimisation that was always there is now exposed and lethal.
Do not ask your CTO “are we using AI?” You already know the answer, and it is the wrong question. Ask instead: “We just made engineering dramatically faster. Where did the constraint go — and are we investing there, or are we still spending on the thing that is no longer the bottleneck?” If nobody in the room can answer that with a specific function and a specific number, you have found your problem.
The organising idea
For thirty years, the entire discipline of running a technology business was built on one assumption: engineering is the constraint, so subordinate everything to it. That assumption held for so long that we stopped noticing it was an assumption. It became the water we swam in.
AI has drained that particular pool. The engineering constraint is breaking, and the Theory of Constraints is telling you, with complete clarity, that the bottleneck has not gone away — it has moved into the organisation around engineering, into the functions that were merely adequate when the drumbeat was slow. Making engineering faster will not help you. It is the mirage. The work now is to find where the constraint actually went, invest there instead, and re-pace the entire business — security, risk, compliance, marketing, sales, success — to a drumbeat that is suddenly, and permanently, much faster.
The train is going to keep speeding up. The only question is whether the rest of the organisation is still roped to the engine.
