Designing an operating model that follows strategy

Many leadership teams have been through the same cycle. The strategy changes, results do not follow, and someone suggests a reorganisation. New boxes are drawn, managers are moved, and a few months later the organisation behaves much as it did before. The same handovers fail, the same decisions get stuck, and the same customers complain about the same things.

The problem is rarely the boxes. It is everything around them: how work actually moves from one team to the next, who decides what, which skills sit where, what people are measured on and which systems they rely on. Together, these make up the operating model. The org chart is only one small part of it.

This article explains what an operating model is, why changing the structure alone so often disappoints, and a practical way to design one that follows the strategy.

What an operating model actually is

An operating model is a description of how the business delivers value to its customers. It answers a simple question: given what we have decided to do, how do we organise ourselves to do it well?

It has seven parts that need to fit together:

• Capabilities. The things the organisation must be able to do, such as winning large tenders, delivering projects on time, or running a reliable service desk.
• Processes. How work flows from start to finish, across teams, to produce a result for a customer.
• Structure. How people are grouped into units, and who reports to whom.
• People. The roles, skills and number of people needed, and where they sit.
• Governance. Who decides what, in which forum, and how often.
• Technology. The systems and data that support the work.
• Performance management. What is measured, how it is followed up and what people are rewarded for.

When these parts fit, decisions are made at the right level and handovers are clear. When they do not, people spend much of their time working around the organisation instead of through it.

Why reorganising the boxes rarely fixes things

Structure is the most visible part of an operating model, and the easiest to change on paper. A new org chart can be drawn in an afternoon and announced the following week. It looks decisive.

But structure only decides who sits together and who reports to whom. It does not decide how work flows between units, who has the authority to make a call, or what each team is measured on. If those stay the same, the new structure inherits the old problems.

Consider a common example. A company organised by function decides to reorganise by customer segment, because the strategy says it wants to be closer to customers. Sales, delivery and support are split into segment teams. But the planning system still works by function, budgets are still set by function, and the bonus scheme still rewards functional targets. Within a year, informal functional networks have reappeared, segment leaders are frustrated, and people talk about the reorganisation as a failure.

The structure was not wrong. It was simply the only thing that changed.

If you only change the structure, the rest of the operating model will slowly pull the organisation back to where it was.

Reorganisations also cost months of leadership attention and often some good people. That is worth paying to solve a real problem, not for a new picture of the same organisation.

Start from the few strategic priorities

A good operating model design starts from the strategy, not from the current org chart. The first step is to be clear about the handful of things the business has decided to win at.

Most strategies contain far too many priorities to design around. Narrow them down to the three or four that genuinely shape how the business must work. For each, ask what it means in practice. For example:

1. If the priority is to grow with large customers, the business must be able to handle complex sales, coordinate across many sites and give each customer one clear point of contact.
2. If the priority is to become the low-cost provider, the business must standardise work, remove duplication and make decisions quickly with few layers.
3. If the priority is to launch new services faster, the business must be able to test ideas cheaply, move people between projects and make go or stop decisions without long approval chains.

These implications are the design criteria. Every later choice about structure, roles and governance should be tested against them. If a design does not help the business deliver its priorities, it does not matter how tidy it looks.

Identify the capabilities that must be excellent

Not every capability needs to be world class. Most businesses have a small number of capabilities that make customers choose them, and a much larger number that simply need to work reliably at a sensible cost.

Sort your capabilities into three groups:

• Distinctive. Capabilities that set you apart and directly support the strategic priorities. These deserve the best people, the most investment and protection from cost cuts.
• Essential. Capabilities that must work well, but where being better than competitors does not win customers. Payroll, IT operations and accounting often belong here. Aim for reliable and efficient.
• Supporting. Capabilities that are needed but could be simplified, shared or bought from others.

This sorting often reveals that a distinctive capability is spread thinly across several units with nobody owning it, while an essential one has grown into a large department with its own ambitions.

The distinctive capabilities are the ones the operating model should be built around. They need clear ownership, enough scale, and a home in the structure where they can be developed.

Design how work flows before deciding structure

This is the step most organisations skip, and the one that makes the biggest difference.

Before drawing any boxes, map the few end-to-end flows that matter most for the strategy. A flow is a chain of work that starts with a customer need and ends with a result: from enquiry to signed contract, from order to delivery, from fault report to fixed problem. For each one, ask:

• Which teams touch this work, and in what order?
• Where are the handovers, and where do things typically get stuck or lost?
• Where are decisions made, and who has to be involved?
• How long does it take, and how much of that time is waiting?

Mapping a few flows like this usually shows where the real friction is. Perhaps three different teams each re-enter the same customer information. Perhaps a decision that should take a day needs four signatures. Perhaps nobody owns the flow as a whole, so problems that cross unit boundaries are never fixed.

Once you can see how work should flow, structure becomes a much easier question. The aim is to group people so that the most important flows cross as few boundaries as possible, and so that the remaining handovers are clear and well managed. Structure then serves the work, instead of the work bending around the structure.

Common design choices and their trade-offs

Every operating model involves a few big choices. There is no universally right answer to any of them. The right answer depends on the strategy, and each option has a cost.

Central or local. Centralising a function gives scale, consistency and lower cost. Keeping it local gives speed, closeness to customers and local ownership. A Nordic business operating in Norway, Sweden and Denmark faces this constantly: should pricing, marketing or service be run from one place, or by each country? A useful rule is to centralise what benefits from scale and consistency, and keep local what depends on knowing the customer and the market.

Function or market. Organising by function, such as sales, operations and finance, builds deep expertise and efficiency. Organising by market, customer group or product brings people closer to the customer and makes one leader responsible for results. The cost is duplication and weaker specialist communities. Many businesses end up with a mix: market-facing units for sales and delivery, and functional units for specialist work.

Shared services. Pulling routine work such as finance, HR administration or IT support into a shared unit can reduce cost and improve quality. It works well for standard, high-volume work. It works badly when the work requires close knowledge of a particular part of the business, or when the shared unit becomes a bottleneck that the rest of the organisation has to queue for. If you create shared services, define clearly what they deliver, at what service level, and how their customers inside the business can hold them to account.

Whatever you choose, be honest about the downside, and design something to compensate for it. If you organise by market, create a way for specialists to share knowledge across markets. If you centralise, give local leaders a clear way to raise needs and influence priorities.

Then set roles, governance and measures

With flows and structure in place, the final layer is how decisions are made and performance followed up. Many good designs fall apart here, because it is detailed work that is easy to postpone.

Start with the most important decisions. For each, agree who makes the decision, who must be consulted and who only needs to be informed. Keep the list short and focused on decisions that cross unit boundaries, since that is where confusion usually lives.

Then look at the forums. Which meetings are needed to run the business, how often, and with whom? Many organisations can remove a large number of meetings once decision rights are clear, because a lot of meetings exist only because nobody knows who is allowed to decide.

Finally, align measures and incentives with the design. If you want teams to collaborate across a flow, measure the flow as a whole, not only each team's part of it. If you want local leaders to own results, give them the information and authority to influence those results.

Test the design before you roll it out

An operating model looks convincing on paper. It is much harder to know whether it works in practice. Before committing the whole organisation, test it.

A few practical ways to do this:

1. Walk through real cases. Take five or six recent situations, such as a large order, a customer complaint, a new product launch or a budget overrun, and play them through the new design. Who would do what? Where would decisions be made? Where would it get stuck?
2. Stress-test the edge cases. Ask what happens when two units disagree, when a customer spans several markets, or when demand suddenly doubles. Good designs have clear answers.
3. Check the numbers. Does the design need more managers than today? More people in total? Is the cost consistent with the strategy?
4. Ask the people who do the work. Middle managers and experienced staff will usually spot problems the leadership team cannot see. Involving them also makes the transition easier.
5. Pilot where possible. If one region, business unit or flow can try the new model first, do that. Learn from it and adjust before rolling out more widely.

Testing takes a few weeks. That is much cheaper than finding the problems after everyone has moved.

Plan the transition and sequence the changes

Even a good design can fail in the transition. Changing everything at once overwhelms people and makes it hard to see what is working. Changing too slowly lets the old model reassert itself.

Some principles that help:

• Sequence by dependency. Decision rights and key roles usually need to be in place before structural changes take effect, or the new units will not know how to work together.
• Keep the business running. Protect customer-facing work during the transition. Name someone responsible for making sure nothing falls between the old and new model.
• Appoint key leaders early. Uncertainty about who will lead what is one of the main causes of lost momentum and lost people.
• Change the systems and measures in step. If reporting and incentives still reflect the old model, people will keep behaving according to it.
• Review after a few months. Agree in advance when you will check whether the new model works, using the design criteria from the start, and be willing to adjust.

Where to start

You do not need a large programme to begin. A leadership team can make real progress in a few working sessions.

1. Write down the three or four strategic priorities, and for each, what the business must be able to do to deliver it.
2. Sort your capabilities into distinctive, essential and supporting, and check whether the distinctive ones have clear owners.
3. Map two or three of the most important end-to-end flows and mark where they cross unit boundaries, where they wait and where decisions get stuck.
4. Only then discuss whether the structure needs to change, and if so, which design choices fit the strategy best.

Often, this work shows that a full reorganisation is not needed at all. Clearer decision rights, a few redesigned handovers and better aligned measures may solve most of the problem at a fraction of the cost. And when a structural change is needed, the organisation will be far better prepared for it, because the work it is meant to support has already been designed.