An operating model is the design of how an organization delivers its strategy: the core work and processes that produce value, the team structure wrapped around that work, the systems and data underneath it, the governance that makes decisions, and the capacity it all runs on. The business model says how you make money. The operating model says how you run.
That definition is easy to agree with and easy to leave abstract, which is why most writing on the subject stays at the level of frameworks and maturity matrices. This post does the opposite: it walks through what the model actually covers, shows two concrete examples, and ends with the honest problem that no canvas solves.
What an operating model covers
Five dimensions carry most of the load. They are not independent; the whole point of the model is how they fit together.
Work and processes. The value chain, step by step: how demand is created, how it converts, how the product or service gets delivered, how customers are kept. Everything else in the model exists to serve this row.
Structure and teams. How people are organized around the work. Functional, cross-functional, pods, regions. Structure is a choice about which handoffs you want to make cheap and which you can afford to make expensive.
Systems and data. Which tools carry each step, and which system is the authority for each kind of data. An operating model with ambiguous systems of record spends a surprising share of its capacity reconciling numbers.
Governance and cadence. Who decides what, at which threshold, in which recurring review. This dimension is the one most often left implicit, and the one whose absence hurts most. An operating cadence is the visible half of governance.
Capacity and partners. Where the hours actually go, split between running the business and changing it, plus the suppliers and partners the model depends on.
Operating model vs business model vs org chart
The three get conflated constantly, and the confusion is expensive because each answers a different question.
The business model answers: how do we create and capture value? Subscription software for mid-market companies, say. Two companies with the same business model can run completely different operating models.
The operating model answers: how are we set up to deliver that? Which work, which teams, which systems, which decisions.
The org chart is one slice of one dimension: reporting lines within the structure. Reorganizing the chart while leaving the work, systems, and governance untouched changes the operating model far less than the effort suggests. This is why so many reorgs disappoint: the boxes moved, the model stayed.
Two worked examples
Abstract dimensions become useful when you see them filled in. Neither of these companies is exotic. That is the point.
A 50-person B2B SaaS company
Work: one product, one funnel. Marketing generates inbound demand, two AEs convert it, onboarding is handled by the same customer success pair that runs renewals. Product and engineering ship from a single backlog.
Structure: functional. Marketing (4), sales (3), customer success (3), engineering and product (28), operations and finance (5), leadership (7 with overlaps). Cross-functional work happens through a weekly commercial sync rather than standing pods.
Systems: CRM as the system of record for customers and pipeline; the PM tool for delivery work; a spreadsheet, honestly, for the KPI set. The spreadsheet is where the model is weakest, and everyone knows it.
Governance: the founder-CEO decides pricing and roadmap trade-offs; a monthly business review checks trajectory against quarterly goals; anything above EUR 10k of unplanned spend goes to the leadership call.
Capacity: roughly 70% run, 30% change. The change budget is two engineering pods' worth of time, and the operating model's central tension is that every escalated customer issue eats the change budget first.
There is a longer treatment of this size of company in the strategy operating model for a 50-person company.
A 300-person professional services firm
Work: win engagements, staff them, deliver them, develop the bench. Utilization is the load-bearing number.
Structure: three sector practices, each with partners, managers, and consultants, plus a shared staffing function and central marketing. The expensive handoff is deliberately between practices and staffing, because the firm decided consultant development matters more than perfect utilization.
Systems: ERP for time and billing as the financial authority; a staffing tool that reads from it; sales pipeline in a CRM that the practices update with uneven discipline, which means the demand forecast is partly folklore.
Governance: partners own engagement economics; the executive committee owns pricing bands, hiring plans, and any client commitment beyond twelve months; a monthly partner meeting reviews utilization, pipeline, and people risk. The CEO's own cadence sits on top of that rhythm.
Capacity: around 85% run. The 15% change capacity is concentrated in one transformation program at a time, because the firm learned that two parallel programs starve each other.
Notice what both examples share: the interesting content is not the boxes but the tensions. Where the model is weakest, where the handoffs are deliberately expensive, where the numbers are folklore. A real operating model description names those.
The target operating model
A target operating model is the future-state version of the same description: how the organization needs to run to deliver the strategy it has chosen, written in the same dimensions as the current state. The definition matters less than the discipline that comes with it: you cannot write a credible target model without an honest current one, and most target-model exercises fail exactly there, designing a future for an organization that exists only on the kickoff slide.
Done properly, the gap between the two descriptions, taken dimension by dimension, becomes the transformation roadmap. The services firm above wants sector practices to sell subscription advisory products. Read across the dimensions and the roadmap writes itself: new delivery work (productized offerings), a structural change (a product function that does not exist today), a systems change (subscription billing the ERP cannot do), new governance (who may commit the firm to a recurring service), and a capacity decision (which practice gives up billable hours to build the first offering). Each gap is a workstream. The roadmap is the diff.
How to design one
Sequence matters more than the canvas you use.
- Draw the value chain first. The work is the spine. Every other dimension is a choice about how to serve it.
- Map structure onto the work, not the other way around. When structure comes first, the org chart becomes the strategy, and the work is left to route itself through whatever handoffs the chart created.
- Assign systems of record. For each step and each kind of data, one authority. Ambiguity here compounds forever.
- Write governance as deciders, not committees. Who decides, at what threshold, in which review. A model full of consulted parties and empty of deciders predicts slow execution.
- Check capacity against the strategy. If the strategy needs 30% change capacity and the model shows 10%, no amount of structure fixes that. Something has to be stopped.
Fill it for the current state, then the target, and keep both to a page each. The operating model canvas in our templates library gives you the six sections pre-structured, as a free download.
The consulting treatment, and what it misses
The strategy firms have written well about operating models for decades, and the frameworks are genuinely useful. But there is a reason the literature is dominated by design and almost silent on operation: a designed model is a document, and documents hold still. The consultants leave after the design phase. The model then meets reality, where teams reorganize themselves informally, tools get adopted and abandoned, and the capacity split drifts ten points in a quarter without anyone deciding it should.
The design was never the hard part. Knowing what the model is actually doing, this week, is.
The model on paper vs the model running
Every dimension of an operating model drifts, but capacity drifts fastest and most invisibly. The model says 30% of effort goes to change-the-business work. Then a large customer escalates, a compliance deadline lands, two people leave, and by October the real number is 12%, while every planning document still says 30. The strategy built on that 30 is now quietly unfunded, and the gap between the two numbers is execution risk in its purest form.
This is where a live view earns its keep. When goals and the work behind them are connected in one structure, the capacity question stops being an annual survey and becomes something you can read: where the hours actually went, which priorities have active work behind them, and where the running model has diverged from the designed one. Vindaris builds that view from the tools teams already work in, so the operating model review starts from what is true rather than what the canvas says. Related reading: the product operating model, which applies this same logic to how product organizations fund and measure their teams.