Most leaders who copy a famous operating model end up with new labels and the same old delays. They launch squads without shared goals, or set quarterly OKRs that nobody reviews. The org chart changes. Accountability and execution don't.
The problem is rarely that leaders chose the wrong diagram. It's that they copied the visible structure without building the decision rights, management rhythm and measures that make it work. A team called a squad still waits for approval if nobody has clarified what it can decide. An OKR still becomes shelfware if leaders don't review progress and act on blockers.
Below are eight examples of operating models, examined as execution systems. For each, I focus on how the work is structured, how governance operates, where OKRs can fit, and what the model makes harder. Famous company stories are useful as illustrations, not templates. The test is whether the mechanics suit your organisation, whether you're a scale-up trying to reduce priority churn or an enterprise coordinating work across functions.
1. Amazon's Small Single-Threaded Teams and Working Backwards
Amazon's team model starts with ownership, not a reorganisation announcement. Small teams own a defined customer or business outcome, and a single-threaded leader gives that outcome focused attention rather than splitting it across competing priorities. The familiar two-pizza idea is a useful shorthand for keeping teams small, but team size alone doesn't create speed. Clear authority and limited scope do.
The Working Backwards method adds a test before teams commit resources. People write a press release and FAQ that describe the customer result they intend to deliver. That forces the team to explain the value in plain language before the work becomes a backlog of features. Amazon's internal PR/FAQ process is used to develop proposals before funding decisions.
Where OKRs fit
Amazon Web Services and retail teams operate as separate outcome-owning units, with their own metrics. For a business adapting this approach, an OKR should clarify the result a team owns, not add another layer of reporting. Give each team a primary objective for its planning cycle, name one accountable owner, and make dependencies visible. Shared ownership can sound collaborative, but it often obscures who must resolve a stalled decision.
Practical rule: Before approving an initiative, ask the proposed owner to explain the customer outcome on one page.
The trade-off is that strong team autonomy can create local optimisation. Teams may hit their own targets while creating friction for another part of the customer journey. Review dependencies on a regular cadence and remove those that add more delay than value. I've seen scale-ups struggle less from a lack of effort than from teams juggling too many priorities and owning none clearly. Amazon's mechanics address that problem, but only if leaders protect focus.
For a closer look at how to balance autonomy with accountability, see my piece on autonomy at work.
2. Spotify's Squads, Tribes, Chapters and Guilds
Spotify's organisational language is well known. Its engineering model grouped small, cross-functional squads around product areas, related squads into tribes, people with the same craft into chapters, and employees with shared interests into guilds. The original account by Henrik Kniberg and Anders Ivarsson described how Spotify was working at a particular point in its development. It wasn't a universal blueprint, and Spotify later described the model as a snapshot in time rather than a template.
That distinction matters. A scale-up can copy the words “squad” and “tribe” while keeping the old approval chain intact. The result is two systems layered on top of each other: teams carry new labels, but decisions still travel through traditional management. That adds coordination cost without giving teams meaningful autonomy.
Copy the alignment, not the labels
Squads need measurable objectives connected to broader product or business outcomes. Chapters can support professional development and line management, while squads handle day-to-day delivery, but separating those responsibilities only works if leaders can staff and coordinate both roles. Guilds can help people share practice, but they shouldn't become another approval forum.
I'd start by deciding what alignment problem needs solving. Is it duplicated work across product teams, inconsistent technical standards, or unclear ownership of a customer journey? Then define how teams will share goals, surface dependencies and make decisions. A squad's autonomy should be reviewed against results, not inferred from its name.
The model suits organisations that need cross-functional product delivery and can support the coordination around it. It's less suitable when leaders expect structure alone to fix unclear priorities. My guide to operating model design focuses on the decisions and interfaces that need to be clear before teams are renamed.
3. Haier's Microenterprises and RenDanHeYi
Haier took a radical route to bring decisions closer to customers. The Chinese appliance manufacturer reorganised around microenterprises, with units accountable for market results rather than waiting for decisions to travel through a traditional hierarchy. Its RenDanHeYi approach links people, orders and customers. Chairman Zhang Ruimin led a shift that unfolded over many years.
The practical idea is straightforward, even if the transformation is not. A unit responsible for sales, service and product results can respond to customer signals more directly than a function that owns only one hand-off in the chain. But distributing accountability doesn't automatically produce sound commercial decisions. Teams need clear customer outcomes, reliable measures and the capability to understand their financial performance.
Put contracts around autonomy
A microenterprise model needs explicit agreements between the business units and the shared platforms that support them. Those agreements should clarify what each unit owns, how it contributes to customer outcomes, and which capabilities the centre provides. If every unit builds its own version of shared infrastructure, local speed can become enterprise duplication.
Haier's appliance business offers a real-world illustration of unit-level accountability across sales, service and product results. The mechanics are relevant to larger businesses too, but full P&L responsibility isn't a shortcut to giving teams more control. Teams need financial literacy before leaders hand over commercial accountability. Otherwise, they may own numbers they can't interpret or influence.
Use this model when slow decisions and distant customer feedback are persistent problems, and when leadership is prepared to build the skills and governance that distributed ownership requires. Keep shared platforms focused on capabilities units can't reasonably build alone. Give every unit a measurable outcome, then review both local performance and the effects on the wider system.
4. Intel and Google's OKR-Driven Operating Rhythm
OKRs work when they shape how leaders allocate attention, review delivery and respond to evidence. Andy Grove introduced Objectives and Key Results at Intel and described the method in High Output Management. John Doerr brought it to Google, where the approach became part of how the company set and tracked priorities as it grew.
The operating model isn't the acronym. It's the rhythm around it: leaders set priorities, teams connect their work to those priorities, people check progress, and the organisation reviews what happened at the end of the cycle. Google's use of OKRs helped align engineering and product work as its product range expanded. Scale-ups also use quarterly cycles to reset priorities after rapid hiring, when yesterday's organisation chart no longer matches today's workload.
Make the review useful
A team should be able to see how its objectives connect to leadership priorities and what evidence will show progress. Keep objectives limited enough that teams can make real trade-offs, and write key results as changes in outcomes rather than lists of tasks. A weekly check-in should surface progress, blockers and decisions required. It shouldn't become a status recital.
Quarterly planning without regular review is just a document with a date on it.
The common failure is ceremonial planning. Leaders agree priorities, publish them, then keep funding every existing initiative. Teams learn that the written goals don't govern actual decisions. Another failure is treating scoring as a performance ranking, which encourages safe targets and selective reporting. Separate learning about delivery from individual performance judgements so teams can raise risks openly.
For the rhythm to stick, leaders must stop, change or resource work when the evidence calls for it. I explain the practical mechanics in my guide to building an operating rhythm.
5. Toyota Production System's Lean Operating Model
Toyota's production system links daily problem-solving to the work itself. Developed by Taiichi Ohno and Eiji Toyoda after the Second World War, it rests on just-in-time production and jidoka, the practice of building quality into the process. When a defect appears, a worker can use an andon cord to stop the line and make the problem visible instead of letting it travel downstream.
That authority is only useful if leaders respond constructively. At the point of work, teams investigate causes and agree actions. A3 reports help people define a problem, understand its causes and track a response. Leaders use gemba walks to see the work directly rather than relying only on summaries. Jeffrey Liker's The Toyota Way later set out the principles behind the system.
Connect local fixes to strategy
A team can improve its own process and still miss the organisation's priorities. Leaders need to connect daily measures, such as cycle time or errors, to the outcomes the business has chosen to improve. Start with one value stream and one defined problem. Make performance visible where the work happens, then use a short daily review to surface blockers and assign action.
Healthcare organisations have adapted Toyota principles to patient safety, including Virginia Mason Health System in Seattle. The sector differs, but the operating lesson transfers: make problems safe to raise, investigate them close to where they occur, and follow through on the agreed fix. A transformation programme that reports activity but doesn't change frontline work won't create that discipline.
For leadership teams, the trade-off is between standardisation and local learning. A common method helps people solve problems consistently, but forcing identical processes onto different workflows can add waste. Link improvement targets to strategic priorities, while letting frontline teams identify practical changes. My guide to cycle time reduction explores how leaders can focus on flow rather than activity counts.
6. Zappos' Holacracy and the Cost of Structural Change
Holacracy attempts to replace conventional job titles and managers with defined roles and formal governance rules. Zappos announced its move towards the system in 2013, driven by a belief that traditional hierarchy slowed decisions. In 2015, it offered employees a severance package if they didn't want to work under the new model. The company's experience shows the human and operational cost that can accompany a major structural shift.
The lesson isn't that Holacracy always fails. It's that a new decision system requires more than new terminology. People need to understand where authority sits, how roles change, how disagreements are resolved and what happens when responsibilities overlap. Without that clarity, a structure intended to remove bottlenecks can create more meetings and uncertainty.
Treat the transition as operating work
A leader considering this kind of change should first state the business problem in plain language. If decisions are slow, identify where they get stuck and why. Then pilot a different governance approach in a contained area and review whether decisions become clearer, faster and more accountable. Don't assume the whole organisation needs the same intervention.
- Build capability: Plan for training, facilitation and a transition period that gives people time to learn the rules.
- Keep outcomes visible: Use objectives and measures to help teams understand what success looks like during structural change.
- Listen for friction: Check whether people understand their roles and can resolve tensions without creating a parallel approval system.
The trade-off is clear. Formal rules can make authority more explicit, but the system takes effort to learn and maintain. Leaders who focus on the launch announcement and neglect capability building leave employees to interpret the new structure while still trying to deliver the old workload. My article on organisational change management covers how to manage that execution risk.
7. Buurtzorg's Self-Managing Teams in Home Care
Buurtzorg's model puts care teams close to the people they serve. Founded by Jos de Blok in the Netherlands, the organisation uses self-managing neighbourhood teams of nurses. Teams handle practical responsibilities such as scheduling, recruitment, quality and training, while central support stays focused on enabling frontline work.
That setup can reduce the distance between a care need and the decision to respond. It also puts more responsibility on each team. Autonomy won't work if teams lack shared standards, access to support or clear ways to assess the quality of their service. A small central function can enable teams, but it still needs the right capabilities and a clear remit.
Give teams boundaries they can use
Before delegating decisions, leaders should define the outcomes and standards that matter. Make relevant measures visible at team level so people can discuss service quality and identify where support is needed. Team objectives should connect to organisation-wide quality priorities, but shouldn't drown nurses in reporting that doesn't improve care.
Buurtzorg has grown across the Netherlands, and care providers in Europe and North America have studied its approach when redesigning community care. The model suits work where local knowledge and continuity matter, and where teams can take responsibility for coordinating their own delivery. It may be difficult to transfer unchanged into an organisation with rigid processes, fragmented systems or limited support for team-level decision-making.
The trade-off is between consistency and local judgement. Shared standards protect service quality, while teams need enough room to respond to individual circumstances. Leaders should keep central support focused on coaching and capability, not on reclaiming every decision when a team encounters difficulty.
8. Netflix's Freedom and Responsibility Culture
Netflix's culture deck, developed by Reed Hastings and Patty McCord and later published publicly, set out an approach built around freedom and responsibility. Leaders share business context and push decisions towards people closest to the work. The idea is often summarised as “context, not control”. That phrase doesn't mean leaders step away. It means they provide clear priorities and constraints, then expect people to make sound decisions.
Netflix's model depends on performance standards and hiring choices that support a high degree of trust. The company has described a “keeper test” in which managers ask whether they would fight to keep each team member. That approach may not suit every organisation or culture. It also doesn't remove the need for clear objectives and regular conversations about results.
Freedom requires accountability
Many leadership teams want the freedom but resist the responsibility that goes with it. Delegating a decision without explaining the business context leaves people guessing. Telling teams they're accountable without defining good performance creates subjective judgement. Both undermine trust.
- Share context: Explain priorities, constraints and trade-offs before handing decisions to teams.
- Define outcomes: Agree what success looks like in measurable terms, then discuss progress against those outcomes.
- Address gaps: Deal with performance problems directly. Autonomy without accountability weakens the model.
The culture deck has influenced scale-ups looking to reduce approval layers, but copying its language doesn't reproduce the conditions that support the model. Leaders still need to set priorities, monitor results and act when performance falls short. Use this approach when teams have the judgement and information to make decisions, and when leadership is prepared to be clear about standards.
Operating Models: 8-Example Comparison Matrix
| Operating Model | Implementation Complexity | Resource Requirements | Expected Outcomes | Ideal Use Cases | Key Advantages |
|---|---|---|---|---|---|
| Amazon: Small Teams and Working Backwards | Moderate; requires clear ownership and disciplined product planning | Small autonomous teams, accountable leaders, customer research and planning time | Clearer priorities and faster decisions focused on customer outcomes | Large or diverse product portfolios with distinct customer needs | Strong ownership, customer focus and local decision-making |
| Spotify: Squads, Tribes, Chapters and Guilds | Moderate to high; requires careful coordination and cultural alignment | Cross-functional squads, coordination across teams, and capacity for skill development | Greater team autonomy, product ownership and peer learning | Technology product organisations that need autonomous teams and shared craft development | Flexible structure and strong local ownership |
| Haier: Microenterprises and RenDanHeYi | High; requires major organisational and governance changes | Many self-managed units, shared platforms, and mature financial and performance management | Faster market response and accountability for customer and business results | Large organisations seeking to decentralise decisions and link units to market demand | Customer proximity, unit-level accountability and employee ownership |
| Intel and Google: OKR-Driven Operating Rhythm | Moderate; requires consistent planning, check-ins and reviews | Leadership commitment, measurement capability and regular team time | Visible priorities, measurable progress and better cross-team alignment | Organisations that need a recurring system for setting and tracking priorities | Shared focus, transparency and regular opportunities to adjust |
| Toyota Production System: Lean | Moderate to high; requires sustained process improvement and leadership involvement | Standardised processes, frontline participation, problem-solving training and regular observation | Reduced waste and defects, with problems addressed closer to their source | Manufacturing and other process-heavy environments seeking quality and efficiency improvements | Continuous improvement, early problem detection and strong quality practices |
| Zappos: Holacracy | High; requires substantial role redesign, training and transition management | Governance and facilitation time, employee training and capacity to manage transition disruption | More explicit accountabilities and distributed decision-making | Organisations prepared to replace conventional management structures with formal role-based governance | Transparent roles and structured decision processes |
| Buurtzorg: Self-Managing Teams | Moderate to high; depends on capable teams and clear standards | Skilled professionals, a small support function, coaching and consistent outcome measures | More local decision-making, frontline ownership and lower management overhead | Community-based care and other services delivered by skilled frontline professionals | Low overhead, team autonomy and decisions close to clients |
| Netflix: Freedom and Responsibility | High; depends on leadership maturity and clear performance expectations | High-performing staff, candid feedback, transparent context and strong management capability | Faster decisions with greater individual accountability | Knowledge-work organisations able to support autonomy and high performance standards | Reduced bureaucracy, faster decisions and clear accountability |
Choose the Model Your Execution Problem Needs
Don't select an operating model because a famous company uses it. Start with the delay, confusion or missed outcome you need to address. Then choose the smallest change that clarifies ownership, speeds a decision or makes delivery more reliable. The structure should solve a real problem, not give an old process a new name.
Unclear ownership points towards Amazon-style single-threaded teams. Slow decisions may call for smaller units closer to the customer, as Haier's microenterprises illustrate. Inconsistent delivery often needs a fixed quarterly rhythm with visible OKRs, regular check-ins and leadership action when work slips. These are different problems. Adding team autonomy won't fix unclear priorities, and introducing more governance won't help if no one knows who owns the result.
Match the design to the work
A product organisation with overlapping teams may borrow Spotify's focus on cross-functional delivery, but it must make alignment and decision rights explicit. A frontline service dealing with recurring defects may learn more from Toyota's problem-solving discipline than from a wholesale restructure. A care provider may value Buurtzorg's local ownership, while a business considering Holacracy should account for the learning and transition burden. Netflix-style freedom can suit teams that have clear context and strong accountability, but it won't compensate for weak performance management.
Use OKRs to connect the chosen structure to measurable outcomes. Each priority needs an accountable owner, a result that signals progress, and a review forum where leaders can resolve dependencies and make trade-offs. Don't set goals that sit outside normal management routines. The UK Office for National Statistics found a statistically significant relationship between management-practice scores and labour productivity, including a correlation between a 1% increase in labour productivity and a 0.02 increase in the management-practice score (ONS analysis of management practices). That's a reason to take management routines seriously, not a guarantee that adopting a particular model will raise productivity.
As your organisation grows, revisit who owns outcomes, how cross-functional trade-offs are made and which forums support decisions. A structure that worked when leaders could resolve dependencies informally may struggle as teams and priorities multiply. The answer isn't automatically more hierarchy. Clear outcomes, decision rights and review rhythms can provide governance without adding approval layers.
If your operating procedures need documenting alongside roles and governance, this franchise operations manual guide may be useful. Keep the central question in view: does the model make it easier for people to understand priorities, own results and act when delivery falls behind?
I help leadership teams connect structure, governance and OKRs so strategy turns into delivery. If you're working through misalignment, unclear ownership or slow execution, book a conversation.