Plenty of strategies are weak to begin with. Wish lists with cover pages, no real diagnosis, no trade-offs in sight. But even the sharp ones, the ones built on actual choices, fail just as often as the weak ones. They fail because the organization underneath them can't move.
A leadership team declares the company "customer-centric." The org chart is still sliced into business verticals, each with its own P&L, its own KPIs, and its own budget cycle. Customer-centric work is horizontal by definition — it crosses those vertical lines constantly. Nobody redesigned the incentives, the metrics, or the decision rights to match the new intent. So every customer journey gets stuck at the first vertical boundary it hits, and the strategy turns into six different local interpretations that don't add up to anything the customer can feel.
I've spent years working inside and alongside organizations that looked fine on paper and couldn't execute on anything. A Nordic financial group where the digital strategy was so abstract that three teams interpreted it three different ways and built three incompatible things. A core banking renewal where the real problem wasn't the technology — it was that every country unit had its own processes, its own governance, and its own idea of what "customer onboarding" meant. A product team that knew exactly what to build and spent half its time writing status updates to people who weren't going to read them.
The pattern repeats. The strategy is usually abstract enough that every team can justify whatever they were already doing. The technology sometimes exists and sometimes has to be rebuilt from scratch. The people are capable. What's broken is the operating model — the invisible structure that decides who makes which calls, how work flows between teams, and what actually counts as "done." Strategy is the what. The operating model is the how. And when the how is broken, the what doesn't matter.
This page is the home base for everything I write about operating model design. If you're leading a transformation, running an ops team, or trying to figure out why your organization keeps stalling, start here.
What is operating model design?
An operating model is the structured answer to one question: how does this organization create, deliver, and capture value? It covers all three parts. How value gets created — what the company actually does that matters to customers. How it gets delivered — the end-to-end flow from idea to customer outcome. How it gets captured — the commercial mechanics that turn delivery into revenue and margin. Strategy says what value you're going for. The operating model is how the organization is wired to produce it.
A complete operating model covers six things:
- Decision rights — who gets to say yes, who gets to say no, and who has to be consulted.
- Roles and accountabilities — what each function owns end to end, and where the handoffs happen.
- Processes — the repeatable paths work takes from idea to customer.
- Governance — how oversight happens without becoming a bottleneck.
- Metrics — what gets measured and what those numbers mean for action.
- Capabilities — the skills, tools, and platforms the model depends on.
Here's the part most people miss: large organizations rarely have one operating model. They have several, sitting next to each other, often contradicting each other. A corporate group runs one way at headquarters and differently in each country unit. A holding company owns five subsidiaries that each have their own processes, their own governance, their own metrics. A bank runs retail, corporate, and wealth as three separate machines that happen to share a logo.
That's fine, as long as it's deliberate. The problems start when a strategic initiative needs those different operating models to cooperate. A core system renewal is the classic example: the technology project is already huge, but the real work is harmonizing the operating models underneath. You can't build one customer onboarding platform for seven country units that each define onboarding differently. The system renewal forces an operating model conversation the business has been avoiding for years, and that conversation usually turns out to be bigger than the technology.
Most organizations have all six elements of an operating model, but they were never designed together. They accumulated. A reorg added a layer here. A risk incident added a committee there. A new CEO added a metric that nobody tracks anymore. An acquisition brought in a whole parallel operating model that was never integrated. Over a few years you end up with something nobody designed and everybody works around.
Operating model design is the work of taking those six elements apart, asking what each one is actually supposed to do, and putting them back together so the whole thing serves the strategy. It often gets confused with restructuring or drawing a new org chart, and it usually leads to both, but the design itself is the thinking that should happen well before you reach for either of those tools.
My top five lessons on operating model design
1. The bottleneck is almost never where people say it is
When I ask operational leaders what's slowing them down, I usually hear "we need more people" or "the tooling is bad." When I spend a week watching the actual work, the bottleneck is almost always a decision point nobody owns. A ticket sits for nine days because it's "waiting on alignment." The real work takes forty minutes.
Before you hire, before you buy software, map the decision points. You'll find the problem.
2. Governance that protects everything protects nothing
The logic of adding another review committee is always the same: "We had a problem last year, so we'll make sure it never happens again." A year later the committee reviews everything, blocks most things, and approves what would have been approved anyway.
The job of governance is to catch the small number of decisions that genuinely need senior judgment. If your steering committee is reviewing routine work, it's not governing. It's performing oversight.
3. Clear accountability beats consensus every time
I've watched organizations spend three weeks aligning stakeholders on a decision that one person could have made in an afternoon. Nobody in those meetings actually wanted to be there. They wanted cover. Diffusing accountability across a room full of people feels safer than putting your own name on the call.
Courage doesn't fix this. Structure does. When ownership is unclear, consensus becomes the default because it's politically the safest move. When the operating model explicitly says "this decision belongs to the product lead," consensus stops being the path of least resistance.
4. The org chart is a symptom, not the disease
Reorgs are popular because they look decisive. The boxes get redrawn, the reporting lines shift, and a few people update their LinkedIn titles. A month later, the same meetings happen with the same people, and the same decisions take the same amount of time.
The org chart describes who reports to whom. The operating model describes who decides what. Changing the first without the second is theater. When I get called in after a reorg that didn't work, the pattern is usually that the boxes changed and the decision rights didn't.
5. You can't redesign everything at once
Operating model work fails most often when someone tries to fix everything at once. New processes get drafted while new governance is still being debated, new roles get announced before anyone has agreed on what they own, and the metrics catch up months later. All of this lands on an organization that still has to do its day job. The result is a two-year transformation program that produces a slide deck and not much else.
The work that sticks is the work that starts with one painful, visible problem, solves it in six to twelve weeks, and uses that win to earn permission for the next piece. Structure Decides is a long game played in short moves.
A simple guide to redesigning your operating model
This is the sequence I use with clients. It's not the only way. It's the one that tends to work when the organization is stuck and the leadership has limited patience for a twelve-month transformation program.
Step 1: Name the pain in one sentence
Before anything else, write down the actual problem in plain language. Not "we need to be more agile." Something like: "Product decisions take six weeks to make and we're losing deals because of it." If you can't name the pain in one sentence, you don't understand it yet, and redesigning the operating model to fix a fuzzy problem will produce a fuzzy fix.
Step 2: Map the current decision flow for one concrete case
Pick one recent decision that illustrates the pain. Walk it backwards. Who asked? Who got consulted? Who approved? How long did each step take? Put the whole path on a wall. Most of the time, the map shows three or four steps that added days and no clarity. That's your starting point.
Step 3: Separate reversible from irreversible decisions
Not every decision deserves the same level of care. Irreversible calls — major platform bets, senior hires, multi-year contracts — deserve thorough review. Reversible calls — price experiments, feature scope, vendor trials — should move fast and be cheap to undo. Most operating models treat both the same way, which is why reversible decisions get over-governed and irreversible ones get under-examined. Sort them.
Step 4: Assign single-owner decision rights for the reversible category
For every reversible decision type, name one owner in the operating model document. A single person, not a committee, and not one of those shared-accountability triangles that gives three roles partial credit and nobody the final word. The owner pulls in whoever they need input from, then makes the call. When the call turns out to be wrong, you fix it with feedback and a faster second attempt instead of bolting another approval layer on top.
Step 5: Replace standing meetings with exception-based reviews
A weekly steering committee that reviews everything becomes a place where decisions go to die. Replace it with a short exception-based forum: issues that are genuinely blocked or genuinely need senior judgment. Everything else moves through the normal flow. One of my clients cut steering from a weekly full review to a short exception-based check-in, and decisions that used to drag for weeks started landing in days.
Step 6: Define what "done" means for each handoff
Half the bottlenecks in broken operating models come from unclear handoffs. A product team "finishes" something and throws it over the wall to ops. Ops sends it back because the acceptance criteria weren't met. Neither side agreed on the criteria in the first place. Write them down. For each handoff in your value stream, define exactly what "done" looks like. Boring work. Huge payoff.
Step 7: Measure decision latency, not just output
Most organizations measure throughput — tickets closed, features shipped, tasks completed. Almost none measure how long decisions take. Add decision latency as a metric: from "decision needed" to "decision made." Track it for one month. The number will surprise you, and it will give you something concrete to improve.
Step 8: Run the new model on one team before scaling
Pick one team, one value stream, or one decision type. Run the new operating model there for six to eight weeks. See what breaks. Adjust. Then expand. Operating model changes that roll out organization-wide on day one almost always get rolled back by month three. Changes that prove themselves on one team get adopted because people see them working.