Over the past decade, more than half of large companies have tried to modernize their operating models. These efforts have different names: agile, product and platform, digitization, new ways of working. Fundamentally, they all chase the promise of increased agility, speed, efficiency, and customer centricity by improving structures, workflows, culture, and skills. But for many organizations, gains have proved elusive.
“We just completed a major operating model transformation, including new quarterly planning processes and cross-functional agile teams, yet I am not seeing any changes to our performance,” the CFO of a European telecommunications company told us. “We’re facing increasing labor costs in next year’s budget, and employee and customer engagement metrics are flat. All that work, and what did it get us?”
We’ve heard the same from many senior executives: Their operating model transformations have not delivered the hoped-for benefits, or the changes have been temporary. Many frustrated transformation leaders feel that their programs are dragging on or have been marginalized into something that has barely affected how the company operates. Sometimes the promised efficiency gains from new ways of working, digital initiatives, and culture changes are nowhere to be seen, and the costs creep back in.
McKinsey’s newest research on operating model redesigns shows that 63 percent of companies have met most of their transformation objectives and improved their performance—though only 24 percent are highly successful. While these numbers are higher than a decade ago, they still reflect the fact that a large slice of companies don’t achieve their full value potential.
In our discussions with dozens of companies, we have started to see a pattern that holds operating model transformations back. In this article, we discuss six common pitfalls that transformations face across operating model archetypes—and how leaders can secure the benefits of a successful change program that creates value.
Challenges with the ‘why’
Organizations typically pursue operating model transformations to reduce costs, enhance employee engagement and sense of ownership, and get things done more quickly. In all cases, the targeted improvements should translate to specific goals—for instance, launching new revenue streams faster or improving customer experience. The first pitfall occurs when that link isn’t made.
Pitfall 1: Goals aren’t clearly linked to the transformation
Leaders’ aspirations for “more empowerment,” “a greater focus on value,” “improved customer centricity,” or “becoming AI and digital first” are no substitute for clearly stated objectives. In the case of the telecommunications company, the CFO was quick to admit that there had been no quantified goals tied to the program, which meant that new cross-functional units, or “tribes,” operated without hard budget constraints and were allowed to set their own goals instead of tying them to the strategy.
The situation was more nuanced at a European bank. Its operating model renewal team had initially set bold, quantified goals, but the team never shared those objectives with business unit leaders. The metrics and ownership of various initiatives were also unclear. Upon closer review, the company realized that its transformation goals were not directly linked to day-to-day success metrics, such as business line profitability, nor to its strategic goals, such as digitalization. It was no wonder transformation objectives came in second to the real business performance-related goals that leaders were tracking.
Transformations that lack clear targets lose momentum and relevance. Instead, the best transformations present a combination of operating model metrics (for example, efficiency and speed) and concrete, quantified business benefits (for instance, margin improvements from reduced costs driven by digitalization). These goals should be easy to understand and spur decision-making toward the right option during pivotal moments.
Omissions in the ‘what’
If you imagine your old operating model as a horse, simply replacing its front legs with wheels doesn’t make it a race car. As new McKinsey research shows, the operating model should be understood as a holistic system that can turn strategic potential into market-beating results. But when companies try to change just a part of their operating model, they can hit one or more of the four following pitfalls.
Pitfall 2: New units lack clarity about strategic goals
For a new operating model to take hold, it’s important to ensure that the strategy is translated into structure across the entire organization. After all, delivering end-to-end improvements is a team sport.
In practice, this means defining the fixed key performance indicators for which each business unit is responsible (such as margin and customer satisfaction), as well as dynamic goals for each (such as improving throughput by 20 percent in the next quarter). A good way to ensure this clarity is to construct a value driver tree for performance and link each unit and team to a branch. That way, everyone knows their role in achieving success for the company.
The challenge is that delivering end-to-end improvements is often a cross-functional endeavor. Take, for example, managing products, where the organization has to bring together different lenses. These are customer facing (service design, customer experience, research, and analytics), commercial (product management, marketing, and partnerships), and technical (architecture, engineering, testing, and data). In a manufacturing company, improving performance requires combining maintenance, operations, engineering, purchasing, health and safety, and other lenses. In retail, managing category profitability requires working across assortment, purchasing, supply chain, merchandising, and analytics.
Companies often start with good intentions to bring together different functions to deliver real value, but they are held back by long-standing complex and siloed structures. As they attempt to design a new structure, each functional or business unit is tempted to stay away from the end-to-end design to protect the status quo.
For example, at one bank aiming to create a flat structure with end-to-end accountable value stream units, the resulting design looked great on the surface. In reality, each team was just a translation of the old structure. There was a strategy team handing over goals to a product management team, which in turn approached a solution architecture team that delivered feature requests to a developer team. Getting anything in front of the customer took months, despite all the agile practices each team was trying to implement.
The European telecommunications company we discussed earlier was adamant about relying on cross-functional teams in its initial operating model redesign. However, in the months that followed, each function gradually started to pull back its resources, and the remaining squads were unable to deliver end-to-end value. Interviews with team members revealed that the culture was biased toward people spending all their time in cross-functional squads, while the functions, called chapters in this model, played a staffing and HR role.
Because the functions rightly felt the need to safeguard functional excellence, they created their own squads in areas such as standards for testing and the design library. To find a balance, the organization clarified the role of chapters to cover consistency, capability building, and functional vision in addition to people management. This centralization of functional excellence then allowed the movement of people to cross-functional squads.
The telecom company’s experience shows that those leading the transformation can act as catalysts for aligning structure to strategy. This means constantly bringing the value and customer angle to the game. Even more important, it means navigating the organizational politics that pull the company back from change.
Pitfall 3: Technology and data changes are pursued separately from organizational changes
In 1967, Melvin Conway coined his famous law stating that technical systems mirror the organizational structures operating them. This means that if the technical parts of the organization are under one big department, create changes through multiyear projects, rely on lots of outsourcing, and are treated as cost centers, then IT systems are also built as monolithic and complex systems that cost relatively little to operate and a lot to change. This interlinkage presents a difficult choice: If an organization wants to move to a faster operating model with business and technology tightly integrated in cross-functional teams, does it first modernize technology and then change the structure, or does it move the people and hope technology evolves to support them?
Many organizations get stuck with this chicken-and-egg problem. Sometimes they accept current technical limitations and decide to wait until the legacy decommissioning project is completed (which often ends up being years in the future) before changing the operating model. Or they try to implement the full end state organization without investing in the development practices, infrastructure, and architecture needed to support modern distributed development and, as a result, cause more confusion than clarity.
One Latin American bank pushed to decentralize most of its engineers so they could sit next to their business counterparts in cross-functional teams, develop new features faster, and become more customer centric. This move was a success initially, but soon the bank discovered that it had not addressed its key IT processes, such as code testing and release to customers. Centralized pipelines for managing releases led to long delays in getting features to production, while decentralized testing capabilities meant code changes were being tested on a unit level but not when integrated. Only after the bank pursued a technological transformation years later did it get the benefits of speed and stability it had hoped to unleash from the start.
Meanwhile, one consumer goods company established cross-functional teams to deliver brand and product outcomes, but it left data in the hands of the old functional constructs. The data department did nothing to democratize access to data and insights, which created a bottleneck and reduced the efficiency of agile teams that depended on this data.

Organize to Value
Build your operating model with value at the core
Organizations that have succeeded with large-scale change programs have accounted for technological changes within their overall transformation road maps. They determine which systems most need agility—for instance, digital channels or specific products or platforms—and what it would take to safely decouple them through technical changes. Such changes could include structural considerations, such as placing tech leads in business units, or holding cross-functional units accountable for technical health and the product life cycle rather than just feature development, and so on.
Organizations should move on both fronts: Waiting for a pure technology transformation to solve legacy problems is a fool’s errand, but trying an operating model transformation without addressing technology is perhaps just as bad.
Pitfall 4: Budgeting, prioritization, and resourcing workflows are not aligned to the operating model
Establishing end-to-end teams with full accountability over business results requires a different approach to budgeting and funding. Once the transformation reaches scale, it is challenging to maintain visibility and alignment using traditional approaches. Instead, companies should institute a different rhythm for reviewing performance, planning ahead, and communicating a cascading set of priorities—such as through a quarterly business review (QBR) or product increment planning (PIP).
We see a huge variation in the logic, scope, and quality of the QBR process in different companies. For example, one large telecom company introduced a QBR, but it was run by agile coaches; senior business executives were not sufficiently involved. As a result, there was little top-down guidance on prioritization, and funding and budgeting were not linked to decisions. The planning cycle was fragmented across multiple initiatives. The fix was clear: Bring in finance, strategy, HR, the project management office, and the coaching community to jointly design an integrated governance cycle across the different control functions instead of having a separate QBR “on the side.”
At the Latin American bank, the process was more integrated and systematic from the start, but several important shifts were not properly internalized. First, the funding logic was still based on large projects approved by steering committees instead of product-based, flexible funding. Second, the focus was on control and certainty, with significant time spent on business case templates, approvals, and backward-looking tracking. Third, the focus of joint discussions was on deliverables and aligning road maps rather than value creation.
To overcome these difficulties, the company introduced the concept of fixed-envelope funding, in which units were given a stable budget and had to prioritize outcomes within the unit instead of asking for more. It also scaled the QBR to cover the entire company rather than just those using cross-functional agile teams.
The concept of fixed-cost envelopes is central. At another European bank, upon seeing costs creep up in the agile perimeter, the CEO installed a very strict "fix the capacity and prioritize within it” rule. Not only did this keep cost proliferation under control, but it also led to discussions on what to prioritize and how to deliver value.
While it may seem counterintuitive, deploying intentionally lighter-weight and less granular long-term planning processes, done every three to five years, can result in actionable aspirations for each year. In this approach, strategy processes are not conducted every year to avoid repeating the “hockey stick” problem of constantly moving target timelines further out. Instead, each annual cycle focuses on how to deliver the agreed-upon goals for that year, allocating funding for operating and capital expenses to stable end-to-end accountable units.
In this approach, the QBR takes as input the latest reforecast, competitive situation, and strategy, together with possible new wild card ideas, to ensure alignment on what outcomes to target during the next 90 days. This is done with strong vertical and horizontal collaboration, including boldly reallocating resources (for example, 5 to 10 percent every quarter) based on where the value is. Leaders’ focus is on delivering tangible outcomes in prioritized areas rather than starting a lot of things in parallel.
Pitfall 5: Culture and leadership remain unaddressed
Having inspirational posters in the elevator and inviting external gurus to speak about the importance of agile mindsets is not enough to truly change the real cultural and leadership DNA of a company. At one global airline, the head of its operating model and culture transformation explained how “we use great words like empowerment and psychological safety in our speeches, but when you look at who gets promoted and how, the true message is starkly different.”
It’s tempting to skip culture and leadership when it comes to transformation because they are topics that can feel fluffy, or outside of things one can control. The reality, however, is that there are proven, tangible steps companies can take to ensure that change truly happens. Those that have driven successful operating model changes consistently report culture change as the most difficult yet important lever. In addition to explicit top-team commitment (not just passive buy-in), what are the signature moves that pay off?
First, take a look at how well the organization’s people and rewards model (roles, careers, remuneration, performance management, incentives, and contracts) supports the behaviors leaders are trying to create. For example, if the push is for increased flexibility, working in teams, and collaborating across the company instead of building a silo, are those supported by the way leaders set goals and talk about career growth? Or do you still do job grading based on static role descriptions combined with yearly bonus targets?
Second, as leaders are chosen for key roles, do they reflect safe bets, meaning incumbents with functional expertise and tenure, or bold moves in terms of embodying the leadership, passion, and vision that should be modeled? Sometimes excitement about an operating model change dissipates when people see that new agile business units will be led by the same people who led the siloed and slow departments before the transformation.
Third, has the desired culture change been defined (for instance, from silos to one team and from escalation to ownership)? Have enough big moves been launched, including asking leaders to commit to the shifts publicly, doing explicit and deep enough trainings on the new behaviors, and embedding culture in the evaluation frameworks? Does the organization measure progress on these moves with the same attention it pays to business performance?
Lack of rigor in the ‘how’
Creating the holistic change required to truly transform the operating model is no easy feat. McKinsey’s 2021 agile-transformation research revealed that businesses that transformed successfully first invested enough time so that the top team was truly aligned, then made a commitment to drive the transformation through with speed (in fact, being ready in less than 18 months resulted in 1.6 times the chance of success).
For a larger company operating in multiple countries, a transformation typically progresses business unit by business unit, or country by country. While the center can play an important role in supporting the units—rotating transformation team members and ensuring that core processes such as budgeting cycles and people evaluation processes are fit for purpose—it is the individual units that need to be in the driver’s seat.
Whatever the unit of change, the team should execute the plan with rigor. Many fail, leading to the final pitfall.
Pitfall 6: Top-down leadership in the transformation is lacking
In a telling example of this pitfall, we discussed modern operating models with a group of senior leaders at another large telecommunications company. After the meeting, one of the participants introduced himself as the “group head of agile and operating model transformation.” He said he was surprised at how new the material seemed to some of the business leaders, since the company’s operating model transformation had been underway for three years.
We see this pattern quite often: delegation of the transformation too far from the top team, multiyear timelines lacking a sense of urgency, and execution done in a silo. And while transformations set up like this often start with great speed in the design and ideation phase, they lose momentum when the true mandate for change is lacking.
Lack of leadership can show up in other ways. Another bank pursuing flat and agile structures decided to allow rare exceptions: Units spanning multiple countries could have an extra layer between the unit’s lead and cross-functional squads. However, in the months that followed, these roles mushroomed as most of the managers designing the new structure opted to create this additional management overhead role. Taking this comforting crutch away and embracing the original intent was not an easy move.
A lack of CEO commitment to the transformation can be terminal, but having other senior leaders who aren’t committed can also cause damage. At one IT services company undergoing a large operating model transformation, the top team had made its decision to launch, yet one top-team member was still behaving as a blocker. This dragged on for months until the CEO made the decision to release him. The energy level of the entire transformation skyrocketed.
A good rule of thumb is that, in addition to full senior-leader commitment, creating an effective transformation can take about four hours a week from every top-team member for the main phase of the transformation (typically six to 12 months). A reaction such as “that’s too much time” can be a symptom of two different problems. Either there is a lack of understanding of the breadth and depth of changes needed across the elements of the operating model, or the transformation’s targeted benefits are too small to merit 10 percent of the top team’s time. The solution is to be clearer and bolder about what the organization is aiming for—in essence, fixing pitfall one.
Staying on track
There are multiple ways to falter in an operating model transformation. But if leaders keep their eyes on the prize (avoiding pitfall one), make sure to drive comprehensive change across the elements of the operating model (steering clear of pitfalls two through five), and drive change with speed and rigor (not getting stuck in pitfall six), they are likely to stay on a productive path (see sidebar, “How leaders can assess a modern operating model transformation”).
Comparing notes with leaders whose companies have undergone or recently completed an operating model transformation is another way to spot hidden dangers. In addition, it’s important to have regular and honest conversations within the leadership team about whether the program is going as planned and where there is risk of hitting a pitfall. Sometimes, figuring out what is working and what isn’t requires a systematic diagnosis, though quite often, watercooler conversations can reveal the true status of a transformation.
The six pitfalls we discuss here are common manifestations of the challenges that have been plaguing transformations for years, and most organizations will face them at some point in their journey. The real differentiator is what companies do when they realize the transformation is stuck. Do they keep spinning their wheels and hope for the best, or do they reassess the situation and make big enough moves to regain traction? In our view, a wait-and-see approach seldom works.