A framework is a checklist for completeness. It tells you what you forgot. It does not tell you what to choose.
That distinction gets lost constantly, and it produces a specific failure: a team runs a framework, fills in every box, presents the output, and changes nothing about how a single recurring decision gets made. The framework was completed. The model was never designed.
The other thing worth knowing up front: every serious framework reduces to the same six variables. They differ in naming, sequence, and emphasis — but mostly they differ in what they take as given. That’s the useful lens, because whatever a framework assumes is the thing you’ll forget to examine.
The Common Core
Strip the vocabulary off any of them and you get some version of this:
| Variable | The question it answers |
|---|---|
| Value proposition | What we deliver and to whom |
| Capabilities | What we must be able to do to deliver it |
| Structure | How people are grouped and who reports where |
| Decision rights | Who decides what, and what triggers escalation |
| Processes and workflow | How work moves, and what the handoffs are |
| People and skills | Who does it, and what they need to be able to do |
| Technology and data | What the work runs on and what it’s measured with |
| Management system | Planning cadence, metrics, review rhythm, incentives |
Eight rows if you’re being precise, six if you collapse the obvious pairs. Every framework below covers some subset. None covers all of it, and the gaps are where the interesting failures live.
The Frameworks Worth Knowing
Galbraith Star Model — strategy, structure, processes, rewards, people.
The oldest of the modern set and still the most structurally honest. Its central claim is that the five points have to be consistent with each other, and that changing structure alone will be undone by the four you didn’t change. Most reorgs are a Star Model with four points missing.
Makes visible: misalignment between structure and incentives. Assumes given: the strategy. Use when: structure and behavior disagree and you can’t work out why.
McKinsey 7S — strategy, structure, systems, shared values, style, staff, skills.
A diagnostic, not a design tool, and better at that than it’s usually given credit for. The hard/soft split is the point: three elements you can change by decision, four you can only change by sustained behavior. That asymmetry explains most failed transformations.
Makes visible: why an announced change didn’t take. Assumes given: that the elements are all movable, which the soft ones aren’t at the speed people expect. Use when: diagnosing a change that formally happened but didn’t.
Operating Model Canvas (POLISM) — processes, organisation, locations, information, suppliers, management system.
The most operational of the set, and the one that best handles the thing others skip: locations and suppliers. If your model spans geographies or depends materially on third parties, this is the framework that won’t let you forget them.
Makes visible: delivery mechanics and external dependencies. Assumes given: the value proposition it’s delivering. Use when: you know what you’re delivering and need to work out how.
Business Model Canvas — nine blocks covering value proposition, customers, channels, revenue, cost.
Worth including precisely because it is not an operating model framework and gets used as one. It describes how you create and capture value. It is silent on how the work gets done. The two are complementary and the confusion between them is why some “operating model” documents never mention decision rights at all.
Makes visible: the economics. Assumes given: everything about execution.
Team Topologies — stream-aligned, platform, enabling, and complicated-subsystem teams, with three defined interaction modes.
The most useful recent addition, and the most specific. Its contribution is treating team interaction as a designed object rather than an emergent one. It’s software-native, but the pattern generalizes better than most people assume — any organization with a shared internal service layer is running platform teams whether it named them or not.
Makes visible: cognitive load and handoff cost. Assumes given: a product-shaped org. Use when: teams are colliding or waiting on each other.
Flow Framework — project-to-product, with flow items and flow metrics.
Narrow and deep. It measures the movement of four work types (features, defects, risks, debt) end to end, which surfaces the thing local metrics hide: that everyone’s utilization is high and nothing is finishing.
Makes visible: where work queues. Assumes given: structure and decision rights. Use when: throughput is the complaint.
RAPID / RACI / DACI — decision-rights tools.
Not operating models. Instruments for one variable — which is exactly why they’re useful. RAPID is the better of them because it separates the right to recommend from the right to decide, which is the distinction most organizations actually get wrong.
Makes visible: who decides. Assumes given: everything else. Use when: the structure is fine and decisions are still slow.
Viable System Model — Beer’s five recursive systems: operations, coordination, control, intelligence, policy.
The systems-theory ancestor of all of the above, and the only one that treats recursion seriously — the claim that every viable unit contains the same five functions at every level of scale. Heavier going than the rest, and correspondingly better at explaining why the others work.
Makes visible: whether a unit can actually self-regulate. Assumes given: a tolerance for abstraction. Use when: you want the underlying theory rather than a workshop template.
Target Operating Model (TOM) — worth naming to clear it up.
A TOM is not a framework. It’s a deliverable: the described future state. It’s produced using a framework. Treating the TOM as the framework is how organizations end up with a hundred-slide future-state document and no method for getting there.
Pick by Symptom, Not by Fashion
The framework should be chosen by what’s broken. This is a decent first cut:
| Symptom | Likely variable | Framework that surfaces it |
|---|---|---|
| Reorg happened, behavior didn’t change | Rewards and incentives | Galbraith Star |
| Change was announced and quietly ignored | Soft elements | 7S |
| Nothing finishes, everyone is busy | Flow and queuing | Flow Framework |
| Decisions take weeks with no clear owner | Decision rights | RAPID |
| Teams collide or wait on each other | Interaction design | Team Topologies |
| Handoffs and third parties are the bottleneck | Processes, suppliers | Operating Model Canvas |
| The unit can’t operate without escalation | Self-regulation | VSM |
| You know the shape is wrong but not the cause | All of them | 7S as a diagnostic first |
Two rules that save time:
Diagnose before you design. Most engagements reach for a design framework when the problem is diagnostic. You cannot design the answer to a question you haven’t specified.
One framework, one purpose. Running three in parallel produces three vocabularies for the same six variables, and the reconciliation work becomes the project.
What Frameworks Systematically Hide
Each one has a blind spot, and they are remarkably consistent.
Informal authority. Every framework maps designed authority. None maps the person everyone actually asks. That person is a real component of your operating model and appears on no diagram.
Conway’s Law. Systems tend to mirror the communication structure of the organization that built them. Which means a framework applied to a mature organization frequently just re-describes a structure that was set years ago by who happened to sit near whom. You get an elegant diagram of an accident.
Cost of transition. Frameworks describe states, not moves. Two states can both be viable while the path between them isn’t survivable. Nearly every framework is silent on the middle.
Time. Almost none of them model cadence — how fast decisions need to be made relative to how fast conditions change. A model that’s correct at annual speed and wrong at weekly speed looks identical on the canvas.
Whether anyone will use it. The distance between a documented model and a lived one is the entire discipline, and no framework addresses it because no framework can.
Where Leader Atlas Fits
Here’s the structural point, and it’s the reason framework exercises so often evaporate.
A framework produces a snapshot. An operating model is a running record.
The canvas describes the model on the day of the workshop. By the following quarter, three decisions have been reassigned, a metric has been redefined, and a new platform has changed two workflows — and the canvas, which lives in a slide deck, says none of it. The model didn’t stop existing. It stopped being written down, which in practice is the same thing.
Leader Atlas is the running record. The framework tells you what to fill in; Atlas is where it lives afterward and how it stays current.
| Framework variable | Where it lives in Atlas |
|---|---|
| Decision rights | Expectations — decision classes, owners, escalation paths, tiebreakers |
| Management system and metrics | KPI definitions, dashboards, reporting cadence |
| Strategy and direction | OKRs, roadmaps, sequencing logic |
| Processes and workflow | Workflows, SLAs, templates, documented methods |
| Technology and data | Systems, platforms, provisioning, shared accounts |
| People, culture, incentives | Mission, principles and values, hiring standard |
Two consequences.
A framework you can’t maintain is a document, not a model. The test isn’t whether the canvas was completed. It’s whether someone can change one cell of it next quarter and have the organization notice. If the artifact has no owner and no update path, it was a workshop output with a shelf life.
The framework is the input; the boundary is the output. What survives the exercise is a set of written boundaries — who decides what, measured how, within which limits. That’s a constraint that creates capacity, and it’s the only durable product of the work.
The sequence holds: Compass sets the principles, Atlas holds the boundaries and definitions, Arcade is where the work runs. Flow is the order.
How to Actually Use One
- Name the symptom first, in one sentence, before selecting anything. The symptom picks the framework.
- Pick one. Use its vocabulary for the duration and don’t blend.
- Fill it in for current state only. Future state before an honest current state is a wish list.
- Find the inconsistencies — the places where two variables contradict each other. These are the findings. The completed boxes are not.
- Translate findings into written boundaries: decision class, owner, metric definition, escalation path.
- Put those in Atlas, not in the deck. The deck is the report. Atlas is the model.
- Set a review date. A model without a revision cadence reverts to whatever it was before, quietly, in about two quarters.
Steps four through six are the work. Steps one through three are the setup, and they’re where most of the calendar goes.
Final Thought
Frameworks are lenses. Each one brings a set of variables into focus and pushes the rest out of frame, and the ones it pushes out are the ones you’ll be surprised by later.
So the question to ask of any framework is not is this the right one. It’s what does this one assume, and am I comfortable leaving that unexamined.
Answer that, use the framework to find your contradictions, and then write down the boundaries it exposed.
The framework is scaffolding. The written boundaries are the building.
