Most companies do not have an operating model.
They have an org chart and a set of habits.
An org chart shows reporting lines. An operating model answers a harder question:
How does this organization convert strategy into repeated decisions?
That distinction matters, because strategy failure is rarely a thinking failure. It is almost always a conversion failure — the strategy was sound, and the model underneath it could not carry the load.
What an Operating Model Actually Is
An operating model is the set of choices that determine how work moves through an organization.
Six components. All six exist whether you designed them or not.
| Component | The Question It Answers |
|---|---|
| Orientation | What do we organize around — function, product, customer, geography? |
| Decision rights | Who decides, who is consulted, who is merely informed? |
| Structure | Where do people report, and where does budget sit? |
| Workflows | How does work actually travel from intake to delivery? |
| Capabilities | What do we build in-house, share, or buy? |
| Measurement | What gets counted, and who is accountable for it? |
If any of these are undefined, they get defined informally — by whoever is loudest, most tenured, or closest to the CEO. That is still an operating model. Just an unmanaged one.
Two Axes, Not One
Most articles on this topic collapse everything into a single list. That is why the advice is usually useless.
Operating models vary along two independent axes, and you choose on both.
Axis 1 — Orientation: what the model organizes around
| Orientation | Optimizes For | Trade-off |
|---|---|---|
| Function | Depth of craft, technical standards | Slow cross-functional delivery |
| Product | Ownership, speed, clear P&L | Duplicated capability |
| Customer / segment | Relevance, retention, lifetime value | Fragmented product roadmap |
| Geography | Local fit, regulatory compliance | Inconsistent brand and standards |
| Channel | Conversion efficiency per surface | Disjointed customer experience |
| Capability | Reuse, leverage, scale | Distance from the customer |
Axis 2 — Structure: where authority sits
Centralized. Federated. Decentralized. Networked.
A functional orientation with decentralized authority behaves nothing like a functional orientation with centralized authority. Naming only the orientation — “we’re product-led” — tells you almost nothing about how the company actually runs.
The Eight Structural Types
1. Functional (Unitary)
One org, organized by expertise. No divisional P&Ls. Decisions escalate to a small executive team that holds the whole picture.
- Wins when: the company sells a tightly related product set and technical depth is the competitive edge
- Breaks when: the portfolio diversifies faster than the executive team can arbitrate
- Example: Apple runs functionally at extraordinary scale — hardware, software, and design report up as disciplines, not as business units, with the CEO as the primary integrating layer
- Failure signal: the executive calendar becomes the bottleneck for every cross-team decision
2. Divisional / Holding (Decentralized)
Autonomous units with their own P&L, resources, and near-total operating freedom. The center allocates capital and sets guardrails. That’s it.
- Wins when: units serve genuinely different markets and local speed beats global consistency
- Breaks when: the units need each other and no one owns the seam
- Examples: Berkshire Hathaway at the extreme end; franchise systems like McDonald’s, where the center owns brand, supply, and standards while operators own execution
- Failure signal: four teams building the same capability, none aware of the others
3. Matrix
Two reporting lines — typically function and geography, or function and product. Designed to get depth and market fit simultaneously.
- Wins when: you genuinely need both dimensions optimized and you have the maturity to manage the tension
- Breaks when: there is no explicit tiebreaker
- Examples: most large CPG and industrial firms — Unilever, P&G — run some version of this
- Failure signal: meetings with twelve attendees and no decision-maker
The matrix is the most-blamed model in business, and the blame is usually misplaced. Matrices don’t fail because two bosses is inherently unworkable. They fail because nobody wrote down which boss wins on which decision type. That is a documentation problem, not a structural one — and it is fixable.
4. Hub-and-Spoke (Federated)
A central team owns standards, systems, and shared assets. Local teams own execution and customer relationships. Authority is split by decision class, not by seniority.
- Wins when: you need brand and compliance consistency across many locations or markets, but local nuance still drives conversion
- Breaks when: the hub sets standards it cannot enforce, or the spokes are measured on metrics the hub controls
- Example: essentially every multi-location retail, healthcare, and insurance brand converges here
- Failure signal: the hub publishes a playbook; the spokes ignore it; nobody notices for two quarters
5. Shared Services and Centers of Excellence
These get used interchangeably. They are not the same thing, and confusing them is expensive.
| Shared Services | Center of Excellence | |
|---|---|---|
| Purpose | Do the work at lower unit cost | Raise the standard of work done elsewhere |
| Output | Completed transactions | Standards, enablement, tooling |
| Measured on | Cost per unit, SLA adherence | Adoption, capability lift, quality variance |
| Fails when | Treated as a strategy function | Treated as a delivery team |
- Wins when: the work is high-volume and standardizable (shared services) or high-skill and scarce (CoE)
- Breaks when: a CoE gets loaded with delivery tickets and quietly becomes an under-resourced shared service
- Failure signal: your CoE has a queue
6. Product / Platform
Small, durable, cross-functional teams with end-to-end ownership of a product surface, sitting on shared internal platforms they consume as services.
- Wins when: the work is continuous rather than project-based, and internal reuse is a real source of leverage
- Breaks when: teams get autonomy before the platform exists to support it
- Example: Amazon’s two-pizza teams and single-threaded ownership work because the internal service layer underneath them was built first
- Failure signal: every team maintaining its own version of the same infrastructure
7. Agile Pod (Squad and Tribe)
Persistent multi-disciplinary pods grouped into larger domains, with craft communities cutting across for skill development.
- Wins when: discovery matters as much as delivery and requirements change faster than annual planning
- Breaks when: copied as a structure without the underlying culture of trust, or when pods have no clear customer
- Example: the Spotify model is the most-cited version — worth noting that Spotify itself moved on from it, which is the lesson, not a footnote
- Failure signal: pods that require six approvals to ship
8. Network / Ecosystem
Internal units operate as market-facing micro-businesses that contract with each other and with outside partners. The center orchestrates rather than directs.
- Wins when: the market rewards adaptation over predictability
- Breaks when: internal transaction costs exceed the coordination they replace
- Example: Haier’s RenDanHeYi model — thousands of micro-enterprises, each with its own P&L and the right to source internally or externally
- Failure signal: more energy spent on internal negotiation than customer value
Choosing: The Fit Test
Pick based on your binding constraint, not on what impressed you at a conference.
| If your binding constraint is… | The model that fits |
|---|---|
| Inconsistent quality across teams | Functional or CoE |
| Slow local response | Federated or decentralized |
| Duplicated cost and effort | Shared services or platform |
| Slow cross-functional delivery | Product or pod |
| Conflicting global and local priorities | Matrix — with written tiebreakers |
| Unpredictable, fast-shifting demand | Network |
One constraint at a time. Models designed to solve four problems at once solve none of them.
This is where constraints do the useful work. A model that forbids something specific is stronger than one that permits everything.
Where Leader Atlas Fits
An operating model that isn’t written down is not a model. It is a preference held by whoever is currently in the room.
Leader Atlas exists for exactly this: it is the artifact layer where the operating model stops being an intention and becomes something a team can actually operate.
Map the components directly.
| Operating Model Component | Atlas Aspect | What Breaks Without It |
|---|---|---|
| Orientation | Mission and vision, principles and values | Teams optimize for different things and call it misalignment |
| Decision rights | Expectations, leaders and teams, coverage | Every decision escalates; the matrix deadlocks |
| Structure | Fundamentals — distribution lists, standing meetings, groups we work with, vendors | New hires spend six weeks finding out who owns what |
| Workflows | Workflows, onboarding, provisioning, fulfillment, SLAs | The model works when the veterans are present and collapses when they are not |
| Capabilities | Systems and platforms, tools we use, shared accounts, documentation | Duplication in a federated model, bottlenecks in a centralized one |
| Measurement | OKRs, KPIs, dashboards, reports | Teams get held accountable for outcomes they don’t control |
| Sequencing | Roadmaps, RED | Everything is priority one; nothing compounds |
Three consequences worth stating plainly.
Different models require different Atlas depth. A federated model lives or dies on documented standards — the hub’s only real authority is the clarity of what it publishes. A functional model needs far less written coordination and far more written craft standard. Same framework, different weighting.
SLAs are decision rights in disguise. The moment you write “the central team responds within 48 hours,” you have defined who waits on whom. That is structure, expressed as a commitment.
Metrics enforce the model whether you intend it or not. Give a federated location team a KPI that only the hub can move, and you have not built a federated model. You have built resentment. This is the same principle behind scoping accountability to what teams control.
The full picture: Compass sets the principles the model must respect. Atlas documents the model. Arcade runs it day to day. The Flow sequence is deliberate — a model documented without principles is bureaucracy, and a model run without documentation is folklore.
The Onboarding Audit
There is a fast, unforgiving test for whether your operating model is real.
Hand a new hire your Atlas on day one. Watch what they can answer without asking a person:
- Who decides when two teams disagree?
- What am I accountable for, and what am I only consulted on?
- Where does work come from, and where does it go when I’m done?
- What am I measured on in 90 days?
- What is centrally owned, and what is mine to decide?
Every question they have to ask a human is an undocumented dependency. Count them. That number is your operating model’s real maturity score — and it is the same number that predicts how badly things degrade when a key person leaves.
Five Ways Models Break
- The org chart changed; the decision rights didn’t. Boxes moved, behavior didn’t. The most common reorg outcome.
- A matrix with no tiebreaker. Two bosses is workable. Two bosses and no written rule for who wins is not.
- A CoE with no adoption mechanism. Standards without either mandate or genuine pull are just published opinions.
- Pods without a platform. Autonomy granted before the shared infrastructure exists produces duplication, not speed.
- Federation without a standard. Local freedom is a strategy when the guardrails are explicit. When they aren’t, it’s just drift with better branding.
Changing an Operating Model
Sequence matters more than design quality. Most transitions fail because the org chart moves first.
- Name the binding constraint. One. In a sentence. If you can’t, you’re not ready to redesign anything.
- Fix decision rights. Cheapest change, largest effect, and it can be tested before anyone’s reporting line moves.
- Rewrite the Atlas. Workflows, SLAs, ownership. Documentation is not the record of the change — it is the change.
- Re-cut the metrics. Every team should be measured on something it can actually move under the new model.
- Move the boxes last. Structure ratifies a model that is already working. It cannot create one.
Run steps 2 through 4 for a quarter before step 5. If the new model doesn’t function on paper and in behavior, it will not start functioning because you redrew the hierarchy.
Final Thought
There is no correct operating model. There is only the model that matches your current constraint, and the honesty to change it when the constraint moves.
The organizations that scale well are rarely the ones that picked the cleverest structure. They are the ones that wrote theirs down, tested it against reality, and revised it before it broke.
Structure is a hypothesis.
Documentation is what makes it testable.
