General Stanley McChrystal’s Team of Teams: What Hundreds of Successful Teams Taught Me About Scaling an Organization

One of the most important ideas in General Stanley McChrystal’s Team of Teams is also one of the most important lessons I have learned from working with hundreds of CEOs, founders, leadership teams, and growth companies over the past two decades:

A company does not scale simply by building more great teams. It scales when those teams learn how to operate together as one connected organization.

That distinction matters more than most leaders realize.

In a small company, the founder or CEO can often connect almost everything personally. They know what Sales is hearing from customers. They know what Product is planning. They understand what Engineering is building. They know the financial constraints, the board expectations, the recruiting priorities, and the biggest risks.

The organization may not have sophisticated systems, but it has something incredibly powerful: proximity.

People can talk directly. Context travels quickly. Decisions are made in the room. Misalignment can often be corrected with a conversation.

Then the company grows.

More people join. Functional teams form. Leadership layers appear. Specialists develop deeper expertise. The number of decisions increases. Dependencies multiply. Information becomes distributed throughout the organization.

What worked with 10 people starts to break with 30, 50, 100, or 500.

The challenge is no longer simply building a high-performing team.

The challenge is building a Team of Teams.

What General Stanley McChrystal Means by Team of Teams

General Stanley McChrystal developed the Team of Teams model while leading complex military organizations operating in environments where traditional command-and-control structures could not respond fast enough to rapidly changing conditions.

The core idea translates directly into business.

As organizations become more complex, leaders cannot assume that information and decisions should continue traveling up and down a hierarchy. Individual teams need enough context to understand the broader environment, enough trust to coordinate with other teams, and enough authority to act without waiting for every decision to reach the top.

The McChrystal Group’s Team of Teams framework describes four essential capabilities: Common Purpose, Trust, Shared Consciousness, and Empowered Execution.

Together, those capabilities create an organization that can combine something usually difficult to achieve simultaneously: the adaptability of a small team with the capabilities and resources of a much larger organization.

When I first began thinking deeply about these ideas, what struck me was how closely they mirrored patterns I had been observing for years.

I had arrived at the problem from a different direction.

I was spending my time inside companies.

I was sitting in leadership meetings. Coaching founders. Working with executive teams. Watching companies raise capital, grow, struggle, reorganize, acquire businesses, miss plans, recover, and sometimes exit.

I became obsessed with understanding why some teams consistently performed while others with equally talented people did not.

That work ultimately became the foundation of Peak OS and my book Peak Teams. The system grew out of more than two decades of working with hundreds of CEOs, founders, leadership teams, and investors.

Over time, another lesson became increasingly clear.

Building one great team was only the beginning.

Great Teams Can Still Produce a Poorly Performing Organization

This sounds contradictory until you see it happen.

A company can have an excellent Sales team.

It can have an excellent Engineering team.

Product can be filled with smart, capable people.

Marketing can execute exceptionally well.

Finance can be disciplined.

Customer Success can deeply understand customers.

And the company can still struggle.

Why?

Because local team performance and organizational performance are not the same thing.

Sales can exceed its targets while selling commitments Engineering cannot support.

Product can build a thoughtful roadmap without understanding what Sales is hearing from the market.

Engineering can become highly efficient at shipping work that is no longer the highest priority.

Marketing can optimize demand generation while Customer Success sees a customer problem that changes the ideal customer profile.

Finance can carefully protect runway while being disconnected from the capabilities other teams believe must be built.

Each team can be doing good work.

But if their understanding of the organization, their priorities, and their dependencies are disconnected, their collective effort can cancel itself out.

I have watched this happen repeatedly.

People are working hard.

Calendars are full.

Slack is busy.

Objectives exist.

Metrics exist.

Everyone can explain what their function is doing.

Yet when you ask a simple question—What is the company collectively trying to accomplish, and how does all this work fit together?—the answers begin to diverge.

That is when a team problem becomes a Team-of-Teams problem.

Scaling Changes the Unit of Performance

Early in a company’s life, the primary unit of performance is often the individual.

Then it becomes the team.

Eventually it becomes the relationship between teams.

That is a profound scaling transition.

The CEO may initially spend most of their energy asking:

Do I have the right people?

Is the leadership team strong?

Are the teams executing?

Those questions remain important.

But as complexity increases, another set of questions becomes equally important:

Do teams understand the same company priorities?

Can one team see when its work creates a dependency for another?

Does information move horizontally across the organization or primarily upward to leadership?

Can teams coordinate without requiring the CEO to broker every interaction?

Do people understand how their outcomes contribute to company outcomes?

Can teams make decisions while remaining aligned to the whole?

Does the organization learn across teams, or does every function learn independently?

These are organizational execution questions.

They cannot be solved simply by hiring more talented people.

They require an operating system that connects talented people.

Common Purpose: Everyone Has to Be Climbing the Same Mountain

The first connection between McChrystal’s Team of Teams model and what I have learned is Common Purpose.

The idea sounds simple.

Everyone should understand the mission.

Almost every CEO believes their organization does.

Then I walk into a room and ask people individually where the company is going.

The CEO gives one answer.

Sales gives another.

Product interprets the strategy differently.

Engineering has translated the strategy into its own priorities.

Marketing is focused on another set of outcomes.

The differences are rarely dramatic.

That is what makes them dangerous.

Small differences in interpretation compound through hundreds of daily decisions.

In Peak Teams, I describe alignment as agreement around the Why, Where, When, What, How, and Who of the organization. When those answers are shared, hundreds of micro-decisions can happen independently while still moving the organization in the same direction.

That is why Peak begins with shared direction.

Mission.

Core values and behaviors.

Three-Year Vision.

One-Year Plan.

Then company and team outcomes.

The documents themselves are not the objective.

The objective is to create a common understanding of where everyone is going and what success requires.

People cannot execute autonomously if they do not understand the larger mission their autonomy is supposed to serve.

Trust Has to Exist Between Teams, Not Only Inside Them

McChrystal’s framework also emphasizes trust.

Most discussions of trust focus on relationships inside one team.

That matters enormously.

But scale creates another requirement: inter-team trust.

Does Engineering trust Product?

Does Sales trust Marketing?

Does Customer Success believe Product will listen when customer patterns emerge?

Does Finance trust functional leaders to use resources responsibly?

Do teams believe commitments made by other teams will be honored?

Without that trust, organizations begin creating defensive behaviors.

Functions hold information.

Leaders create extra approval processes.

Teams build buffers into plans.

People escalate unnecessarily.

Meetings multiply because no one trusts that the work will happen without another check-in.

Eventually the CEO becomes the referee between functions.

In Peak, I describe Symbiosis as a condition of trust, respect, unity, and mutual dependence. Importantly, that does not apply only within one team. The same principle has to extend across the company as a team of teams.

Strong organizations do not eliminate functional boundaries.

They build trust across them.

Shared Consciousness: Teams Need to See Enough of the Whole

Another powerful McChrystal concept is Shared Consciousness.

This may be one of the most important organizational capabilities in a scaling company.

People cannot make strong decentralized decisions when they are operating from fragmented information.

Yet that is exactly what happens in many companies.

Sales knows something Product does not.

Customer Success identifies a pattern Marketing has not seen.

Finance understands a constraint Engineering does not know exists.

The CEO gradually becomes one of the only people who sees pieces of everything.

Then an organizational dependency forms around the CEO.

Every important issue eventually reaches the top because the CEO possesses the most complete context.

That model does not scale.

The alternative is not sharing everything with everyone.

The alternative is creating enough organizational visibility that people can understand the context surrounding their decisions.

Company outcomes should be visible.

Team outcomes should connect to them.

Critical metrics should be understood.

Cross-functional dependencies should be surfaced.

Risks should travel across organizational boundaries.

Decisions that affect multiple teams should become visible to those teams.

People need a common operating picture.

That shared context allows the organization to coordinate without requiring every conversation to pass through leadership.

Empowered Execution: Context Makes Autonomy Possible

The fourth capability in McChrystal’s framework is Empowered Execution.

This is another concept I have seen misunderstood repeatedly.

CEOs often tell me:

“I want my team to take more ownership.”

Then I look at how the organization works.

Roles are unclear.

Objectives are ambiguous.

Teams do not understand the broader strategy.

Decision rights are undefined.

Important information is hidden inside leadership conversations.

The CEO frequently overrides decisions.

And every significant action requires approval.

That organization does not have an empowerment problem.

It has a clarity and operating-system problem.

In Peak Teams, I describe empowerment as one of the behaviors that creates the most freedom for both the CEO and the team. When people understand their roles, responsibilities, objectives, and decision authority, they can make decisions and act without constantly seeking approval.

Autonomy cannot exist sustainably without context.

Give people authority without context and you create chaos.

Give people context without authority and you create frustration.

Great Team-of-Teams organizations create both.

The Founder Is Often the Organization’s First Operating System

This is where McChrystal’s work connects most directly to one of the recurring patterns I have observed in growth companies.

At first, the founder is the operating system.

They hold the vision.

They distribute context.

They resolve priorities.

They connect functions.

They make decisions.

They translate between teams.

They remember commitments.

They identify conflicts.

They know when something has changed.

And because everyone is relatively close to the founder, it works.

Until it doesn't.

I described this dynamic in Peak Teams as the CEO Stress Spiral. The CEO becomes the hub connecting the board, investors, clients, leadership team, and organization. Eventually everything feels like it is sitting on the CEO’s shoulders.

One of the most important realizations from my work is that CEOs do not necessarily need to execute all the details.

They need visibility into the details while trusting their teams to own execution.

That requires a fundamental transition:

Founder-connected execution must become system-connected execution.

The organization cannot depend forever on the CEO personally carrying context from one team to another.

Something else has to become the connective tissue.

That something is the operating system.

From Founder-Connected to System-Connected Execution

This transition changes the role of the CEO.

Instead of repeatedly telling people the direction, the organization maintains shared direction.

Instead of personally checking every initiative, the CEO has visibility into outcomes and metrics.

Instead of mediating every ownership conflict, roles and decision rights are clear.

Instead of calling another meeting every time teams need to coordinate, there is a dependable operating rhythm.

Instead of solving every cross-functional problem, teams have a mechanism for surfacing and resolving dependencies together.

Instead of being the source of organizational intelligence, the CEO helps build an organization that develops intelligence collectively.

The CEO remains essential.

But the CEO stops being the only thing holding the organization together.

That is one of the most important markers that a company is actually becoming scalable.

Peak OS Turns Team-of-Teams Principles Into Operating Habits

This is where Peak OS fits.

McChrystal offers a powerful model for how adaptive organizations should behave.

My work has focused heavily on the next question:

How do you make those behaviors repeatable inside a growing company?

Peak operationalizes common purpose through mission, values, long-term direction, annual planning, and connected company and team outcomes.

It strengthens trust through transparency, shared commitments, accountability, and collaborative problem-solving.

It creates shared consciousness through connected objectives, KPIs, organizational visibility, dependencies, risks, decisions, and regular cross-functional conversations.

It supports empowered execution through clear roles, ownership, expectations, and decision authority.

And it connects everything through operating rhythm.

Weekly.

Quarterly.

Annually.

That rhythm matters because organizations do not stay aligned because they created a great strategic plan once.

Trust does not stay strong because people attended an offsite.

Visibility does not happen because someone built a dashboard.

Empowerment does not persist because the CEO gave an inspiring speech about ownership.

The behaviors have to be practiced.

Again and again.

That is one of the central lessons behind Peak: habits build behaviors, and behaviors drive results.

Operating Rhythm Is the Connective Tissue Between Teams

A Team of Teams needs a way to repeatedly reconnect.

This is why operating rhythm becomes so important.

A strong weekly operating rhythm should not be a round-robin status meeting.

It should help create a shared operating picture.

What has changed?

Where are outcomes on course?

Where are they slipping?

What are the metrics telling us?

Which dependencies have emerged?

What information does another team need?

Which issues require cross-functional discussion?

What decision needs to be made?

Who owns the response?

What did we learn?

Then people return to their teams.

They do not need everyone involved in every decision.

They have enough shared context to execute their part of the system.

That is a fundamentally different kind of meeting from simply reporting what everyone did last week.

Its purpose is organizational synchronization.

Peak Does Not Make Every Team Operate Identically

This distinction is important.

A Team-of-Teams operating model does not mean every team should operate exactly the same way.

Sales should still be excellent at Sales.

Engineering should still operate like Engineering.

Product should retain its specialized methods.

Finance should maintain its discipline.

Customer Success should stay close to customers.

The objective is not uniformity.

It is connection.

The direction connects.

The outcomes connect.

The metrics connect.

Dependencies become visible.

Relevant information travels.

Decisions connect to strategy.

Learning travels across team boundaries.

Each team retains the autonomy that makes it effective while participating in a larger organizational system.

That is what I mean when I say:

Run the whole organization as one connected system.

The Real Scaling Constraint Is Often Between Teams

Many founders assume the next scaling problem will be headcount, capital, process, technology, or management depth.

Sometimes it is.

But I increasingly believe one of the biggest constraints appears in the spaces between teams.

The handoff between Marketing and Sales.

The dependency between Product and Engineering.

The feedback loop between Customer Success and Product.

The connection between Finance and every function making resource decisions.

The translation from leadership strategy into team outcomes.

The flow of information from the edge of the organization back into decision-making.

These connections determine whether the company behaves like one organization or a collection of functions.

When they are weak, the CEO fills the gaps.

When they are strong, the organization becomes capable of coordinating itself.

How Do You Know You Have a Team-of-Teams Problem?

The symptoms tend to appear before leaders recognize the underlying issue.

Individual teams appear busy while company priorities move slowly.

Functions report different definitions of success.

Teams repeatedly discover dependencies too late.

Decisions accumulate at the CEO or executive team.

Meetings multiply.

People complain that they do not know what other teams are doing.

Information travels upward and downward but rarely sideways.

Metrics are interpreted differently across functions.

One team changes direction without understanding the effect on another.

The CEO spends increasing amounts of time translating between teams.

Nothing may look catastrophically wrong.

But the organization feels harder to operate.

That feeling matters.

It often signals that the company has outgrown informal coordination and now needs an intentional organizational operating system.

What Hundreds of Teams Ultimately Taught Me

After hundreds of teams, the pattern has become difficult for me to ignore.

Talent matters.

Strategy matters.

Capital matters.

Technology matters.

But organizations ultimately execute through teams.

And as those organizations scale, performance depends increasingly on whether those teams function as an interconnected whole.

The strongest companies I have seen repeatedly demonstrate several characteristics.

They understand where they are going.

Teams understand how their outcomes connect to the larger mission.

Information travels across boundaries.

Dependencies become visible early.

People know what they own.

Leaders do not unnecessarily hold decisions at the top.

Teams have predictable ways to coordinate.

Problems create learning that moves through the organization.

Those are not isolated management practices.

Together they create an organizational capability.

McChrystal calls the model Team of Teams.

I have come to see it as one of the fundamental requirements of organizational execution.

The Organization Has to Become the Team

General Stanley McChrystal’s Team of Teams provides powerful language for a transition every successful growth company eventually has to make.

At first, you build a team.

Then you build teams.

Eventually, you have to build the connections between those teams.

That is where organizational scale actually happens.

The company moves from depending on direct founder coordination toward common direction.

From siloed knowledge toward shared context.

From centralized decisions toward distributed ownership.

From isolated functional execution toward organizational synchronization.

From a collection of teams toward a Team of Teams.

The strongest organizations are not simply composed of high-performing teams.

They are high-performing teams connected into a high-performing system.

That is one of the most important lessons I have taken from hundreds of teams.

And it is one of the central problems Peak OS was built to solve.

Related Insights

What Is Peak OS?

What Is Organizational Execution?

What Is Organizational Intelligence?

What Is a Business Operating System?

What Is Operating Rhythm?