Transformation is cross-functional by definition. So why do most programs get managed as if each function can deliver its piece independently?
The failure almost always comes from one of two places: too much control from a single function optimizing for its own metrics, or an abdication of leadership that leaves the cross-functional tradeoff unowned. Either way, the constraint compounds quietly while each function reports green.
It's an innocuous question that's easy to overlook but critical to the success of any cross-functional program — and all transformations, by definition, are cross-functional.
Who owns the constraint?
The technology changes. The organizational failure mode does not.
Boardrooms right now are consumed by the promise and the pressure of AI. Billions are flowing into digital transformation initiatives. Pilots are succeeding. Platforms are being built. And behind the scenes, a meaningful share of these programs are quietly stalling out.
The instinct is to blame the technology. Faulty data pipelines. Unrefined models. Legacy systems that won't cooperate. IT teams that can't move fast enough. These are real frustrations, and they're not wrong. But they're almost never the actual constraint.
The pattern that keeps showing up across the transformation programs I've seen stall, AI-related or not, looks like this: every function is performing. Every scorecard is green. The initiative is amber. And when you ask who owns delivery of the cross-functional result, the room goes quiet. Everybody contributes. Nobody owns it — so it gets escalated, and the sponsor gets pulled in as the de facto owner of a problem that should never have reached them. Progress waits on whoever is least available. Work starts, stalls, restarts, accumulates rework at every transition. The technology gets blamed. The real problem is organizational: no one person owns the decision, but every single person can veto it, right up to the last minute.
That problem was diagnosed precisely, forty years ago, by Eliyahu Goldratt in The Goal. His Theory of Constraints makes a deceptively simple argument: the performance of any system is determined by its constraint, not by the sum of its parts. A factory where every machine runs at full efficiency can still produce nothing if one bottleneck is starving everything downstream. Optimizing non-constrained functions doesn't improve throughput. It creates the illusion of progress while the real problem compounds. It's easy to see the bottleneck on a production line. It is much harder in today's distributed and virtual working environments, where the constraint hides inside coordination patterns and escalation habits rather than showing up as a physical queue in front of a machine.
The core constraint showing up in transformation programs today is not technical. It is organizational: nobody owns the cross-functional tradeoff. And the only thing AI has changed is the speed at which that absence becomes expensive.
Three levels. Three different expressions of the same failure. All of them hiding in plain sight.
This is the most common and the most quietly destructive version of the constraint problem. The symptoms are consistent regardless of industry or era.
A major initiative launches with genuine commitment. It immediately hits a dependency — the right analyst, the right IT resource, the right subject matter expert — already allocated to something else on someone else's roadmap. The initiative stops and waits. When the resource finally clears, the team ramps back up, rediscovers context, and pushes forward until the next dependency surfaces.
I've seen this in manufacturing networks where a company-wide program was declared complete while every site still had its own list of local customizations needed before the standardized design could actually work — eliminating the network flexibility and scalability the program was supposed to create. I've seen it in consumer lending operations where five separate VP-owned development teams were each making locally rational decisions that collectively prevented any cross-functional initiative from maintaining momentum. I've seen it in global supply chain programs where the sequencing of work across functions was effectively owned by whoever had the most urgent request that week.
The constraint in each case wasn't the technology, the talent, or the intent. It was the absence of a single owner with a shared view of priorities and resource availability across all functions. The real sign of a leader who understands this is the ability to foresee constraints before they materialize — to see initiative planning and resource allocation as a puzzle to be solved, not a checklist to be completed. That takes a fundamentally different kind of thinking than functional management, and it's almost never what the org chart provides by default.
This version of the constraint is more dangerous because it hides behind enthusiasm. Internal alignment is high. The product works. The market opportunity is real. And the pipeline is not converting.
The instinct is to blame the product — there's a feature gap, the roadmap isn't moving fast enough, if we just had X the deals would close. That explanation is convenient and almost always wrong. It directs attention away from the commercial functions and toward the team with the least voice in the room. The real constraint is almost always in the handoffs: marketing owns the top of the funnel, sales owns the middle, customer success owns the back, and nobody owns the system connecting them. Deals die in the gaps. The product gets the blame.
The symptoms: sales and customer success are reporting positive signals while conversion lags consistently. Value realization is being calculated by the team that needs it to land, not validated by the customers who are supposed to be experiencing it. Feature requests are accumulating as the explanation for every lost deal, with no structured process for evaluating whether any of them would have actually changed the outcome.
I've seen this at an investor-backed industrial AI venture where customers weren't converting from paid trial to full subscription — not because the product didn't work, but because the value story was being narrated by the commercial team rather than experienced independently by the customer. I've seen it in a B2B media business with five divisions, five different commercial models, and a platform implementation being planned before anyone had built a unified picture of what the commercial system actually needed to do. In both cases, the technology was ready before the commercial operating model was. And in both cases, the product took the blame for a constraint that lived entirely in the GTM structure.
The proverbial "all for one and one for all" is not a cultural aspiration in this context. It is a structural requirement. Someone has to own the full commercial system, not just their piece of it — with the standing to enforce the handoff discipline that distributed ownership never produces on its own.
The most impactful but hardest to self-identify version of the constraint problem lives at the level of strategy, because the people closest to it have the most invested in the current framing.
Organizations in crowded markets almost always invest in what their competitors are investing in, because those investments feel safe and defensible. What customers are asking for is rarely where the real constraint is. The constraint is almost always in the part of the system nobody has chosen to own yet — the gap between what exists and what the market actually needs, which incumbent players have every incentive to ignore.
The symptoms at this level are subtler. Investment portfolios that mirror last year's allocations, even if the results were a little off. Functions that can articulate exactly what they're building but not why it matters to the customer at that specific moment in their journey, or why it will matter six months out once it makes it to market. Technology decisions made before the strategic position was clearly defined. Executive teams that align in the room and reprioritize independently afterward.
I've seen this in the payments industry, where the real opportunity wasn't to build another participant in a five-party supply chain, but to collapse the chain itself — treating the structural constraint of the market as the product opportunity rather than the operating environment to be accepted. I've seen it at a major financial services business where mapping the full customer lifecycle with the executive team revealed that investment was overwhelmingly concentrated at the transaction moment, while the earlier stages where durable relationships are actually built were systematically underserved. Nobody had made a deliberate decision to underinvest there. It had simply never been owned. Once the map existed, the misalignment was undeniable — and a $250K prototype and three-market validation of a B2C shopping and engagement app followed directly from that conversation. The organization ultimately shelved the app in favor of a marketing-focused B2C website, but the conversation about where to invest had changed. I've seen it in healthcare, where shifting from negotiating individual services independently to owning the full patient episode as the unit of value unlocked a fundamentally different commercial and clinical position.
In each case, the constraint wasn't the market or the technology. It was the absence of a cross-portfolio view that anyone owned — and the willingness to ask where the gap actually was rather than where the competition was already playing.
There is a harder implication here that most organizations avoid naming. Identifying a gap in the market almost always surfaces a corresponding gap in internal capability. The existing organization was built around the existing definition of the market. A new definition requires new skills, new processes, and sometimes a fundamentally different operating model. This is precisely what is happening with AI investments today: organizations are committing capital to the promise of progress while the internal capability gaps remain unaddressed. The gap in the market and the gap in the organization are the same constraint seen from two different angles.
Three levels, three different failure modes, the same root cause: nobody identified, let alone owned, the constraint.
What Goldratt understood, and what most transformation programs still haven't absorbed, is that local optimization never produces system throughput. It never has. AI doesn't change that. It accelerates it. Every function performing well on its own metrics while the system underdelivers is not a technology problem. It is a constraint problem. And it is a leadership problem. Until someone owns the constraint — with the standing to see it coming before it materializes and the authority to subordinate local priorities to the system's actual need — no amount of additional investment in the non-constrained parts will move the needle.
Here is where most organizations get it wrong even after they've accepted everything above.
The hiring instinct in PE-backed transformation is to find someone who has done the exact thing you need done, three or four or five times before. The logic sounds reasonable: proven experience, faster ramp, lower risk.
The problem is that someone who has solved the same problem five times is almost certainly operating on automatic pilot. They bring the pattern that worked somewhere else. They apply it. They see what they expect to see. And they miss the specific constraint that makes your situation different from the last four.
The people most likely to find the actual constraint are the ones who bring genuine external perspective and diversity of thinking — practitioners who have worked across enough different industries, operating models, and functional domains to recognize the pattern without assuming the prescription. The value is in the diagnosis, not the playbook. They are not going to tell you what to do before they've mapped your system. They are going to ask the question the internal team stopped asking, because the internal team already knows the answer and has built the organization around it.
That is a different profile from "done it before." It is harder to evaluate in an interview. And it is almost always the hire that moves the needle — because it is the one that identifies where your constraint actually is, rather than importing a solution built for someone else's.
The question worth asking of every portfolio company at the start of an engagement: where is the constraint in this system, and who owns it?
If the answer is "we work it out between functions," that's not an answer. That's the constraint.
And if the instinct is to hire someone who has solved it before, ask one more question: are they going to see your constraint, or are they going to see the last one?
This is part of a series on value creation in PE-backed businesses (see all insights). Goldratt figured out the constraint problem in 1984. We're still relearning it, one transformation program at a time.