Operating model design is the discipline of deciding how people, processes, technology and governance combine to deliver your strategy, then deliberately arranging those elements so they do. Get it right and you gain four things worth fighting for: clarity, speed, skills and commitment, the four outcomes a modern operating model is built to produce.
If you take one thing from this article, take this: do not start with the org chart. Start with a small set of design principles, then map your operating model's elements against them. In practice that means:
- Draft 7 to 15 specific design principles that translate strategy into decisions your teams can actually use.
- Map the full set of operating-model elements, from purpose through to talent, against those principles before you touch structure.
- Pilot the redesign in one high-value area before you scale it business-wide.
Everything below walks through how to do each of these properly, including the framework, the step-by-step process, and where most redesigns quietly fail.
Key Takeaways
Operating model design succeeds when leaders set specific design principles, map all 12 elements against strategy, and measure the four outcomes continuously rather than treating launch as the finish line.
| Point | Details |
|---|---|
| Define scope first | Separate operating model decisions (people, process, technology, governance) from business model and org chart questions. |
| Draft 7 to 15 principles | Write specific, evidence-grounded principles that resolve real trade-offs before choosing structure. |
| Map all 12 elements | Cover purpose, value agenda, structure, ecosystem, leadership, governance, processes, technology, behaviours, rewards, footprint and talent as an interacting system. |
| Pilot before scaling | Rewire one high-value domain, assign decision rights explicitly, and validate trade-offs before wider rollout. |
| Measure outcomes continuously | Track decision latency, hand-off frequency and role utilisation with a live organisational model like Oakandnine to catch drift early. |
Table of Contents
- What is operating model design, and how is it different from your business model?
- Why operating-model design pays off for leaders who invest in it properly
- Design principles: turning strategy into decisions your teams can use
- The 12 operating-model elements you need to map
- A step-by-step blueprint for designing and rolling out your target operating model
- How a live organisational model changes the mapping and measurement problem
- What the conventional playbook gets wrong about operating model design
- Design the model, then run it: where Oak & Nine fits
- Sources
What is operating model design, and how is it different from your business model?
An operating model is the blueprint for how your organisation actually delivers value. It defines how people, processes, technology, governance and metrics fit together to execute strategy day to day, and it is a distinct concept from the business model, which describes what you sell, to whom, and how you make money from it.
Confusing the two causes real damage. A business model answers "what markets do we serve and how do we monetise them?" An operating model answers "who does the work, who decides, and which systems carry it?" Organisational design sits one level below both: it is the org chart, reporting lines and role definitions that operating model design produces, not the other way round.
The mistake we see most often: a leadership team redraws the org chart, calls it a redesign, and wonders six months later why decisions are still slow and duplicated. Reorganising boxes on a chart without touching processes, governance or technology is not operating model design. It is furniture rearrangement. The corrective is straightforward:
- Define the org chart last, not first.
- Design governance and decision rights explicitly, rather than assuming a new reporting line will fix them.
- Treat technology and process choices as core design decisions, not IT's problem to solve afterwards.
Why operating-model design pays off for leaders who invest in it properly
Four outcomes separate a well-designed operating model from a mediocre one: clarity on who owns what, speed in how decisions get made, the right skills sitting where the work happens, and genuine commitment from the people expected to deliver. Miss any one of these and strategy execution stalls, regardless of how sound the strategy itself is.
The evidence is blunt on this point. Research from McKinsey finds that redesign success tracks closely with senior-team alignment and real investment in rewiring core processes, not just structural change. Delegate the hard trade-offs to a small project team without genuine senior buy-in, and the redesign tends to fail before it reaches the frontline.
Two failure modes show up repeatedly. The first is slow decisions: a regional manager waits three weeks for sign-off on a call that should take three days, because nobody redesigned the decision rights when the reporting lines changed. The second is duplicated effort: two teams building the same reporting dashboard because governance never clarified who owns performance data. Both are operating model failures wearing an organisational-design costume.
Design principles: turning strategy into decisions your teams can use
Design principles are the tool that separates a deliberate operating model from an accidental one. A good principle is not a value statement or a mission line; it is a specific, evidence-grounded rule that tells your teams how to resolve a genuine trade-off when structure alone cannot decide it.
Bain & Company's guidance is precise on the number: translate your strategy into a compact set of typically 7 to 15 principles before you touch structure. Fewer than that, and you have not covered enough ground. More than that, and nobody remembers them when it matters.
What makes a principle usable rather than decorative:
- It is specific enough to resolve a real trade-off. "We prioritise speed over perfect consistency in customer-facing decisions" tells a regional manager exactly what to do when head office and the front line disagree.
- It is grounded in your actual strategy, not generic best practice. If your strategy depends on winning through customisation, a principle favouring platform standardisation over bespoke delivery will fight your own plan.
- It is short enough to repeat from memory. If a principle needs a paragraph of explanation, it will not survive contact with a Tuesday afternoon decision.
Common trade-offs principles need to settle include centralisation versus local speed, platform standardisation versus bespoke delivery, and build versus buy for technology. A Bain brief on the topic makes the point plainly: vague principles do not help leaders make trade-offs, they only sound good in a workshop.
Vet every draft principle with a simple actionability test: could two competent managers, faced with the same trade-off, use this principle to reach the same decision independently? If the answer is no, the principle is still a slogan.
Pro Tip: Run your draft principles past a real, recent decision your team argued about. If the principle would not have settled that argument in under a minute, rewrite it.
The 12 operating-model elements you need to map
A modern operating-model framework organises design choices across 12 interlocking elements. Treat these as a checklist, not a sequence. They interact as a system, and the outcomes you're after, clarity, speed, skills and commitment, emerge from how well the elements fit together, not from any single one.
- Purpose — why does this unit exist? Does everyone in it know?
- Value agenda — what specific value are we designed to deliver, and to whom?
- Structure — who reports to whom, and does that reflect how work actually flows?
- Ecosystem — which partners, vendors or platforms extend our capability?
- Leadership — who is accountable for outcomes, not just activity?
- Governance — what decision rights exist, and who holds them?
- Processes — which workflows create the value, and where do they break?
- Technology — which systems carry the work, and do they talk to each other?
- Behaviours — what do people actually do when no one is watching?
- Rewards — do incentives reinforce the behaviours we need or undermine them?
- Footprint — where is work physically or organisationally located?
- Talent — do the right skills sit where the work happens?
The interactions matter more than any single element. Redesign your technology without touching governance, and you have automated a decision bottleneck rather than removed it. A useful lens here is treating your current arrangement as a fingerprint across all 12 elements: it tells you whether you need to tweak a handful of elements or overhaul the whole model.
For speed, a common design choice is pushing decision rights down to the point of customer contact and removing an approval layer. For resilience, the equivalent choice is deliberately duplicating a critical skill across two locations so a single point of failure cannot stall the whole operating model.
A step-by-step blueprint for designing and rolling out your target operating model
Once your principles are drafted and your elements are mapped, the redesign becomes a five-step programme rather than a one-off project. Each step has its own risks, and skipping one is where most operating model implementation plans quietly unravel.
-
Diagnose the current fingerprint. Map how the 12 elements currently work in practice, not on paper. Measure the gap between current performance and the four outcomes: where is clarity missing, where are decisions slow, where are skills mismatched, where is commitment weak? This is your baseline operating model assessment, and it should surface uncomfortable findings, not confirm what leadership already believed.
-
Agree principles and success metrics with the senior team. This cannot be delegated. Bain's research is direct on this: senior leaders must personally own the trade-offs embedded in your principles, because a small project team without genuine senior alignment is a leading cause of redesign failure. Agree the metrics you'll track alongside the principles, so you can tell later whether the redesign actually worked.
-
Develop two to four candidate fingerprints. Do not design one option and sell it. Build genuine alternatives, evaluate each against your principles, and let the principles do the deciding rather than internal politics.
-
Pilot in a high-value domain. Rewire the core processes in one business-critical area, assign decision rights explicitly using a decision rights matrix, and treat this as a real test, not a demonstration. A fast, focused pilot validates trade-offs quickly and surfaces transition risk before you have committed the whole organisation to it.
-
Scale with phased governance and incentive alignment. Roll the design out in stages, moving talent deliberately rather than leaving people stranded in roles the new model no longer needs. Link rewards to the outcomes you actually want, because unaligned incentives are one of the most common reasons a sound redesign fails at the point of execution.
Throughout all five steps, manage transition risk proactively rather than reactively. The most common red flags are underinvesting in the people and process rewiring, failing to connect incentives to the new design, and treating change management as an afterthought rather than a parallel workstream. A structured change management approach tends to catch these before they surface as attrition or quiet non-compliance.
Pro Tip: Build your rollout roadmap around milestones tied to the four outcomes, not just delivery dates. "Decision latency down by half in the pilot domain" tells you more than "phase two complete on schedule."
How a live organisational model changes the mapping and measurement problem
Mapping 12 interacting elements by hand, in spreadsheets and workshop notes, is slow and goes stale the moment anything changes. A live organisational model that unifies structure, process and system data lets you track the signals that actually indicate whether your redesign is working, in near real time rather than at the next quarterly review.
The minimum dataset worth capturing includes decision latency (how long approvals actually take), hand-off frequency between teams, and role utilisation against capacity. Dashboards built on these three signals tell you faster than any survey whether clarity and speed are improving or quietly regressing.
Oakandnine's platform is built around exactly this problem: it maps organisational structure, connects the functions across HR, finance and operations, and surfaces the bottlenecks a redesign is meant to remove. Where routine data collection and reporting used to eat a project manager's week, automation absorbs it, freeing the team to focus on the trade-offs the principles were written to resolve.
What the conventional playbook gets wrong about operating model design
Most operating model guidance treats the framework, the 12 elements, the principles, the diagnostic, as the hard part. It isn't. The frameworks are well established and genuinely good; McKinsey and Bain have refined them for years, and there is no need to reinvent them. The hard part, consistently underestimated, is the discipline to keep measuring after the pilot ends.
Too many redesigns treat the launch of the new structure as the finish line. The actual test comes three months later, when the old habits creep back because nobody is watching decision latency or role utilisation closely enough to notice. Principles decay into slogans the moment leadership stops referring back to them in real decisions.
If I had to tell a leadership team where to put their effort, it would not be on drafting more elegant principles. It would be on building the muscle to watch the four outcomes continuously and act on drift early, before it hardens into the next operating model that needs redesigning in three years. Treat the redesign as an operating discipline, not a project with an end date, and half the usual pitfalls disappear on their own.
— Ronan
Design the model, then run it: where Oak & Nine fits
Most operating model programmes stall not at the design stage but at the point of proving it worked, because nobody had the visibility to catch drift early. Oakandnine closes that gap: it maps your organisation's structure, processes and systems into one live model, automates the routine reporting that used to consume your project team's time, and surfaces bottlenecks and decision latency before they cost you a quarter of lost momentum. For managing directors weighing up a redesign, the platform built for that role shows exactly how the mapping and measurement work in practice. Operations leaders running the pilot and scale phases will find the operations-focused view more directly useful, with dashboards built around the same decision-latency and role-utilisation signals covered above. If you're about to start a redesign, the sensible next step is a demo: see your own organisation's fingerprint mapped before you commit a single structural change.
Sources
- A new operating model for a new world — McKinsey
- Design principles for a robust operating model — Bain & Company
- Operating model — Wikipedia