In 2003, General Stanley McChrystal took command of the Joint Special Operations Command in Iraq and discovered that the most capable military force in history was losing to an enemy it should have destroyed in weeks. Al-Qaeda in Iraq was not better trained, better equipped, or better funded. It was faster. A decentralised network of semi-autonomous cells could observe a situation, decide on a response, and act before McChrystal's hierarchical command structure could process the intelligence, route it through approval chains, and issue orders. The problem was not competence. It was architecture. A hierarchy optimised for efficiency was being outrun by a network optimised for adaptability.
McChrystal's solution — documented in his 2015 book Team of Teams — was to transform his 7,000-person task force from a traditional command hierarchy into a network of small, autonomous teams connected by shared information and mutual trust. The unit of performance was still the small team. Special operations had always known that a tight-knit squad of twelve operators, bonded by shared purpose and extreme interdependence, could accomplish what a conventional battalion could not. The insight was that this team-level cohesion could be extended across teams — not by merging them into a single large unit (which would destroy the trust and speed that made small teams effective) but by connecting them into a network where every team understood the broader context well enough to act without waiting for orders from above.
McChrystal called the two enabling conditions "shared consciousness" and "empowered execution." Shared consciousness meant radical transparency: every piece of intelligence was shared across the entire task force through a daily Operations & Intelligence briefing that connected 7,000 people across multiple time zones. The briefing was not a status update. It was a mechanism for ensuring that every team had the context required to make autonomous decisions that aligned with the broader mission. Empowered execution meant pushing decision authority to the lowest competent level — letting the team on the ground act on the intelligence they received without routing every decision through the command chain. The combination produced a task force that could operate at the speed of a network while maintaining the coherence of a hierarchy.
The connecting tissue between teams was deliberately engineered. McChrystal embedded liaison officers — members of one team physically placed inside another — to create trust across team boundaries. The liaisons were not coordinators. They were trust bridges: people who understood both teams well enough to translate context, anticipate needs, and resolve conflicts before they escalated. The technique worked because trust, McChrystal observed, does not scale through hierarchy. It scales through relationships. A thousand people cannot all trust each other directly. But if each team trusts the liaison from the adjacent team, and each liaison trusts both their teams, the network achieves functional trust at a scale that no hierarchy can match.
The model translates to business with striking precision. Spotify's squad model — autonomous teams of six to twelve people, each responsible for a specific product area, connected through "chapters" (discipline-based guilds) and "tribes" (collections of related squads) — is a commercial implementation of the team-of-teams architecture. Amazon's two-pizza teams, mandated by Jeff Bezos, are autonomous units connected not through liaison officers but through well-defined APIs: each team owns a service, exposes an interface, and communicates with other teams only through that interface. The most radical implementation is Haier's "rendanheyi" model, created by CEO Zhang Ruimin: the Chinese appliance manufacturer reorganised its 80,000 employees into over 4,000 microenterprises, each operating as an autonomous business unit with its own P&L, connected to each other and to external partners through a platform that replaces hierarchy with market mechanisms.
What unites these implementations is the structural insight that sits at the core of McChrystal's framework: the optimal unit of execution is the small team, and the optimal architecture for connecting small teams is a network, not a hierarchy. Hierarchies excel at efficiency — routing predictable work through standardised processes. Networks excel at adaptability — responding to novel situations through distributed decision-making. In environments where the rate of change exceeds the hierarchy's processing speed — modern warfare, software development, consumer markets — the network wins. The team-of-teams model is how you build an organisation that captures the speed and trust of small teams at the scale of an enterprise.
Section 2
How to See It
The team-of-teams architecture reveals itself through speed of adaptation. Look for organisations where small, autonomous groups respond to local conditions without waiting for central approval — and where those responses are coherent with the broader strategy because of shared information, not shared commands. The tell is decision latency: how long does it take from the moment information is available to the moment someone acts on it?
Product & Engineering
You're seeing Team of Teams when a company's engineering squads ship independently — each team deploys its own service on its own schedule — yet the overall product feels coherent because every team has access to the same product strategy, the same customer data, and the same architectural principles. No central release committee. No cross-team approval chain. Coordination happens through shared context, not shared authority.
Startups & Growth-Stage Companies
You're seeing Team of Teams when a startup scales from thirty to three hundred people and the founder's reaction is not to add management layers but to split the company into small, autonomous pods — each with its own mission, its own metrics, and its own authority to ship — connected through weekly all-hands briefings that provide the shared consciousness McChrystal described.
Enterprise & Corporate
You're seeing Team of Teams when a large organisation dismantles its project management office and replaces it with autonomous teams that own outcomes rather than tasks. The former structure assigned work from above. The new structure provides context from the centre and lets teams decide how to execute. The shift is visible in meeting structure: fewer status updates, more information sharing.
Military & Government
You're seeing Team of Teams when a military unit's after-action reports show that frontline teams made decisions that would previously have required multiple levels of approval — and the decisions were better, not worse, because the teams had better local information than any central command could aggregate. Speed plus context beat authority plus distance.
Section 3
How to Use It
Decision filter
"When I see a decision bottleneck, I ask: is this slow because the people with the information lack the authority, or because the people with the authority lack the information? If the first, push authority down. If the second, push information up. The team-of-teams model solves both simultaneously."
As a founder
Design your organisation as a network from the start. The instinct at scale is to add hierarchy — a VP layer, a director layer, a team lead layer — each adding decision latency. The alternative: keep teams small (six to ten people), give each team a clear mission and the authority to execute it, and invest heavily in the information infrastructure that provides shared consciousness. The daily all-hands briefing, the internal dashboard, the shared Slack channel where every team posts what they learned today — these are not overhead. They are the connective tissue that makes autonomy coherent.
Amazon's API mandate is the engineering expression of this principle: every team must communicate through well-defined interfaces, which means every team can change its internal implementation without breaking others. The organisational equivalent is giving each team a clear contract — here is your mission, here are your metrics, here are the interfaces you maintain with other teams — and then getting out of the way.
As an investor
Evaluate the company's decision architecture, not just its org chart. A flat org chart with centralised decision-making is a hierarchy with fewer titles. A hierarchical org chart where frontline teams have genuine autonomy is a team-of-teams in disguise. The diagnostic: pick a recent product decision and trace the path from initial information to final action. How many people touched the decision? How long did it take? In a well-functioning team of teams, the answer is one team and days. In a disguised hierarchy, the answer is five approval layers and months.
The companies that scale fastest are almost always team-of-teams architectures — Shopify's pods, Stripe's small teams, Amazon's two-pizza units. The common feature is not flatness but autonomy: each unit has the information, the authority, and the capability to act without waiting. Hierarchies that require central approval for every decision have a throughput ceiling that team-of-teams architectures do not.
As a decision-maker
The hardest part of implementing a team-of-teams model is surrendering control without surrendering coherence. McChrystal described his role shift as moving from "chess master" — directing every piece on the board — to "gardener" — creating the conditions for autonomous teams to thrive. The chess master makes better individual moves. The gardener builds a system that makes better collective moves faster than any chess master can process.
The implementation requires investment in two specific systems: an information system that provides shared consciousness (every team sees the same data, the same strategy, the same context) and a trust system that enables empowered execution (leaders who trust teams to act, teams who trust each other's judgment, and a culture that treats mistakes from empowered action more favourably than failures from excessive caution).
Common misapplication: Removing hierarchy without building the information infrastructure that replaces it. McChrystal did not eliminate the chain of command. He supplemented it with a radical transparency mechanism — the daily O&I briefing — that gave every team the context previously held only by senior leaders. Companies that flatten their org chart without investing in shared consciousness get the worst of both worlds: no one has the authority to decide, and no one has the information to decide well.
Second misapplication: Treating "team of teams" as an excuse for under-management. Autonomous teams still need clear missions, well-defined interfaces, and leaders who provide strategic context. The team-of-teams model does not eliminate leadership. It changes its function — from directing execution to enabling it. A leader who interprets "empowered execution" as "I don't need to manage" will produce autonomous teams that are fast, confident, and misaligned.
Section 4
The Mechanism
Section 5
Founders & Leaders in Action
The team-of-teams model is most visible in large organisations that have maintained startup-like speed despite scale — companies where hundreds or thousands of people operate with the agility that conventional wisdom says only small teams can achieve. The two cases below show different implementations of the same architecture: small, autonomous teams connected through shared information and well-defined interfaces rather than through hierarchical command.
Bezos institutionalised the team-of-teams model before McChrystal named it. The two-pizza team rule — no team should be larger than can be fed by two pizzas — was the structural foundation. But the rule was never about pizza. It was about cognitive load and decision speed. A team of six to ten people can maintain the mutual trust and shared context required for autonomous action. A team of fifty cannot. Bezos enforced small teams not as a cultural preference but as an architectural principle: each team owns a service, defines its API, and communicates with other teams only through that interface.
The 2002 API mandate — every team must expose its data and functionality through service interfaces, no exceptions — was the shared consciousness mechanism. Instead of liaison officers, Amazon used software interfaces to create the connective tissue between autonomous teams. The result was an organisation of thousands of small, independent teams that could build, deploy, and iterate without coordinating through a central authority. AWS itself emerged from this architecture: the internal infrastructure team built tools for other Amazon teams, realised the tools had external value, and shipped them as a product — a decision an autonomous team could make because it had both the authority and the information to act.
When Nadella took over Microsoft in 2014, the company was the textbook example of what the team-of-teams model replaces: a rigid hierarchy where divisions operated as warring fiefdoms, each optimising for its own P&L at the expense of the whole. The Windows division vetoed products that threatened its dominance. Office and Azure operated as separate empires. Information did not flow across divisions because sharing information meant sharing power, and power was the currency of Microsoft's internal political economy.
Nadella's transformation was structural, not motivational. He dismantled the stack-ranking system that pitted employees against each other within teams. He reorganised the company around customer scenarios rather than product lines — breaking the divisional silos that had prevented cross-team collaboration for decades. He invested in shared platforms (Azure, Microsoft Graph) that created the equivalent of McChrystal's shared consciousness: common data and infrastructure that every team could access, reducing the information asymmetry that had powered the fiefdom structure. The cultural shift from "know-it-all" to "learn-it-all" was the trust mechanism — a signal that collaboration was valued over competition. Microsoft's market capitalisation went from roughly $300 billion when Nadella took over to over $3 trillion a decade later. The turnaround was not a product story. It was an organisational architecture story — a hierarchy of competing fiefdoms transformed into a network of connected teams.
Section 6
Visual Explanation
Section 7
Connected Models
The team-of-teams model sits at the intersection of organisational design, systems theory, and military strategy. Its connections reveal the forces that make hierarchies fail, the mechanisms that make networks succeed, and the boundary conditions that determine when each architecture is appropriate.
Reinforces
Decentralisation
Decentralisation is the structural principle; team of teams is the operational architecture that makes decentralisation work at scale. Pure decentralisation — autonomous units with no connecting fabric — produces chaos. The team-of-teams model solves the coordination problem that pure decentralisation creates: shared consciousness provides the alignment that hierarchy previously enforced, while empowered execution preserves the speed that decentralisation promises. McChrystal's contribution was proving that decentralisation does not require sacrificing coherence — it requires investing in the information infrastructure that replaces hierarchical coordination.
Tension
Span of Control
Span of control — the number of direct reports a manager can effectively oversee — is the constraint that hierarchies are designed to manage. The team-of-teams model sidesteps the constraint entirely. Instead of widening or narrowing spans of control, it replaces the control mechanism: teams are not "controlled" by managers above them but connected to peers beside them through shared information and trust. The tension is practical: organisations transitioning from hierarchy to network must decide which coordination mechanisms to replace and which to retain. Eliminating span-of-control structures without building network alternatives produces a power vacuum, not empowerment.
Reinforces
Conway's Law
Conway's Law states that organisations design systems that mirror their communication structures. The team-of-teams model leverages this deliberately: if you want a modular, loosely coupled system, build a modular, loosely coupled organisation. Amazon's API mandate is Conway's Law applied intentionally — each two-pizza team builds a service that mirrors its own autonomy, producing an architecture where services communicate through well-defined interfaces just as the teams that build them do. The reinforcement is bidirectional: the organisational structure shapes the system architecture, and the system architecture reinforces the organisational structure.
Section 8
One Key Quote
"We want to be a large company that's also an invention machine. We want to combine the extraordinary customer-serving capabilities that are enabled by size with the speed of movement, nimbleness, and risk-acceptance mentality normally associated with entrepreneurial start-ups."
— Jeff Bezos, 2015 Letter to Amazon Shareholders
Bezos was describing the fundamental tension that the team-of-teams model resolves: scale gives you resources, reach, and resilience, but it also gives you hierarchy, bureaucracy, and decision latency. The conventional wisdom says you must choose — either be large and slow or small and fast. The team-of-teams architecture refuses the trade-off. Amazon at 1.5 million employees operates thousands of two-pizza teams, each with the autonomy to invent, experiment, and ship as if it were a startup — connected to the broader organisation through APIs, shared infrastructure, and common leadership principles rather than through hierarchical command chains.
The result is an organisation that invents at startup speed while deploying at enterprise scale. AWS, Alexa, Prime, Kindle, advertising — each emerged from a small, autonomous team that had the authority to act on an insight without routing it through a corporate approval process. The two-pizza team is not a management gimmick. It is the structural mechanism that makes it possible to be large and fast simultaneously — McChrystal's team of teams applied to commerce rather than combat.
Section 9
Analyst's Take
Faster Than Normal — Editorial View
The team-of-teams model is the most important organisational insight of the last two decades, and the most frequently botched in implementation. McChrystal's framework is elegant: small autonomous teams, shared consciousness, empowered execution. The implementation is hard because it requires leaders to do the one thing most leaders are constitutionally unable to do — give up control.
The failure mode I see most often: leaders who adopt the vocabulary without the architecture. They call their teams "squads." They reference McChrystal in all-hands meetings. They put "empowered execution" on the values slide. Then they require every decision above a trivial threshold to be approved by someone three levels up. The structure says "network." The behaviour says "hierarchy." The employees notice the gap immediately.
The two enabling conditions are not optional, and they are not symmetric. Shared consciousness without empowered execution produces informed powerlessness — everyone knows what's happening, no one can do anything about it. Empowered execution without shared consciousness produces confident chaos — everyone acts decisively, in incompatible directions. You need both. McChrystal invested as heavily in the daily O&I briefing (shared consciousness) as he did in pushing decision authority to the frontline (empowered execution). Most companies invest in neither — or, worse, invest in one while neglecting the other.
Amazon is the cleanest commercial implementation. The two-pizza team structure creates autonomous units. The API mandate creates the connective tissue. The leadership principles create the shared mental model. Each mechanism addresses a specific requirement of the team-of-teams architecture: small teams for trust and speed, interfaces for coordination without hierarchy, and principles for alignment without control. The architecture is why Amazon can operate in cloud computing, e-commerce, logistics, entertainment, advertising, and hardware simultaneously — each domain run by autonomous teams connected through infrastructure rather than management.
Spotify's squad model is the most studied and the most misunderstood. Companies copy the structure — squads, tribes, chapters, guilds — without copying the enabling conditions. Spotify invested years in building the trust, the tooling, and the cultural norms that made autonomous squads effective. Companies that adopt the squad label after a two-day offsite get the overhead of reorganisation without the benefit of autonomy. The structure is the least important part of the model. The information infrastructure and the trust culture are everything.
Section 10
Test Yourself
The team-of-teams label gets applied to any organisation with small teams — regardless of whether those teams are genuinely autonomous, genuinely connected, or genuinely faster than a traditional hierarchy. The scenarios below test whether you can distinguish the real architecture from the cosmetic relabelling.
Is Team of Teams the right diagnosis here?
Scenario 1
A 500-person software company reorganises into 'autonomous squads' of eight people each. Each squad has a product owner, a designer, and engineers. Six months later, a survey reveals that 80% of squads still escalate every non-trivial decision to their VP for approval. The VPs meet weekly to 'align priorities.' Product changes that used to take two weeks now take six because the squad makes a recommendation, the VP reviews it, the VP committee discusses it, and the VP sends it back with modifications.
Scenario 2
A logistics company operates 200 warehouse teams across 15 countries. Each team manages its own inventory, staffing, and local supplier relationships. A central operations dashboard — updated in real time — shows every team's performance, inventory levels, and customer satisfaction scores. When a supply chain disruption hits Southeast Asia, three local teams independently reroute their sourcing within 48 hours. The central team learns about the rerouting from the dashboard, not from an approval request.
Scenario 3
A startup founder reads McChrystal's book and eliminates all management layers. The company goes from a three-tier hierarchy (founder, team leads, engineers) to a flat structure with no managers. Six months later, projects are routinely delayed because no one knows who is working on what. Engineers duplicate each other's work. Two teams independently build competing solutions to the same problem. The founder says the teams need 'more time to adapt to autonomy.'
Section 11
Top Resources
The literature on the team-of-teams model spans military strategy, organisational theory, and technology management. McChrystal's book is the canonical source, but the underlying principles — network structure, autonomous teams, shared information systems — have been developed independently by practitioners in software, manufacturing, and management science. The resources below progress from the original military framework through the business implementations to the organisational science that explains why the model works.
The canonical source. McChrystal describes the transformation of JSOC from a hierarchical command into a network of autonomous teams — and extracts the principles (shared consciousness, empowered execution, trust through liaison) that translate to any organisation operating in a fast-changing, complex environment. The treatment of why hierarchies fail in complex environments is the strongest available argument for network architectures.
The most detailed inside account of Amazon's organisational architecture — two-pizza teams, the API mandate, single-threaded leadership, and the mechanisms that connect autonomous units into a coherent operation. The book provides the implementation detail that McChrystal's framework outlines in principle: how do you actually build and maintain a team-of-teams architecture at a company with over a million employees?
Coyle examines how high-performing teams build the trust, shared purpose, and psychological safety that the team-of-teams model requires at the individual team level. The research spans Navy SEALs, Pixar, the San Antonio Spurs, and IDEO — groups where small-team cohesion produces results that scale through the team-of-teams mechanism. Essential reading on the team-level foundations that the network-level architecture depends on.
Edmondson introduces "teaming" as a verb — the dynamic process of collaborating across shifting team boundaries — which is the operational reality inside a team-of-teams architecture. Her research on psychological safety provides the empirical foundation for McChrystal's claim that trust is the connective tissue between autonomous teams. The book is the strongest academic complement to McChrystal's practitioner account.
Marquet's account of transforming the USS Santa Fe from the worst-performing submarine in the US Navy to the best by replacing the leader-follower model with a leader-leader model. His "intent-based leadership" framework — where subordinates state their intent and leaders confirm rather than direct — is an independent implementation of McChrystal's empowered execution principle. The book provides the clearest operational playbook for pushing decision authority to the frontline without losing alignment.
Team of Teams — Traditional hierarchies route decisions through a central node, creating bottlenecks. The team-of-teams model connects autonomous units through shared consciousness and trust, enabling the speed of small teams at the scale of a large organisation.
Reinforces
Network Effects
Network effects in a team-of-teams architecture are internal rather than external. Each new team added to the network increases the total information and capability available to every other team — provided the shared consciousness infrastructure can scale. The value of the network grows non-linearly with the number of connected teams, just as the value of a telephone network grows non-linearly with the number of subscribers. The reinforcement has a limit: beyond a certain network size, information overload replaces information advantage. McChrystal's daily O&I briefing worked at 7,000 people. Whether it would work at 70,000 is an open question.
Reinforces
[OODA Loop](/mental-models/ooda-loop)
John Boyd's OODA loop — Observe, Orient, Decide, Act — is the competitive tempo framework that explains why team-of-teams architectures win. A hierarchy's OODA loop runs at the speed of its slowest approval chain. A team-of-teams architecture runs at the speed of its fastest autonomous unit. McChrystal's task force in Iraq reduced its OODA cycle from days to hours — not by making the hierarchy faster but by replacing hierarchical decision-making with networked autonomous action. The team on the ground observed, oriented, decided, and acted before the enemy's network could complete the same cycle.
Tension
Organisational Debt
The team-of-teams model can prevent organisational debt or accelerate it, depending on implementation quality. A well-functioning network of autonomous teams restructures continuously — each team adapts its internal processes as conditions change, preventing the structural calcification that generates organisational debt. A poorly implemented network — autonomous teams with no shared consciousness — accumulates a different kind of debt: divergent processes, incompatible systems, and cultural fragmentation that becomes harder to reconcile over time. The tension: team-of-teams architectures require more deliberate maintenance of the connective tissue (shared platforms, liaison relationships, common standards) than hierarchies do, because the connective tissue is not enforced by authority but sustained by investment.
The honest risk: the team-of-teams model is fragile in the wrong hands. It requires leaders who are secure enough to surrender control, teams that are capable enough to handle autonomy, and information systems that are robust enough to maintain shared consciousness at scale. When any of these conditions fails, the model degrades — into chaos (no shared consciousness), paralysis (no empowered execution), or the very hierarchy it was designed to replace (leaders who recentralise authority when autonomous teams make mistakes).
For founders scaling past fifty people: the choice between hierarchy and network is the most consequential architectural decision you will make. A hierarchy is easier to build and easier to manage. A network is harder to build and harder to maintain — but it scales speed in ways that hierarchies cannot. If your market changes faster than a hierarchy can process, the hierarchy will kill you. If your market is stable enough for hierarchical coordination to work, the network adds unnecessary complexity. Know your environment. Choose your architecture accordingly.
