Most reorganisations move boxes on a chart and wait for behaviour to follow. It rarely does. The boxes change, the reporting lines change, and six months later people are collaborating, deciding and arguing in almost exactly the same way as before. The reason is that the org chart is one part of a larger system, the operating model, and changing one part while leaving the rest alone is the most reliable way to spend a year reorganising and get nothing back.

The quick version

  • Your operating model is how an organisation actually delivers value: the work that gets done, who does it, how decisions are made, and how it all connects, the bridge between strategy (what you intend) and the daily reality (what happens).
  • Ways of working are the human layer of that model: the routines, decision rights, meeting cadence and behaviours that determine how people collaborate day to day. They are the part most reorganisations forget to design.
  • The classic warning, from organisation designer Jay Galbraith, is that structure is only one of five interlocking choices, change it without changing processes, rewards and people systems, and behaviour won't move.
  • There is no universally "best" operating model. The right one fits your strategy; copied models (the famous "Spotify model" included) tend to fail because they import another company's answer without its context.

The idea in depth

An operating model answers a deceptively simple question: how do we actually deliver what our strategy promises? One of the clearest working definitions comes from Andrew Campbell and colleagues, whose Operating Model Canvas describes a model as a value-delivery chain, the sequence of work that turns inputs into the thing a customer receives, broken into six interlocking elements, captured in the acronym POLISM: Processes, Organisation, Locations, Information, Suppliers, Management systems. The point isn't the acronym; it's that an operating model is a set of choices that have to hang together, not a single chart.

Which means the first job is to stop talking about "the restructure" as if structure were the whole game. Before you touch the org chart, write down the handful of value chains your organisation actually runs, the end-to-end flows of work that produce something a customer relies on, and ask which the current design helps and which it fights. Run that exercise honestly and the real problem usually turns out not to be the boxes at all. It's a handoff, a missing decision right, or a process crossing four teams, none of whom own the outcome.

Why structure alone never changes behaviour: Galbraith's Star

The most durable idea in organisation design explains exactly why reorganisations disappoint. In the early 1970s, Jay Galbraith set out the Star Model (developed in Designing Complex Organizations, 1973, and refined in Designing Organizations): an organisation's design is the fit between five interlocking elements, strategy (direction), structure (where decision power sits), processes (how information and work flow), rewards (what gets measured and incentivised), and people (selection and development). Galbraith's central observation was practical and slightly damning: leaders habitually change structure and leave the other four points untouched, so behaviour barely moves, and performance disappoints.

flowchart TD
  S(["Strategy
the direction"]) --> ST(["Structure
where power sits"])
  S --> PR(["Processes
how work + info flow"])
  S --> RW(["Rewards
what's measured"])
  S --> PE(["People
skills + mindset"])
  ST --- PR
  PR --- RW
  RW --- PE
  PE --- ST
Galbraith's Star: strategy sets direction, and the other four choices must align to it, and to each other. Move one and the rest have to follow. Leaders Loop

The practical consequence: treat any reorganisation as a five-part change, not a one-part change. Create cross-functional product teams (structure), but keep rewarding functional output in performance reviews (rewards), keep escalating decisions to functional heads (processes and decision rights), and staff the teams with specialists who've never worked outside their silo (people), and the new structure is fighting four headwinds at once. The boxes quietly revert. Galbraith's discipline is blunt: for every structural change, ask what has to change in processes, rewards and people for this to actually work. If the honest answer is "nothing," the change probably won't stick.

Reorganising the boxes without reorganising the rewards, the processes and the people is how you spend a year and change nothing.

An honest limitation. The Star Model tells you the levers must align; it does not tell you which configuration is right for your situation. It's a checklist for coherence, not a recipe. Two companies with the same strategy can land on very different, and equally valid, operating models depending on their size, history and culture. Use the Star to stop yourself shipping a half-change, not to derive the answer from first principles.

Ways of working: the layer reorganisations forget

If structure is where power sits, ways of working are how that power gets used hour to hour, the meeting cadence, the decision rights, the team shapes, the norms about how people collaborate. This is the layer where the "Spotify model" entered the conversation. In 2012, Henrik Kniberg and Anders Ivarsson published "Scaling Agile @ Spotify", describing autonomous squads grouped into tribes, with chapters (a craft within a tribe) and guilds (a craft community across the whole company). It spread because it gave a vivid vocabulary to a hard problem: keeping small teams fast while scaling to hundreds of engineers.

Here is the cautionary part the authors themselves were careful about: the paper described how Spotify happened to be working at one moment in time, not a blueprint to copy. As Atlassian and others have since documented, even Spotify never fully "ran the Spotify model," and companies that adopted the labels without the underlying autonomy, trust and engineering culture got the org chart of Spotify and none of the speed. Steal the questions, then, not the answers. How much autonomy can each team safely hold? Where do crafts need to talk across teams? Your answers will look different from Spotify's, that's the point.

flowchart TD
  STR(["Strategy
what we're trying to win"]) --> OM(["Operating model
value chains, structure,
decision rights"])
  OM --> WOW(["Ways of working
team shapes, cadence,
norms, behaviours"])
  WOW --> DW(["Daily work
what people actually do"])
  DW -.->|"reality feeds back"| STR
The chain that breaks in most reorganisations: strategy is redrawn at the top, but ways of working, the layer nearest the daily work, is left untouched. Leaders Loop

The honest caveat on ways of working is that they are cultural, which makes them slow to change and easy to fake. You can rename teams "squads" in an afternoon; you cannot grant genuine autonomy in an afternoon, because autonomy depends on trust, on clear decision rights, and on people having the skill to use the freedom well. That's why ways of working can't be installed by decree, they're grown, modelled by leaders, and reinforced by what actually gets rewarded.

A worked example

Take a 200-person software company, call it Meridian. (Illustrative throughout; this is a teaching example, not a real company.) Strategy: move from selling one-off projects to a subscription product. Leadership's instinct is the usual one, reorganise. They dissolve the old delivery-by-client structure and stand up three cross-functional "product squads," each meant to own a slice of the product end to end.

Six months later, nothing feels different. Run it through the Star and the reason is obvious. Structure changed, but rewards didn't: account managers are still bonused on project revenue, so they keep pulling engineers onto bespoke client work. Processes and decision rights didn't: every roadmap call still goes to the old functional VPs, so the squads can't actually decide anything. And people didn't: the squads are staffed with specialists who've never owned a whole outcome and quietly wait to be told what to build.

The fix isn't another reorg. It's finishing the first one across all five points: re-write the incentive so squads are measured on product adoption and retention, not project hours; push defined decision rights down into the squads (and have the VPs visibly stop overruling them); and invest in the people layer, a few outcome-owning leads, plus coaching for specialists learning to work cross-functionally. Only when all five points move does the new structure stop reverting. The new org chart was never the change; it was one-fifth of it.

Frequently asked questions

What's the difference between an operating model and an org chart?

The org chart is just the structure, who reports to whom. The operating model is the whole system that delivers value: the value chains (the actual work), the structure, the processes and decision rights, the information and tools, and the management routines that hold it together. The org chart is one slice of the operating model, and on its own it's the least powerful slice for changing how an organisation behaves.

What's the difference between an operating model and "ways of working"?

The operating model is the architecture, how value is delivered across the whole organisation. Ways of working are the human, day-to-day layer of that architecture: team shapes, meeting cadence, decision rights in practice, and the norms about how people collaborate. The operating model decides what the teams are; ways of working decide how those teams actually behave. A coherent design needs both, and most reorganisations design the first and forget the second.

What is a "target operating model" (TOM)?

It's simply the operating model you're trying to reach, the "to be" state, set against the current "as is." The phrase comes up in transformations and post-merger integration, where it helps to describe the destination concretely before changing anything. A target operating model can be a one-page canvas or a hundred-page manual; the useful versions are specific about value chains, decision rights and ways of working, not just the new boxes.

Should we copy the Spotify model?

No, and the people who created it would agree. The 2012 paper described how Spotify worked at one point in time, not a framework for anyone else to adopt; even Spotify evolved past it. Borrow the questions it raises (how much team autonomy, how crafts connect across teams, what owns an outcome) and answer them for your own strategy and culture. Importing the labels, squads, tribes, guilds, without the underlying trust and engineering maturity tends to produce the vocabulary of agility and none of the speed.

How do we know our operating model is actually broken?

Look for the symptoms, not the chart. Decisions that take too many people and too long; work that stalls at handoffs between teams; nobody clearly accountable for an end-to-end outcome; incentives that reward the opposite of what the strategy needs. If those keep recurring after a reorganisation, the problem isn't the structure, it's one of the other four points of the Star that nobody touched.

Related in the Toolkit

An operating model is built from more specific choices, the shape of the boxes themselves (org structures) and who is actually allowed to decide what (decision rights) are the two that most often go unexamined when a reorganisation stalls.

Where to go next