Operating Model Design Principles

Executive summary

An operating model is the way a company arranges its people, processes, decisions, information, and assets to deliver its strategy. It answers practical questions. Who is accountable for a customer's order from quote to cash? Who decides on a price exception? How many layers separate the CEO from the work? Which activities are centralized, which sit inside business units, and which are bought from outside?

Operating model design matters because strategy does not execute itself. A plan to grow a product line, improve delivery, or integrate an acquisition will meet the existing structure, and where the structure was built for a different company, it will win. Many strategic plans fail in exactly this way, which is why the strategic planning playbook treats the cascade into the operating cadence as the critical step.

When to use this

Use this guide when:

• A strategy change, such as a new market, a new product line, or a shift in who your customers are, does not fit the current structure.
• You have grown through acquisition and now run two or more sets of processes and reporting lines.
• Leaders spend their time resolving handoff disputes between functions.
• Decisions queue up at the CEO because nobody else is sure they are allowed to make them.
• Costs have grown faster than output, and you suspect layers, duplicated roles, or unclear accountability.
• A new owner or sponsor has asked how the company is organized to deliver the value creation plan.

Do not use it as a cost-cutting exercise in disguise. Structure changes that affect employees raise legal, consultation, and employment-law obligations that differ by jurisdiction and by your agreements and policies. Involve HR and counsel early; nothing here is legal or HR advice. Also avoid starting a redesign during a liquidity crisis; stabilize cash first with liquidity crisis triage.

Diagnostic questions

1. Can each leader state, in one sentence, what the company must do differently in the next three years because of the strategy?
2. For your top three customer promises (for example, on-time delivery, accurate quotes, fast onboarding), who is the single accountable person for each?
3. How many functions touch a typical order, claim, or project from start to finish, and how many handoffs are there?
4. Where do work items wait longest, and who is responsible for the queue?
5. Which decisions come to the CEO that someone closer to the information could make?
6. When two functions disagree about a priority, what is the resolution path and how many days does it take?
7. What is the span of control and the number of layers in each major function, and do they match the nature of the work in each?
8. Which activities are duplicated across sites, business units, or acquired companies?
9. Which roles exist only to coordinate between other roles?
10. Which KPIs are owned by a person whose actions can actually move them?

How to read the answers: if question 2 yields no single name for a customer promise, the first design problem is accountability, not structure. If question 3 shows many handoffs, look at flow before boxes and lines. If question 5 shows a queue at the CEO, decision rights are the constraint, and a decision rights matrix will deliver more than a new org chart.

The framework: seven parts of an operating model

Think of an operating model as seven parts that must fit together. A change in one usually requires a check on the others.

The parts you control least reliably are people and incentives, and the parts that are easiest to change on paper are structure and the org chart. That is why many reorganizations alter the boxes and leave behavior unchanged. A design is complete only when it addresses decision rights, cadence, and metrics as well as structure.

Design principles

1. Strategy sets the requirements. Before drawing any option, write three to six design requirements derived from the strategy. Examples: "A customer has one accountable contact from quote to payment." "Pricing exceptions are decided within one business day." "Acquired businesses report on the same calendar and chart of accounts." The requirements become the criteria for choosing between designs.

2. Design around the flow of work. Map the path from customer request to cash and identify where the work crosses boundaries. Boundaries create handoffs, handoffs create queues and errors, and queues create delay. Draw structure so the most frequent and most valuable flows cross the fewest boundaries.

3. Minimize handoffs, then name them. You cannot eliminate every handoff. Where one remains, define what is handed over (the standard), who receives it, and who owns the time spent waiting. A handoff with no named owner for the queue is where problems hide.

4. One outcome, one accountable owner. An outcome that is shared by two functions is owned by neither. For each important outcome, name one person who answers for it, even if many contribute. Accountability should match authority: if the person cannot influence the inputs, redesign the role or the outcome.

5. Push decisions to the information. Decisions are best made by the person closest to the facts, within limits set by those accountable for the consequences. Write limits as thresholds (for example, price exceptions up to a stated margin floor) rather than as approvals for everything. See the decision rights matrix template.

6. Spans and layers follow the work. There is no correct span of control. Repetitive, standardized work supports wider spans; complex, judgment-heavy, or safety-critical work requires narrower ones. Choose spans by task type, then count the layers that result. Use span of control cost analysis to look at the cost, but do not set a company-wide number.

7. Centralize for consistency, embed for speed. Centralize an activity when consistency, scale, scarce expertise, or control matters more than responsiveness. Embed it in the business unit or site when speed, local knowledge, or customer proximity matters more. Outsource when the activity is not a source of advantage and a supplier can perform it reliably at a clearer cost. State which of these applies to each activity and why.

8. Governance should be the smallest that works. Each recurring meeting needs a purpose, an owner, standing inputs, and decisions it can make. If a meeting cannot make a decision, ask why it exists. The cadence is where the design runs, so connect it to the operating cadence and the operating review system.

9. Measure what the owner can move. Metrics should attach to roles that can influence them. Decide the KPI set together with the structure so that accountability and measurement line up.

Step-by-step process

1. Write the design requirements. Three to six statements derived from the strategy. Owner: CEO. Output: a requirements list with a priority order.
2. Map the value flow. Draw the top two or three flows from customer request to cash, with every handoff and wait time. Owner: COO with process owners. Output: flow maps with handoff counts.
3. Capture the current structure. Functions, headcount, spans, layers, and where each activity sits today. Owner: HR with Finance. Output: a structure fact base.
4. Map decision rights as they actually work. Interview a few people on who really decides, not who is meant to decide. Owner: CFO or COO. Output: a current-state decision map and a list of bottlenecks.
5. Identify design problems. Compare the facts with the requirements: missing owners, long handoff chains, duplicated work, decisions in the wrong place, layers without work. Owner: CEO. Output: a ranked problem list.
6. Generate two to four design options. Include a minimal-change option that fixes decision rights and handoffs without moving boxes. Owner: CEO with a small design team. Output: option descriptions.
7. Evaluate options against the requirements. Score each option on stated criteria, compute handoffs, layers, and indicative cost, and test with the options review method. Owner: CEO and CFO. Output: a scored comparison.
8. Check the people implications early. Roles affected, capabilities required, and legal and consultation obligations. Owner: HR with counsel. Output: a people impact note.
9. Design the supporting parts. Decision rights matrix, cadence, KPI ownership, and role definitions for the chosen option. Owner: CEO and function heads. Output: a one-page design for each part.
10. Pilot. Run the new design on one flow, site, or product for a defined period with named success measures. Owner: COO. Output: pilot results and adjustments.
11. Roll out in stages. Sequence changes by dependency, and communicate the reasons and the facts, not only the new chart. Owner: CEO. Output: a rollout plan with dates and owners.
12. Review. Compare results to the requirements at 90 days and 12 months, and record what changed. Owner: CEO. Output: a design review in the quarterly plan review.

Templates

Design requirements

Flow and handoff map

Spans and layers fact base

Metrics and KPIs

Setting targets without invented benchmarks. Compare each function to your own best-performing unit with similar work, and to the number implied by the nature of the work, such as a tighter span for judgment-heavy roles. Where a named public peer discloses headcount and revenue, you can compare revenue per employee in the filing, with caution about differences in model. Avoid importing a standard span, layers, or overhead percentage from an article; those depend on the type of work and the quality of managers and systems.

Common mistakes

1. Redrawing boxes without changing behavior. If decision rights, cadence, and metrics stay the same, a new org chart will not change outcomes.
2. Designing around people. Starting from who should hold which role guarantees a design shaped by the current team. Design the roles first, then fill them, with care and fairness.
3. Setting a company-wide span. A single number across functions ignores the difference between standardized and judgment-heavy work.
4. Creating shared ownership. Two owners for one outcome means none. Name one.
5. Centralizing everything for control. Central teams can become queues. Centralize where consistency matters and embed where speed does.
6. Ignoring acquired-company differences. Integrating structure without aligning chart of accounts, calendar, and KPI definitions leaves two operating models under one chart.
7. Announcing before testing. A reorganization announced as a surprise creates uncertainty and attrition. Pilot first, and handle employee and legal requirements properly with advisers.
8. No design requirements. Without stated requirements, debates are about preferences, and the loudest executive wins.

Worked example

Illustrative. The numbers below are made up to show the method. They are not benchmarks and describe no real company.

A $60M industrial services company wants shorter delivery from order to completion. Its design requirements: one accountable owner per customer order, no more than four handoffs on the standard order-to-delivery flow, and pricing exceptions decided within one business day.

Step 1: Map the flow. In the current design, a standard order passes through Sales, Estimating, Scheduling, Field Operations, Quality, Billing, and back to Sales for customer sign-off. That is six handoffs. The team samples recent orders and finds an average wait of 1.5 days at each handoff.

Step 2: Compute the structure effect. Six handoffs × 1.5 days = 9.0 days of waiting in the flow. A product-aligned pod design, in which Sales, Estimating, Scheduling, and Quality coordination sit in one team with Field Operations as a dedicated partner and Billing as a shared service, has four handoffs: pod to Field Operations, Field Operations back to the pod for Quality sign-off, pod to Billing, and Billing back to the pod for customer closure. At the same 1.5 days per handoff, waiting falls to 4 × 1.5 = 6.0 days, a saving of 3.0 days in the flow, subject to the assumption that the wait per handoff stays the same in the new design. The team notes this assumption explicitly, because pods may reduce waits per handoff further or introduce new ones.

Step 3: Look at spans and layers. The operations function has 216 people. With an average span of 6, the function needs ceil(216 ÷ 6) = 36 first-line managers, then ceil(36 ÷ 6) = 6 second-line managers, then 1 head, a total of 43 managers across three layers. With an average span of 8, it needs 27, then ceil(27 ÷ 8) = 4, then 1, a total of 32 managers across three layers. The difference is 11 managers. The team does not choose span 8 across the board. Field crews doing standardized work can run at wider spans, while the quality group does judgment-heavy inspections and stays narrow. The layers count stays at three either way, which shows that in this function the question is span by work type, not layers.

Step 4: Decision rights. Pricing exceptions currently go to the CEO, who answers within an average of three days. The design sets a margin floor: pod leads decide exceptions that keep margin at or above the floor, the VP Sales decides those down to a second stated limit, and the CEO sees only those below it, reported monthly. The requirement of one business day is met for the cases inside the pod lead's limit.

Step 5: Options and test. Option 1 (minimal change) fixes pricing decision rights and names an owner per order, but keeps six handoffs. Option 2 (pods) reduces handoffs to four and requires some people to move. The CEO selects Option 2 for one product line as a 90-day pilot, with success measures defined before the pilot starts: elapsed order-to-delivery time, pricing decision latency, and rework rate. HR and counsel review the people changes before anything is communicated.

What the example shows. The design choice was made on requirements and numbers rather than preferences, the key assumption was stated, the span analysis led to a work-type decision rather than a company-wide number, and the redesign went through a pilot before a rollout.

AI prompt assistance

AI can help with analysis and drafting. It cannot see how work really flows in your company, so use it on the data and descriptions you provide and check what it returns.

1. Derive design requirements from the strategy.

Here is our three-year strategy summary. Draft five operating model design requirements, each phrased so it can be tested, such as "a customer has one accountable owner from quote to cash." Do not propose a structure.

Check: the management team should edit and rank the requirements, since they are the criteria for everything that follows.

2. Analyze handoffs from process notes.

Here are interview notes describing how an order moves through the company. List every step, the owner, and each point where work changes owner. Count the handoffs. Flag any step where the notes do not say who owns the queue.

Check: validate the map with the people who do the work, and sample real orders for wait times.

Implementation guide

Governance. The CEO owns the design. The COO owns the flow and the pilot. The CFO owns the cost analysis and the decision rights thresholds. HR and counsel own the compliance of any change affecting employees. A small design team of three to five leaders from different functions keeps the work from becoming one function's view.

Downloadable assets

The design requirements, flow and handoff map, and spans and layers fact base above are copy-ready into a spreadsheet. No calculator exists for this topic yet; the spans and layers table with the ceiling formulas in the worked example does the job in a spreadsheet.

Related resources

• Strategy and planning guides: the hub for this series.
• Strategic planning playbook: where the operating model supports the cascade.
• Decision rights matrix template: setting who decides what.
• Operating cadence: weekly, monthly, quarterly rhythms: how the design runs week to week.
• Span of control cost analysis: costing spans and layers.
• Strategic options review for mid-market CEOs: choosing between design options.

Frequently asked questions

What is an operating model?

An operating model is how a company organizes its people, processes, decisions, information, and assets to deliver its strategy. It covers the flow of work to the customer, the structure and spans, decision rights, governance and meeting cadence, metrics, capabilities, and where work is done. It describes how the company runs, not just who reports to whom.

What are the principles of operating model design?

Core principles are to derive design requirements from strategy, design around the flow of work, minimize and name handoffs, give each outcome one accountable owner, push decisions to the information, set spans by type of work, centralize for consistency and embed for speed, keep governance minimal, align metrics with owners, and test before rolling out.

How many layers and what span of control should a company have?

There is no universal number. Standardized, repetitive work supports wider spans and fewer layers, while complex or safety-critical work needs narrower ones. Set spans by type of work, count the resulting layers, and compare to your own best-performing units. Review cost with a span-of-control analysis rather than applying a company-wide target.

When should you centralize versus embed a function?

Centralize when consistency, scale, scarce expertise, or control matters more than responsiveness. Embed when speed, local knowledge, or proximity to the customer matters more. Decide activity by activity, write down the reason, and revisit it as the strategy changes. Many companies use a hybrid with a standard set by the center and decisions made locally.

How do you test an operating model change before a reorganization?

Pilot the new design on one flow, product, or site with success measures defined in advance, such as elapsed time, decision latency, and rework. Run it for a fixed period, adjust, and then decide on a staged rollout. Involve HR and counsel before any change affecting employees, because obligations vary by jurisdiction.

How this works in a System of Performance

An operating model changes outcomes only when the design shows up in the numbers: who owns each outcome, how long work waits, how quickly decisions are made. In most companies that evidence is scattered across systems and people, so a design is judged on opinion. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. If you want to see how much of your current flow is visible in your own data, bring it to us as a launch partner.