Most operating model design fails at the sequence, not the content.
The work starts with a structure workshop, produces a target org chart, and gets socialized as a transformation. Six months later the boxes have moved and the behavior has not, because nobody ever wrote down who decides what.
Design is not drawing the new structure. Design is deciding how the organization will make its recurring decisions, and then arranging everything else to support that. Structure is the last output, not the first.
What follows is the order that works, the artifact each step must produce, and the test that tells you whether the design is real before you spend political capital on it.
Before You Start: Two Preconditions
You are redesigning something that already exists. Every organization has an operating model. If nobody designed it, it was defined informally — by whoever is loudest, most tenured, or closest to the CEO. That is still a model. You are not creating one from nothing; you are replacing an unmanaged one, and the unmanaged one has incumbency.
Design is not strategy. Strategy decides what you compete on. The operating model decides how that becomes repeated decisions. If the strategy is still contested, stop. You cannot design an engine for a destination nobody has agreed on.
The Sequence
| # | Step | Artifact it produces | Done when |
|---|---|---|---|
| 1 | Name the binding constraint | One written sentence | Leadership can repeat it without the deck |
| 2 | Run the decision census | List of recurring decisions with owners | Every decision has exactly one owner |
| 3 | Choose orientation and authority | Two explicit choices, per capability | Both axes are named, not just one |
| 4 | Define the interfaces | Consumption and guarantee table | Every team knows what it can rely on |
| 5 | Set the funding model | Budget allocation rule | Money follows the new unit of work |
| 6 | Cut the metrics | Metric-to-owner map | No team is measured on what it can’t move |
| 7 | Write it down | Atlas | A new hire can answer without asking |
| 8 | Backtest and pilot | Decision replay, one value stream | The model survives real cases |
| 9 | Move the structure | New org chart | The behavior already changed |
Steps 1 through 8 cost almost nothing and are reversible. Step 9 is expensive and is not. Most programs run them in reverse.
Step 1 — Name the Binding Constraint
One constraint. One sentence. Falsifiable.
Not “we need to be more agile.” That is a mood. Something like: cross-functional work takes eleven weeks and needs to take four, or output quality varies enough between teams that we re-do a third of it, or four teams are building the same capability and none of them know it.
The constraint determines everything downstream. Different constraints point at genuinely different models, and the full landscape of structural types only becomes useful once you know which problem you are solving.
If you cannot name one constraint, you are not ready to design. Models built to solve four problems at once solve none of them — this is where constraints do the real work. A model that forbids something specific is stronger than one that permits everything.
Write the constraint at the top of the design document. Every subsequent decision gets tested against it.
Step 2 — Run the Decision Census
This is the step almost nobody does, and it is where the design is actually made.
List the twenty to thirty decisions that genuinely determine your outcomes. Not tasks. Decisions — the moments where someone chooses and the organization commits. Pricing exceptions. Roadmap sequencing. Hiring approvals. Vendor selection. Quality sign-off. What gets killed.
For each one, capture four things:
| Field | Question |
|---|---|
| Owner | Who decides — one name, one role |
| Consulted | Who must be heard, and by when |
| Tiebreak | Who wins when consultation deadlocks |
| Latency | How long the decision is allowed to take |
Three rules make this useful rather than decorative.
One owner per decision. If two names appear, you have not made a design choice, you have documented an argument. Split the decision until each half has a single owner.
Latency is a design parameter. A decision with no time limit escalates by default. Writing “72 hours, then it defaults to the owner” converts a bottleneck into a rule.
Compare against reality. Fill a second column with who currently decides. The gap between the two columns is your entire change program. Everything else is packaging.
Decision rights are the cheapest thing to change and the highest-leverage. They can be tested for a quarter before anyone’s reporting line moves. Document them in Expectations so they outlive the meeting they were agreed in.
Step 3 — Choose Orientation and Authority. Both.
Two independent axes. Most designs name one and assume the other, which is why so many models behave nothing like their description.
Orientation — what you organize around: function, product, customer segment, geography, channel, capability. The functional and product options are the two most consequential, and they carry opposite cost structures: functional pays coordination cost, product pays duplication cost.
Authority — where decisions sit: centralized, federated, decentralized, networked. A functional org with distributed authority behaves nothing like a functional org with centralized authority, which is the whole point of treating centralization as a separate axis.
Choose both, and choose per capability rather than per company. Brand standards and security can be centrally functional while customer-facing surfaces are product-owned. That is not inconsistency, it is precision. What breaks organizations is leaving the split undocumented — undocumented splits get resolved by whoever is in the room, and re-resolved differently next quarter.
Sanity check each choice against the constraint from Step 1. If a choice does not relieve the constraint, it is preference, not design.
Step 4 — Define the Interfaces
Structure gets the attention. Interfaces determine whether the thing works.
For every team in the target model, write three lines:
- Owns — what this team decides alone and is accountable for
- Consumes — what it depends on from others to deliver
- Guarantees — what others can rely on from it, and within what time
That third line is where models live or die. A service level is a decision right in disguise: the moment you write “the central team responds within 48 hours,” you have defined who waits on whom. Publish the guarantee, or the dependency becomes a negotiation every single time.
Then count the interfaces. Every dependency between teams is a permanent tax on every future decision, which is why reducing complexity is a design activity and not a cleanup project. If your target model has more interfaces than the current one, you have probably designed a coordination problem and labeled it a transformation.
Step 5 — Set the Funding Model
The funding model is the operating model. Everything else is commentary.
Ask one question: after this change, does money follow projects or does it follow teams?
Project funding routes every priority through a central allocation decision, which means a central function arbitrates — regardless of what the org chart says. Persistent team funding means the team already holds the resources and decides how to spend them. You cannot grant outcome ownership to a team that has to ask permission to staff the work.
This is the step transformations skip, and skipping it is why so many produce product vocabulary sitting on top of functional mechanics. New titles, old physics.
Decide it explicitly, write the allocation rule, and name who can override it.
Step 6 — Cut the Metrics to Match
Every team should be measured on something it can actually move under the new model.
Give a local team a target that only a central team can influence, and you have not built a federated model. You have built resentment, and it will be attributed to the structure rather than to the measurement.
Map it directly: metric, owner, the levers that owner controls, review cadence. Where a metric depends on a lever the owner does not hold, either move the lever or change the metric. There is no third option, and the version where you “align on it collaboratively” is the failure mode.
Land the results in OKRs and KPIs with the sequencing captured in roadmaps, so accountability and priority are visible in the same place. The discipline of scoping accountability to what teams control applies here more than anywhere else in the design.
Step 7 — Write It Down
An operating model that isn’t written down is not a model. It is a preference held by whoever is currently in the room.
The written design is not a slide deck. A deck is a persuasion artifact with a shelf life of one meeting. The design is a working document: decision rights, interfaces, workflows, service levels, funding rules, metric ownership, escalation paths. That is what Leader Atlas exists to hold — the layer where the model stops being an intention and becomes something a team can operate.
Two calibrations worth making deliberately:
- A product-oriented design needs heavy interface documentation. Autonomy without written contracts is drift.
- A functional design needs lighter interface documentation and far heavier craft standards, because the function’s authority is only ever as strong as the bar it publishes.
The Flow sequence holds throughout: Compass sets the principles the model must respect, Atlas documents it, Arcade runs it day to day. A model documented without principles is bureaucracy. A model run without documentation is folklore, and folklore leaves when its carrier does.
Step 8 — Backtest, Then Pilot
Every operating model looks excellent in the deck. Test it before you commit.
The decision replay. Take the fifteen hardest real decisions from the last two quarters — the contested ones, the ones that took too long. Run each through the new design on paper. Who decides? How fast? What happens when the consulted parties disagree? If replaying real history produces the same deadlocks under the new model, the design has not solved anything. This exercise takes an afternoon and it is the highest-yield hour in the entire program.
The three load tests.
| Test | What it asks | What failure looks like |
|---|---|---|
| Name removal | Delete your three strongest operators from the design | The model only functions with specific individuals |
| Volume | Double the workload | Escalation volume rises faster than output |
| Conflict | Two owners want opposite things | No written tiebreak exists |
The pilot. One value stream, one quarter, real work — with the new decision rights, new metrics, and new funding rules, inside the existing structure. If the model does not work while the boxes are unchanged, redrawing the hierarchy will not rescue it. It will only make the failure permanent and expensive.
Step 9 — Move the Structure, Then Set a Review Cadence
Structure ratifies a model that is already working. It cannot create one. Move it last, and move it once.
Then treat the design as a hypothesis with an expiry date. The constraint you designed against will move — because the portfolio grows, because tooling changes what a small team can do, or because capital conditions change how much duplication the business can carry. Cost pressure quietly recentralizes organizations that still describe themselves as autonomous, so keep a standing read on the economic picture rather than discovering the shift halfway through a planning cycle.
Schedule the review. Twice a year, ask two questions: is the constraint we designed against still the binding one, and does the decision census still match who actually decides? If either answer has drifted, redesign the affected part deliberately — before it redesigns itself.
How the Design Fails
Five patterns account for nearly all of it.
- The org chart changed; the decision rights didn’t. The most common reorg outcome, and the most expensive.
- The funding model never moved. New model, old money, old behavior.
- Teams own outcomes they lack levers for. Accountability without authority produces attrition, not performance.
- A center sets standards it cannot enforce. Standards with neither mandate nor genuine pull are published opinions.
- The design was never written past the deck. It survives exactly as long as the people who were in the room.
Note that four of the five are failures of the sequence, not of the structural choice. The model you pick matters far less than the order in which you implement it.
The Design Review Checklist
Before signing off, answer these in writing. If any answer needs a meeting, the design is not finished.
- What is the one binding constraint, in a sentence?
- Which twenty decisions matter most, and who owns each one?
- What is the orientation, and separately, where does authority sit?
- What does each team own, consume, and guarantee?
- Does money follow teams or projects after the change?
- Is every metric owned by someone who controls its levers?
- What happened when we replayed last quarter’s hardest decisions through this?
- What is the review date, and who owns it?
For the wider frameworks and examples behind this, the complete operating model guide covers the landscape, and defining the target operating model is what turns this design into a sequenced destination.
Final Thought
Designing an operating model is not an architecture exercise. It is the work of deciding, in advance and in writing, how your organization will decide.
Do that well and the structure is almost an afterthought. Skip it and no structure will save you.
The boxes are the easiest part. That is why so many programs start there.
