Your operating model isn’t broken. It’s just slowing everything down.
Nobody ever announces this in a meeting. There’s no crash, no siren, no Slack thread titled “Our operating model broke”. Instead things just take longer.
Approvals multiply.
Handoffs get complicated.
A two-week task takes two months.
And everyone blames “the process” without noticing that the process is the operating model.
It’s like boiling a frog, except the frog is your delivery speed and the water is governance.
Here’s a distinction worth tattooing somewhere visible: your business model is how you make money.
Your operating model is how you deliver value.
One lives in investor decks, the other lives in calendars, sprint boards and approval chains.
They’re related, but they’re not the same, and the second one is where organisations lose their edge.
McKinsey’s research found that even top-performing companies achieve only about 70% of their strategies’ full potential. Operating model shortcomings are a major reason.
Almost a third of your strategic value left on the table.
A Quick Stress Test Before We Go Further
Before we dig into why operating models fail and what makes them work, try this. Five questions. Be honest (nobody’s grading).
- Does your operating model accelerate delivery or slow it down?
- Are you funding projects or products?
- Do teams own outcomes end-to-end?
- Can you ship weekly without executive escalation?
- Does your tech architecture support your organisational structure?
If most answers were “no” or “not really” then keep reading. If all answers were “yes”, then also keep reading. Confidence is sometimes the last thing to go before reality hits.
What Is An Operating Model?
An operating model is the blueprint for how an organisation delivers on its business strategies. It connects organisational structure, governance, business processes, technology enablement, talent and decision rights into something that (ideally) works together.
Think of it as the organisational architecture behind your value proposition, the thing that turns strategy into output. Or, less charitably, the thing that sometimes turns strategy into meetings about strategy.
Operating model examples come in different shapes.
- A centralised model keeps decisions and resources tightly controlled at the top: consistent, efficient, sometimes slow.
- A product-based model organises around products or customer segments, giving teams more autonomy and agility.
Neither is inherently better. The right one depends on what you’re delivering and how fast the market around you is moving (spoiler: probably fast).
Then there’s the gap between where you are and where you want to be: your current state versus your target operating model.
The current state is how things work today:
- The real workflows;
- The real bottlenecks;
- The real decision paths;
- The meetings that could have been emails.
The target operating model is the designed future state aligned with your strategic objectives. Most organisations have a version of both.
The trouble starts when nobody measures the distance between them honestly.
Why Most Operating Models Fail
Operating models don’t burst into flames on a Tuesday, they erode. A layer here, a committee there, an approval step that made sense once but now adds a week to every decision.
And then someone asks “Why does everything take so long?” and nobody has a good answer.
McKinsey’s research on operating model redesigns paints an interesting picture. 63% of companies have met most of their transformation objectives. Sounds reasonable until you realise that only 24% were highly successful. And that’s actually an improvement over a decade ago.
The failures tend to follow a few familiar patterns.
They’re designed for control, not speed
Operating model work starts with good intentions: let’s create clarity, let’s define governance. But governance has a gravity problem – it accumulates.
More approvals, more committees, more people who need to say “yes”. McKinsey emphasises that a well-designed model should accelerate execution, not add layers of friction.
Yet many organisations optimise for risk avoidance over productivity and then wonder why their competitive advantage is doing a slow moonwalk off the stage.
They ignore technology reality
Organisational charts can be redesigned in a workshop, but legacy systems cannot. A new operating model might call for cross-functional squads and seamless data-driven collaboration. But if your tech stack is a collection of siloed systems held together with custom middleware and good vibes, the org design is already disconnected from reality.
As Deloitte’s research on technology operating models puts it, legacy systems, traditional project management techniques and complex integrations all pose direct challenges to organisational delivery speed. And most technology organisations are still stuck in that hybrid state, caught between old infrastructure and new ambitions.Teams are told to streamline and collaborate, then discover they can’t share data between departments without filing a request and waiting three days.
“Customer-centric” is declared, not designed
Almost every operating model redesign includes one – “We will be customer-centric” (right between “digital transformation” and “continuous improvement” on slide fourteen).
But customer-centricity isn’t a declaration. It requires cross-functional squads with shared metrics, aligned incentives and ways of working that put customer segments at the centre, not business units. If marketing and sales can’t see what engineering is doing (and vice versa), the customer-centric slide is just a slide.
The roadmap is strategic, but not operational
Big vision, ambitious strategic objectives, beautiful three-year roadmap. And then no sequencing, no delivery engine, no clear answer to “What ships next week?”. A roadmap without an operational model underneath it is just a wish list with better formatting.
The 4 Key Components That Make Operating Model Work
Enough about what breaks. Here’s what makes the operating model work land, and not in theory, but in the calendar-and-code reality of delivering products.
1. Clear decision ownership
Not “everyone is responsible”. When everyone is responsible then nobody is, this is not a group project in school. Define who can say “yes”, who can say “no” and who doesn’t need to be in the room. Decisions are faster when fewer people have veto power and more people own outcomes.
2. Product-based delivery structure
Organise around products and customer outcomes, not departments. The difference between “the dev team builds what the business team requests” and “a cross-functional team owns this product end-to-end” is the difference between a relay race and a football team. One hands off, the other adapts in real time.
3. Embedded engineering
Not outsourced thinking, but engineering as part of the operating model’s core. When tech teams understand business processes deeply enough to challenge assumptions (not just execute tickets), the whole organisation moves differently.
4. Scalable DevOps and QA automation
An effective operating model treats infrastructure and quality as accelerators rather than afterthoughts. If every release requires a manual testing marathon and a prayer to the deployment gods, your model has a delivery bottleneck baked in.
These four components work together. Remove one and the rest compensate for a while, then the whole thing starts to drift like a shopping cart with one bad wheel.
What A Target Operating Model Looks Like
Where is the way of getting real value from AI?
A real target operating model is not a diagram with boxes and arrows that people present once and filed somewhere between last year’s OKRs and that brand guidelines doc nobody opens.
A working one:
- Aligns organisational structure with technology architecture;
- It funds products, not projects, meaning teams have continuity and ownership rather than being assembled and dissolved every quarter like a band that keeps breaking up and reuniting;
- It measures customer outcomes and it enables faster iteration because the people, the processes and the tech stack are designed to support each other.
This is where the execution layer matters. Modern backend scalability, DevOps and SRE practices, QA automation, product-led delivery models, agile execution support – these are no buzzwords but the infrastructure underneath an operating model that delivers. Without them even the most elegant organisational design stalls at implementation.
At Lerpal, this is exactly the kind of operating model work we support by embedding engineering, DevOps and delivery capability into the model itself. Because an operating model that looks right on paper but can’t ship weekly is just a governance upgrade with better formatting.
What Breaks Still Needs Fixing
Operating models fail because nobody’s watching the right symptoms. The meetings get longer, teams get frustrated – you name it, and everyone assumes it’s a people problem or a process problem when it’s actually a model problem.
The operating model describes how your organisation turns strategy into delivered value. When it works, it’s nearly invisible. When it doesn’t, everything feels harder than it should.
If your operating model is clear on paper but slow in practice, it’s an execution architecture problem, and good news – that’s a solvable one.
Explore how Lerpal helps organisations align delivery, engineering and operating model design.
