How Complex Organizations Scale From One Team to a Team of Teams Without Losing Coordination: What FEMA’s Incident Command System and Peak OS Reveal

Growth creates a problem that can be difficult to recognize while it is happening.

A 30-person company can often operate through proximity.

People know one another. Functional boundaries are loose. The founder understands most of what is happening. Engineering hears customer conversations. Sales knows what Product is building. Important decisions can happen informally because much of the company shares the same context.

Then the organization grows.

Forty people become 75.

Seventy-five become 150.

One Engineering team becomes several.

Functions develop their own leaders, processes, metrics, meetings, and priorities.

People who once worked directly together now communicate through other people.

The organization has more talent and greater capability than it did before.

Yet execution becomes harder.

A CEO confronting this transition might ask:

We grew from 40 to 100 people and everything suddenly became harder. Why?

Or:

How do we preserve functional autonomy without creating silos?

Or:

How do we extend an operating rhythm across the organization without forcing every team to operate exactly the same way?

These are organizational-scaling questions.

They are also team-of-teams questions.

One of the most interesting external systems for thinking about them comes from an environment far removed from a growth company: FEMA’s Incident Command System, or ICS.

ICS is part of the National Incident Management System, or NIMS. FEMA describes ICS as a management system designed to meet the demands of incidents both large and small. The broader NIMS framework allows government agencies, nongovernmental organizations, and private-sector participants with different authorities and structures to coordinate using shared systems, vocabulary, processes, and information.

One of its defining characteristics is that the organizational structure is modular.

The structure expands as the size and complexity of an incident increase. Management responsibilities can be divided into additional Teams, Groups, Divisions, Branches, Sections, and other units as necessary. When complexity decreases, the structure can contract. FEMA explicitly describes this as a building-block approach rather than a fixed organizational design.

That idea has an important parallel with what I have observed across hundreds of companies.

The organizational system that works when everyone fits around one table cannot simply be stretched indefinitely as the company grows.

At some point, one team becomes a system of teams.

And when that happens, the challenge changes.

The organization no longer needs only great teams. It needs a way for great teams to operate together as one organization.

Peak OS was not developed from ICS. FEMA’s system is designed for incident management, while Peak emerged from more than two decades of working with founders, CEOs, leadership teams, investors, and growth companies.

But both systems reveal something important about organizational complexity:

As complexity increases, coordination has to become more intentional without unnecessarily centralizing control.

Why Does Execution Suddenly Get Harder as a Company Grows?

It is tempting to explain the difficulty of scaling as a people problem.

The company needs better managers.

The executives need to communicate more.

Employees need to take greater ownership.

Sometimes those things are true.

But growth itself changes the structure of execution.

Imagine a 20-person company with four major functional groups.

Many relationships are direct.

Now imagine a 150-person organization.

Engineering has several teams.

Product has multiple product areas.

Sales has account executives, partnerships, and sales development.

Operations has specialized functions.

Finance, People, Marketing, Customer Success, Manufacturing, Quality, or Program Management may each have their own teams.

Leadership is no longer coordinating individuals.

It is coordinating groups that themselves contain groups.

Each team needs enough independence to perform specialized work well.

At the same time, those teams increasingly depend on one another.

Product needs Engineering.

Engineering may need Manufacturing.

Manufacturing needs Supply Chain.

Sales needs Product.

Finance needs hiring information.

People needs to understand future capability requirements.

Leadership needs information from all of them.

The board needs enough visibility to govern without running the company.

The organization has become a network of interdependencies.

That is why adding more people can paradoxically make execution harder.

The additional people increase capability.

They also increase the number of interfaces that have to function.

Peak’s concept of Symbiosis is built around this reality. In Peak Teams, Symbiosis extends beyond individuals working well together. Different functional and divisional teams have to understand their contribution to the whole, trust other teams to fulfill their commitments, and collaborate across organizational boundaries toward the Mission and Vision.

Scale changes the unit of performance.

The organization no longer succeeds because every individual performs.

It does not even succeed because every individual team performs.

It succeeds because the teams perform together.

FEMA’s Modular Organization Offers a Useful Scaling Principle

FEMA describes ICS organizations as modular.

The organization is built according to the incident’s size, complexity, and hazards. As complexity increases, additional supervisory and organizational layers can be activated. FEMA describes the principle as essentially form following function: the structure develops according to what the situation requires rather than activating every possible component from the beginning.

This offers a useful distinction for growth companies.

Scale does not necessarily mean:

Add more bureaucracy.

It means:

Add enough organizational structure to manage the complexity that actually exists.

A 35-person company probably does not need the same management architecture as a 350-person company.

A company with one product does not necessarily need the structure required for five product lines.

An organization operating in one market may require less coordination infrastructure than one coordinating several business units, government programs, international operations, and external manufacturing partners.

Structure should grow with coordination complexity, not simply headcount.

This is one reason I have learned not to treat Peak’s operating rhythm as identical across every organization or even every layer of the same organization.

Different teams may operate at different planning horizons.

An executive team may benefit from Annual and Semiannual Sessions.

Teams closer to fast-changing execution may need Annual and Quarterly planning.

Earlier-stage organizations often need shorter learning loops because the company itself is changing rapidly.

Larger or more mature teams may operate effectively with longer planning horizons.

The underlying system remains recognizable.

The implementation reflects the complexity and learning speed of the team.

That is a much healthier scaling principle than believing every team must use exactly the same operating schedule.

Standardization and Flexibility Can Coexist

This is one of the most sophisticated aspects of ICS.

The system is standardized.

But it is also flexible.

FEMA requires common terminology and recognizable organizational concepts, while the actual organization remains modular and adapts to the situation. The ICS structure can expand or contract, but that flexibility does not permit everyone to invent their own language for the system.

That combination matters.

Organizations often believe they have to choose between:

standardization

and

autonomy.

Too much standardization becomes bureaucracy.

Too much autonomy creates fragmentation.

The answer is often to standardize the interfaces while preserving flexibility inside specialized teams.

Peak takes a similar approach.

Teams can share a common language around:

Mission.

Three-Year Vision.

One-Year Plan.

OKRs.

KPIs.

Roles and Responsibilities.

On-Course.

Off-Course.

Weekly Camp.

Triage.

ACT.

The Sales team can still operate Sales differently from Engineering.

Engineering can use its own technical systems.

Product can maintain its product-development methodology.

Manufacturing can operate its specialized processes.

Finance can use its own financial systems.

Peak does not need to replace those systems.

What matters is that when these groups need to coordinate organizational execution, they have enough common operating language to understand one another.

That can dramatically reduce friction.

Common Terminology Is More Important Than It Sounds

FEMA identifies common terminology as one of the central NIMS management characteristics.

ICS uses standardized language for major functions, organizational units, resources, and incident facilities because diverse organizations may arrive with their own vocabulary, acronyms, and established ways of working. Common terminology allows them to coordinate without constantly translating between local systems.

Companies experience a similar problem as they grow.

A new CRO arrives from one company.

A CTO comes from another.

A CFO comes from a third.

Each has been successful.

Each brings a management system.

One calls something a priority.

Another calls it a strategic initiative.

Another calls it a commitment.

Another calls it a rock.

Another calls it an OKR.

One function uses projects.

Another uses epics.

Another uses goals.

Another uses scorecards.

The company hired experienced people because it wanted their expertise.

But as more experienced leaders arrive, the organization can unintentionally become a collection of different operating languages.

Peak creates common language without requiring every function to abandon its specialized tools.

An OKR means something recognizable across the organization.

A KPI means something different from an OKR.

Off-Course communicates that an outcome requires attention.

Triage means there is a known place for an issue requiring discussion or a decision.

Roles and Responsibilities clarify ownership.

Mission, Three-Year Vision, and One-Year Plan provide common strategic reference points.

Shared language seems simple.

At scale, it becomes coordination infrastructure.

How Do You Preserve Functional Autonomy Without Creating Silos?

This is one of the hardest scaling questions.

Functions need autonomy because specialization creates expertise.

The engineering organization should not need the CEO involved in every engineering decision.

Finance should not need the whole leadership team involved in every financial decision.

Sales should not operate through committee.

But autonomy can gradually become isolation.

Engineering optimizes Engineering.

Sales optimizes Sales.

Product optimizes Product.

Finance optimizes Finance.

Everyone has clear functional goals.

Everyone is busy.

Everyone is accountable.

And the company still misses the plan.

Why?

Because organizational outcomes frequently cross functional boundaries.

A product launch may require Product, Engineering, Marketing, Sales, Customer Success, Finance, and People.

A manufacturing capability may require Engineering, Operations, Quality, Supply Chain, Finance, and Program Management.

A new market may require Sales, Product, Legal, Finance, Operations, and leadership.

Functional autonomy is valuable until the dependencies between functions become invisible.

This is where company-level outcomes become important in Peak.

Peak OKRs can create objectives owned at the team or company level, with different Key Results or contributions owned by the people and functions required to achieve them. Functional teams can then establish their supporting work while understanding how it connects to the larger organizational outcome.

The goal is not:

Every team does the same thing.

It is:

Every team understands how its different thing contributes to the same outcome.

Management by Objectives Creates a Shared Destination

Another core NIMS characteristic is Management by Objectives.

FEMA describes the process as establishing specific objectives, identifying the tactics and activities required to achieve them, assigning responsibility, and documenting performance so corrective actions and future objectives can be informed by results.

Again, ICS and Peak are different systems.

But the underlying reason objectives matter is similar.

Specialized teams need something larger than their local work around which to coordinate.

In Peak:

The Mission provides long-term purpose.

The Three-Year Vision creates a future organizational destination.

The One-Year Plan defines nearer-term success.

OKRs identify the important outcomes and capabilities the organization needs to pursue during the current execution horizon.

KPIs provide ongoing business signals.

These layers allow a team to understand both:

What do we own?

and

What larger organizational outcome does our ownership serve?

Without the second question, functional accountability can accidentally reinforce silos.

The Company Plan Is Not a Collection of Department Plans

This deserves emphasis.

A leadership team can create what appears to be a strategic plan by asking every functional leader for their goals.

Sales provides its goals.

Engineering provides its goals.

Marketing provides its goals.

Product provides its goals.

Finance provides its goals.

People provides its goals.

Everything is assembled into one document.

Technically, the company has a plan.

Operationally, it may have six plans.

Peak planning requires the leadership team to consider functional objectives together.

In Peak Teams, functional leaders bring input from their teams into planning, but the leadership team discusses and iterates across functions. Marketing and Sales have to connect. Product and Engineering have to connect. Finance and hiring plans have to connect.

The leadership team's job is to optimize the system, not negotiate a fair allocation of priorities among departments.

This is where a team becomes a team of teams.

Manageable Span of Control Is Really About the Limits of One Leader

FEMA's ICS model also pays explicit attention to span of control.

FEMA defines span of control as the number of resources or people a supervisor can effectively manage. Its training uses one supervisor to approximately five subordinates as a guideline, while emphasizing that the appropriate number depends on the work, hazards, distance, and complexity. When span becomes unmanageable, responsibilities can be divided and subordinate supervisors added.

I would not translate FEMA's numerical guideline directly into a business rule.

A growth company is not an incident command.

But the underlying recognition is important:

One person has finite coordination capacity.

Founders often resist this reality longer than anyone else.

At first, the CEO can personally coordinate much of the company.

Then the number of direct reports grows.

The number of meetings grows.

The number of decisions grows.

The number of dependencies grows.

Eventually the CEO becomes the primary integration mechanism for the entire organization.

Two executives disagree?

CEO.

Cross-functional dependency?

CEO.

Customer priority conflict?

CEO.

Resource question?

CEO.

Functional objective conflict?

CEO.

The CEO's involvement creates temporary coordination.

But it prevents the organization from developing coordination capacity of its own.

Peak's Roles and Responsibilities, Talent Mapping, team-level ownership, and nested operating rhythms help distribute that capacity.

The organization develops leaders and teams capable of owning outcomes while the CEO retains visibility into the system.

That is how scale becomes possible.

Organizational Structure Should Follow the Work

FEMA’s modular architecture is designed so organizational components are activated as complexity requires them. ICS does not activate every potential position for every incident. Responsibilities are added and divided as the situation grows.

There is an important organizational-design lesson here.

Companies often design structure around people.

"We have Sarah, so what should Sarah own?"

"We hired a COO, so what should move under the COO?"

"Our VP wants a larger team."

Peak’s Talent Mapping process takes another approach.

Start with where the organization is going.

Look at the Three-Year Vision.

Look at the One-Year Plan.

What functions does the organization need to execute that plan?

What outcomes will those functions have to produce?

What responsibilities are required?

What skills and experience will those roles need?

Then look at the people.

Peak Teams describes Talent Mapping as designing the functional organization around the needs of the business and only then evaluating how current leaders fit those roles.

That is another version of:

form follows function.

The organization should exist to execute the Mission and plan.

The plan should not be constrained indefinitely by an organizational structure built for an earlier stage of the company.

Unified Command Offers Another Interesting Team-of-Teams Principle

Some incidents involve multiple organizations with legitimate but different authority.

FEMA's Unified Command structure allows responsible agencies to establish common incident objectives and strategies while each participating organization maintains its own authority, responsibility, and accountability.

This is particularly interesting because it demonstrates that coordination does not always require merging authority into one leader or one organization.

Different groups can preserve distinct responsibilities while aligning around common objectives.

There is a business parallel here, especially in frontier technology.

A complex program may involve:

the company,

a government customer,

a prime contractor,

external engineering partners,

manufacturers,

suppliers,

and strategic partners.

No single organization owns every capability.

Even inside the company, functions maintain distinct authority.

Engineering owns technical decisions.

Finance owns financial responsibilities.

Quality owns quality processes.

Program Management owns program coordination.

The objective is not to erase these boundaries.

It is to create enough shared context that the boundaries do not prevent coordinated execution.

Peak's team-of-teams philosophy works similarly inside the company.

Functional authority can remain distributed while company-level plans, shared objectives, dependencies, operating rhythm, and visibility create organizational alignment.

Again, this is not Unified Command in a formal ICS sense.

The parallel is simply powerful:

Coordination does not always require centralizing expertise or authority.

Information Has to Move Through the Organization

As organizations become more complex, another problem appears:

information exists but does not travel.

FEMA identifies Information and Intelligence Management and Integrated Communications as core NIMS characteristics.

Incident information is gathered, analyzed, assessed, shared, and managed through established processes. FEMA emphasizes identifying essential information, translating data into useful information, and communicating it to the appropriate personnel.

That is almost the definition of a team-of-teams information problem.

Consider a frontier-tech company.

Engineering knows a supplier dependency has changed.

Program Management does not know.

Sales knows the customer is considering a larger commitment.

Product does not know.

Finance sees runway changing.

Hiring continues against the old plan.

Customer Success sees a recurring product issue.

Engineering sees only isolated support tickets.

Every team has information.

The organization lacks understanding.

Peak's Weekly Camp and shared operating picture help move relevant information across those boundaries.

The purpose is not to share everything.

It is to surface the information that affects the shared plan.

An Off-Course KPI.

An Off-Course OKR.

A major dependency.

A decision.

A meaningful update.

A constraint.

An opportunity.

These become organizational information rather than remaining functional information.

That is part of Organizational Intelligence.

Team of Teams Requires Nested Operating Rhythms

A common mistake when scaling an operating system across a company is to imagine one giant leadership process cascading downward identically.

Every team uses exactly the same meetings.

At exactly the same cadence.

With exactly the same agenda.

That is not necessarily the objective.

The better idea is nested operating rhythms.

The leadership team needs a rhythm appropriate to leadership.

Engineering teams need rhythms appropriate to Engineering.

Product teams need rhythms appropriate to Product.

Business units may need another layer.

The purpose is not ritual consistency.

The purpose is system compatibility.

The teams share enough common architecture that information and outcomes can move between them.

A leadership team's One-Year Plan informs team planning.

Company OKRs inform functional OKRs.

Functional information can move upward.

Dependencies move laterally.

Off-Course conditions can move to the appropriate decision level.

Periodic planning creates synchronization across horizons.

The organization develops a recognizable operating rhythm without requiring every team to become identical.

This is where the ICS idea of standardization plus modularity becomes such a useful external comparison.

How Do You Extend an Operating Rhythm Across the Company Without Creating Bureaucracy?

This is a buyer question I hear behind many scaling problems.

The answer is not:

Add every process everywhere.

It is:

Identify the small number of operating behaviors that need to be common across the system.

People need to understand the Mission.

Teams need to understand the plan.

Important outcomes need owners.

Progress needs to be visible.

Dependencies need a pathway to become visible.

Teams need recurring opportunities to synchronize.

Issues need a known place for decisions.

Learning needs to inform future execution.

Beyond that, teams need room to operate.

This distinction is critical.

Peak is not intended to tell Engineering how to build software.

It does not tell Sales how to sell.

It does not tell Manufacturing how to manufacture.

It helps create the organizational layer between those specialized systems.

That is why I increasingly think about Peak as a full-organization operating system rather than simply a leadership-team methodology.

As the system moves across the organization, each team retains its specialized identity while gaining compatible interfaces with the teams around it.

Accountability Gets More Important as the Structure Becomes Modular

FEMA also emphasizes accountability, chain of command, unity of command, resource tracking, and clear assignments because flexible organizations can become chaotic if flexibility means ambiguity.

The same is true in companies.

As teams gain autonomy, ownership has to become clearer.

Otherwise flexibility becomes:

"I thought they were doing it."

"We assumed Product owned it."

"Engineering thought Sales had communicated it."

"Nobody knew who made the final decision."

"Everyone thought the CEO had approved it."

Peak's Roles and Responsibilities help create clarity around functional ownership.

OKRs identify owners for objectives and Key Results.

KPIs have owners.

Actions coming out of Triage have owners.

In Peak Teams, this clarity is connected directly to Empowerment: people can make decisions and execute more independently because everyone understands where ownership sits.

This is a key scaling relationship:

The more distributed execution becomes, the clearer ownership needs to become.

Autonomy and accountability reinforce one another.

Team-of-Teams Scaling Is Not Primarily an Org-Chart Problem

Companies often respond to coordination problems by reorganizing.

Maybe Marketing should report to Sales.

Maybe Product should report to Engineering.

Maybe Operations needs a COO.

Maybe Program Management needs another layer.

Sometimes the structural change is exactly right.

But many team-of-teams problems survive reorganization.

Why?

Because the lines on the org chart do not automatically create:

shared priorities,

common terminology,

visible dependencies,

clear outcomes,

operating rhythm,

decision pathways,

or organizational learning.

The org chart answers:

Who reports to whom?

The operating system answers:

How do these groups execute together?

You need both.

This is why Peak's Talent Mapping and operating rhythm work together.

Talent Mapping helps ensure the organizational structure reflects where the company is going.

The operating system helps that structure actually function as a connected organization.

Frontier-Tech Companies Become Team-of-Teams Organizations Early

The FEMA comparison is especially useful for frontier technology because organizational complexity can arrive before large headcount.

Imagine an 80-person defense company.

It may already contain:

hardware engineering,

software engineering,

systems engineering,

manufacturing,

quality,

program management,

supply chain,

business development,

finance,

security,

people,

and government relationships.

It may also depend on:

external manufacturers,

specialized suppliers,

government customers,

research partners,

prime contractors,

investors,

and the board.

That is already a complex team-of-teams system.

The CEO may ask:

Why does this feel like a 300-person company when we only have 80 people?

Because complexity is not only a function of headcount.

It is a function of:

specialization,

dependencies,

decision interfaces,

outside stakeholders,

technical constraints,

and the consequences of coordination failure.

A small frontier-tech company can therefore require a mature operating system earlier than a much larger but less interdependent company.

This is an important buying insight.

The trigger for implementing an operating system should not simply be:

How many employees do we have?

A better question may be:

How many teams and dependencies now have to coordinate for us to accomplish the plan?

The Bigger Lesson From ICS Is Scalable Coordination

FEMA's Incident Command System is designed for a fundamentally different environment from a business.

A company should not attempt to run itself like an emergency incident.

Peak does not replicate ICS roles, command structures, operational periods, or incident-management procedures.

The useful comparison is at the organizational-design level.

ICS demonstrates that as complexity changes, organizations can combine:

common terminology with specialized roles,

clear objectives with distributed execution,

standardized interfaces with flexible structure,

clear authority with cross-organizational coordination,

local expertise with shared information,

and organizational expansion without requiring one leader to personally manage everything.

Those are powerful scaling principles.

Peak OS emerged from a very different body of experience, but many of the same organizational needs appear.

Mission creates common direction.

Three-Year Vision and One-Year Plan create shared horizons.

OKRs and KPIs make outcomes and performance visible.

Roles and Responsibilities clarify ownership.

Symbiosis connects specialized teams.

Weekly Camp creates recurring synchronization.

Triage creates a decision mechanism.

Team Surveys and planning cadence create learning.

And the system can operate across leadership, functional, divisional, and other teams without requiring those teams to give up the specialized processes that make them effective.

What Changes When the Company Becomes a Team of Teams?

The answer is not that everything needs more process.

The change is deeper.

Leadership can no longer rely primarily on proximity.

Context needs a system.

Dependencies need a system.

Ownership needs a system.

Organizational visibility needs a system.

Coordination needs a system.

Decision-making needs a system.

Learning needs a system.

The company still needs great leaders.

It still needs talented specialists.

It still needs functional excellence.

But those capabilities have to be connected.

That is the organizational transition many companies feel somewhere between being one team and becoming an enterprise.

The organization begins asking:

How do we add structure without becoming bureaucratic?

How do we preserve autonomy without creating silos?

How do we maintain visibility without putting the CEO in every meeting?

How do we create one operating rhythm without making every team identical?

How do we keep experienced executives operating as one leadership team rather than importing separate management systems?

These are not isolated management problems.

They are symptoms of the same underlying transition:

The company has become a team of teams, but the way it operates has not yet caught up.

FEMA's ICS provides one external example of an organization designed explicitly around modular, scalable coordination.

Peak OS addresses the business version from another direction.

The common principle is worth remembering:

As an organization becomes more complex, the answer is neither centralized control nor independent silos. The answer is a system that allows specialized teams to remain specialized while coordinating around common objectives, shared information, clear ownership, and compatible operating rhythms.

That is what allows a company to scale beyond one team without losing the coordination that made the original team successful.

Related Insights

What Is Peak OS?

What Is Organizational Execution?

What Is Organizational Intelligence?

What Is a Business Operating System?

What Is Operating Rhythm?