Why Cross-Functional Initiatives Fail Even When Every Function Is Strong: What TeamSTEPPS and Peak OS Reveal About Multi-Team Systems

A company can have a strong Engineering team, strong Product team, strong Sales team, strong Finance team, and strong Operations team—and still fail at its most important company initiatives.

That creates a frustrating question for CEOs:

Why do cross-functional initiatives fail even when every function involved is good at what it does?

The answer is often not inside any one team.

It is between the teams.

Engineering understands its work.

Product understands its work.

Sales understands its work.

Finance understands its work.

Each function may have talented leaders, clear priorities, good internal communication, and strong execution discipline.

But the company outcome depends on another capability:

Can those specialized teams operate together as one coordinated system?

There is a substantial body of research behind that question, and one of its most useful applications is TeamSTEPPS—Team Strategies and Tools to Enhance Performance and Patient Safety.

TeamSTEPPS is often described as a healthcare teamwork framework. That is accurate, but incomplete.

The Agency for Healthcare Research and Quality and the U.S. Department of Defense jointly developed TeamSTEPPS through a multi-year research and development effort and released it nationally in 2006. Its intellectual roots reach beyond healthcare into decades of research on teamwork in high-risk environments, including the military, aviation, and nuclear power. AHRQ specifically describes the current TeamSTEPPS curriculum as drawing from more than 50 years of evidence in environments where the consequences of poor team performance can be significant.

That history matters.

TeamSTEPPS is not simply another management framework that happened to arrive at concepts such as shared situational awareness, coordinated teams, clear roles, communication, and mutual support.

It represents decades of team-performance research being synthesized and adapted across military, aviation, human-factors, and healthcare environments.

Healthcare became one of the places where those ideas were formalized around a particularly important concept: the multi-team system.

AHRQ defines team structure as either an individual team or a set of teams—a multi-team system, or MTS—working collaboratively around the patient's needs. Its current framework combines that structure with four teachable capabilities: Communication, Team Leadership, Situation Monitoring, and Mutual Support.

Peak OS was developed through a different path.

It emerged from more than two decades of working with hundreds of founders, CEOs, leadership teams, and investors and identifying the recurring operating behaviors that enabled companies to execute as they became more complex. Those behaviors became SCALE: Symbiosis, Communication, Alignment, Learning, and Empowerment.

That makes the comparison more interesting—not less.

Military, aviation, healthcare, and growth-company experience all point toward a similar organizational truth: once important outcomes depend on multiple specialized teams, performance depends on the system connecting those teams—not merely the capabilities inside each one.

For aerospace, defense, robotics, advanced manufacturing, autonomy, physical AI, and other frontier-tech companies, that is an increasingly important execution problem.

TeamSTEPPS Has Roots in Military and Aviation Team Performance

Understanding where TeamSTEPPS came from helps explain why its ideas are so relevant outside healthcare.

AHRQ and the Department of Defense jointly developed the framework, with DoD's Military Health System playing an important role in its early development and implementation. AHRQ describes TeamSTEPPS as the result of a multi-year R&D effort between the two organizations and notes that it was released nationally in 2006 as a standardized approach to healthcare team training.

But the research lineage goes further back.

TeamSTEPPS drew from evidence about teams operating in environments where coordination failures can have serious consequences. AHRQ specifically identifies aviation, the military, and nuclear power among the high-risk environments informing the framework.

Crew Resource Management, or CRM, is part of that history.

Aviation developed CRM around the recognition that technical competence alone did not prevent failures. Teams also needed better communication, situation awareness, leadership, decision-making, workload coordination, and the ability to challenge or support one another appropriately.

Those lessons moved into healthcare through medical team-training efforts, including earlier programs that adapted aviation crew-resource concepts for clinical teams. AHRQ's TeamSTEPPS evidence base continues to identify Crew Resource Management as one of the important research foundations behind the framework.

So the lineage looks roughly like this:

Military and high-risk team-performance research

↓

Aviation Crew Resource Management and human factors

↓

Military and civilian medical team training

↓

AHRQ + Department of Defense TeamSTEPPS

↓

Healthcare multi-team systems

This context changes the significance of the comparison with Peak.

The argument is not that healthcare independently discovered something similar to Peak.

The more compelling observation is that a body of team-performance knowledge has repeatedly crossed domains because different high-complexity environments keep encountering similar coordination problems.

Peak independently encountered many of those same problems through growth companies.

A Group of Strong Teams Is Not Automatically a Strong Multi-Team System

TeamSTEPPS makes an important distinction between individual teams and the larger system in which they operate.

AHRQ explicitly describes a multi-team system as multiple interconnected teams collaborating around a shared outcome. Understanding how those teams interact is considered essential to effective teamwork.

That distinction becomes critical as companies scale.

Imagine a major product launch.

Engineering has to build it.

Product has to establish requirements and priorities.

Marketing has to create demand.

Sales has to prepare customers and the market.

Customer Success has to prepare existing accounts.

Finance has to support the investment.

People may need to hire new capabilities.

Operations may need processes that did not previously exist.

Each team can perform its own work well.

The launch can still fail.

Why?

Because the launch itself does not exist neatly inside any single function.

It exists in the relationships among them.

That means functional excellence and organizational execution are different capabilities.

A strong Engineering team can be part of a poorly functioning organizational system.

A great Sales team can hit local goals while creating unintended problems elsewhere.

A Product team can make individually rational decisions that conflict with commitments another team is making.

Finance can optimize runway in a way that unintentionally constrains a capability the company needs to achieve the plan.

The functions are not necessarily weak.

The multi-team system is.

Peak Calls the Team-of-Teams Behavior Symbiosis

This is where Peak's concept of Symbiosis becomes much more operational than it may initially sound.

In Peak Teams, Symbiosis describes an organization in which people understand their contribution, trust others to execute their roles, and work collectively toward shared Mission and organizational outcomes. The concept explicitly extends beyond a single team to the company as a team of teams.

The question therefore changes from:

Is every function performing?

to:

Are the functions performing together?

Those questions can produce very different answers.

Sales can be at 110% of goal.

Engineering can be delivering its planned work.

Marketing can be generating leads.

Finance can be hitting runway targets.

And the One-Year Plan can still miss because the outputs of those functions do not combine into the organizational outcomes the company actually needed.

That is why Team-of-Teams is not simply language for having several good teams.

It describes another level of organizational capability.

Why Do Cross-Functional Initiatives Fail Even When Every Function Is Strong?

We can make the buyer problem more specific.

Cross-functional initiatives frequently fail because the coordination requirements exist outside normal functional ownership.

Product knows its priorities.

Engineering knows its roadmap.

Sales knows its targets.

But who owns the dependency between the Product roadmap and the customer commitment Sales just made?

Manufacturing understands production.

Engineering understands design.

Who owns the interface when an engineering decision changes production timing?

Finance understands capital.

People understands hiring.

Who owns the connection between the technical capabilities assumed in the One-Year Plan and the time required to recruit them?

These are not necessarily accountability failures inside functions.

They are interface failures between functions.

This is one reason companies can become increasingly frustrated as they hire more experienced executives.

Every function improves.

Yet coordination becomes harder.

The company has increased specialized capability faster than it has increased the system's ability to integrate that capability.

Shared Mental Models Are a Core TeamSTEPPS Outcome

One of the most useful concepts inside TeamSTEPPS is the shared mental model.

AHRQ defines a shared mental model as a common picture of the relevant facts and relationships defining an event, situation, or problem. Shared mental models help people understand responsibilities, information requirements, goals, strategies, and how individual roles relate to one another. They also help team members anticipate changing needs and adjust their actions as circumstances change.

That concept has a powerful business parallel.

A leadership team may believe everyone is aligned because everyone attended the same strategic-planning session.

But ask each executive independently:

What are the company's most important outcomes this year?

What does success look like?

What are the most important objectives right now?

What is the biggest risk to the plan?

Who owns this cross-functional outcome?

What other teams are dependent on it?

What would cause us to reconsider the plan?

The answers may be different.

That difference matters.

Hearing the same strategy is not the same thing as maintaining a shared mental model.

Peak creates shared organizational context through several connected mechanisms.

The Mission establishes why the organization exists.

The Three-Year Vision creates a common future destination.

The One-Year Plan establishes the nearer definition of success.

OKRs identify the important organizational outcomes and capabilities being built now.

KPIs make operating conditions visible.

Roles and Responsibilities clarify ownership.

Together, these mechanisms give teams more than a set of goals.

They create a shared picture of why, where, what, how, and who.

Shared Understanding Does Not Require Identical Knowledge

AHRQ makes another useful distinction.

People enter teams with different experiences, perspectives, and information. Those differences can improve the team's understanding when they are communicated and integrated. Without effective sharing, however, the same differences can prevent the group from developing a common picture.

That is exactly what organizations need from specialization.

Engineering should understand Engineering better than Sales.

Sales should understand customers and pipeline better than Engineering.

Finance should understand capital better than Product.

Manufacturing should understand production better than everyone else.

The objective is not to make everyone equally knowledgeable.

It is to create compatible understanding.

Engineering needs to understand the customer commitment that affects its work.

Sales needs to understand the technical constraint affecting what it can promise.

Finance needs to understand the organizational capabilities required by the plan.

People needs visibility into which specialized roles will become execution constraints if they are not filled.

Each team retains different knowledge.

The company gains enough common knowledge to coordinate.

That is a Team-of-Teams capability.

Situation Monitoring Turns Individual Awareness Into Shared Understanding

TeamSTEPPS treats Situation Monitoring as one of its four core skills.

AHRQ describes it as actively and continuously scanning the situation to understand what is happening. Individual situation monitoring creates situation awareness; when team members communicate that awareness effectively, the team can develop a shared mental model.

AHRQ makes the reason particularly clear: situation monitoring helps teams recognize potential issues or deviations early enough to address them before they become larger problems.

That closely parallels a core buyer question for growth-company leaders:

How do we create shared visibility across functions using different systems?

Engineering may use Jira.

Sales uses Salesforce.

Finance uses financial-planning systems.

Manufacturing uses an ERP or manufacturing-execution platform.

Product has its own roadmap.

The answer is not necessarily putting every operational detail into one system.

The systems exist for different purposes.

Peak creates a shared execution layer above them.

Leadership does not need every Engineering ticket.

It may need to know whether an important company-level product outcome is On-Course.

It does not need every sales opportunity.

It needs the KPIs necessary to understand whether the revenue plan remains healthy.

It does not need every recruiting activity.

It may need to know whether a critical role assumed by the One-Year Plan is likely to be filled when the capability is required.

The common picture contains decision-relevant information, not every available fact.

Weekly Camp Creates a Recurring Situation-Monitoring Loop

Peak's Weekly Camp is especially relevant here.

The team reviews OKRs.

On-Course.

Off-Course.

Done.

Pushed.

It reviews KPIs.

On-Course.

Off-Course.

If an issue requires deeper understanding or a decision, it can move into Triage.

This is not simply status reporting.

The underlying question is:

Has something changed that matters to our ability to accomplish the shared plan?

That creates a recurring organizational situation-monitoring loop.

A product milestone changes.

The team sees it.

A KPI deteriorates.

The team sees it.

A key capability falls Off-Course.

The team sees it.

Once the information becomes shared, the organization can decide whether action is required.

The earlier that occurs, the greater the number of options usually available.

Mutual Support Goes Beyond Being a Helpful Teammate

TeamSTEPPS also emphasizes Mutual Support.

AHRQ describes mutual support as team members assisting one another, sharing feedback, monitoring workload, and speaking up when important concerns arise. It is sometimes referred to as backup behavior because team members understand one another's responsibilities well enough to recognize when support is needed.

There is a deeper business application here.

Functional accountability says:

Did my team deliver its goals?

Team-of-Teams accountability adds:

What does the organization need from my team for the shared outcome to succeed?

Suppose Product owns a company OKR but Engineering owns two critical Key Results.

Engineering is not "helping Product."

Engineering is contributing to a company outcome.

Suppose Finance shifts resources because Manufacturing has become the critical constraint on the One-Year Plan.

Finance is not abandoning its function.

It is helping optimize the organizational system.

Peak's Symbiosis similarly requires teams to understand that what is best for the company may occasionally be different from what optimizes their individual function.

That is operational mutual support.

Team Leadership in a Multi-Team System Is Different From Functional Leadership

TeamSTEPPS defines Team Leadership partly as the ability to lead effectively within a multi-team system, ensuring that team actions are understood, changes in information are shared, and people have the resources they need.

That creates another important leadership distinction.

A VP of Engineering has at least two responsibilities.

The first is to lead Engineering.

The second is to be a member of the team responsible for the company.

Those roles are not always perfectly aligned.

Engineering may prefer to spend the quarter reducing technical debt.

The organization may urgently need a customer capability.

Finance may prefer greater spending discipline.

The organization may need to hire ahead of revenue to achieve a mission-critical program.

Sales may want maximum flexibility.

The company may need Product focus.

The leadership team cannot simply consist of functional advocates negotiating for their departments.

Each executive has to optimize the larger organizational system.

That transition—from functional leader to enterprise leader—is one of the most important changes executives make as companies scale.

Who Owns the Space Between Teams?

This may be the most important question in cross-functional execution.

If Sales owns Sales and Engineering owns Engineering, who owns the work between Sales and Engineering when the company objective depends on both?

Sometimes it is the owner of a specific company OKR.

Sometimes it is Product.

Sometimes Program Management.

Sometimes the leadership team has to resolve the interface.

Different situations require different answers.

TeamSTEPPS makes the coordination problem explicit through its multi-team-system architecture. AHRQ recognizes that interconnected teams require leadership and structural understanding across the system rather than assuming individual teams will naturally coordinate.

Peak addresses the same organizational problem differently.

Company-level OKRs can give one person clear ownership of the outcome while Key Results are distributed across the leaders and teams necessary to achieve it.

Roles and Responsibilities clarify functional ownership.

Weekly Camp exposes dependencies.

Triage creates a place for cross-functional decisions.

The leadership team maintains responsibility for optimizing the company as a whole.

The deeper lesson is straightforward:

Coordination itself is work.

If nobody owns it, leadership is assuming it will magically emerge from functional excellence.

It often does not.

Cross-Functional Accountability Needs Singular Ownership and Shared Contribution

This is one reason cross-functional accountability can be confusing.

A company says:

"We all own the launch."

That sounds collaborative.

Operationally, it may mean nobody owns the launch.

Peak creates a clearer distinction.

An objective should have an owner.

Key Results can have different owners.

Different functions may contribute.

But there is still clarity around the person accountable for driving the shared outcome.

In Peak Teams, Peak OKRs explicitly define ownership of both Objectives and Key Results, while the leadership team discusses functional intersections because important company objectives rarely exist inside only one organizational silo.

That gives the multi-team system a visible architecture:

one shared outcome,

clear ownership,

multiple specialized contributions.

That is much more scalable than "everyone owns it."

How Do You Stop Every Cross-Functional Disagreement From Escalating to the CEO?

This is one of the clearest buyer symptoms of a poorly functioning multi-team system.

Product and Engineering disagree.

CEO.

Sales and Product disagree.

CEO.

Finance and People disagree.

CEO.

A customer commitment conflicts with technical reality.

CEO.

The CEO gradually becomes the company's universal coordination layer.

At first, this may work because the founder has broad organizational context.

Eventually it becomes a bottleneck.

The healthier answer is not removing the CEO from leadership.

It is increasing the decision-making capacity of the organizational system underneath the CEO.

Teams need:

clear company priorities,

clear outcome ownership,

clear Roles and Responsibilities,

shared information,

visible dependencies,

known decision rights,

and a reliable forum for issues crossing team boundaries.

Peak's Triage process helps provide that forum.

The team uses ACT:

Assess the situation.

Consider alternatives.

Take action.

The goal is not another discussion.

The goal is movement—a decision, action, owner, or information requirement that allows execution to continue.

Sometimes Triage also reveals that the real problem is unclear ownership.

Clarify the ownership, and the next five similar decisions may never need to reach the CEO.

TeamSTEPPS Uses Different Forums for Different Team Needs

Another useful TeamSTEPPS principle is that not every team conversation serves the same purpose.

The framework includes practices such as Briefs, Huddles, and Debriefs to establish plans, adjust when conditions change, and learn from performance.

This reflects a broader design principle in TeamSTEPPS: teamwork is maintained through repeated communication, situation monitoring, leadership, and mutual support rather than through one generic "team meeting." AHRQ notes that regular information sharing through team forums helps maintain shared mental models as circumstances change.

Peak has a similar philosophy.

Annual and Quarterly or Semiannual Sessions create planning and reflection.

Weekly Camp creates execution visibility.

Triage creates focused problem-solving and decision-making.

Team Surveys create structured organizational feedback.

Each forum has a different job.

That matters because companies often solve coordination problems by simply adding meetings.

A strong operating rhythm instead asks:

What organizational function needs to happen, and what is the right recurring mechanism for it?

More Meetings Can Be Evidence That the Interfaces Are Weak

Consider what happens when teams do not trust the organizational interfaces.

Product schedules a recurring Engineering alignment meeting.

Sales starts a recurring Product sync.

Finance introduces a workforce-planning meeting.

Operations creates another cross-functional review.

Program Management creates another status meeting.

Leadership adds another executive update.

The company is now spending enormous amounts of time compensating for weak coordination.

The problem is not necessarily the meetings themselves.

The problem is that the organization does not have a reliable coordination architecture.

TeamSTEPPS provides standardized teamwork tools and capabilities.

Peak creates a business operating rhythm.

Both point toward the same principle:

Predictable coordination can reduce reactive coordination.

The purpose of Weekly Camp is not one more meeting.

It is to create enough reliable visibility, communication, and problem-solving that teams do not need to create a new meeting every time an issue crosses a functional boundary.

Shared Mental Models Have to Be Maintained, Not Created Once

Alignment decays.

A leadership team can leave an Annual Session completely clear about the plan.

Then the environment changes.

A major customer creates new information.

A product experiment succeeds unexpectedly.

A hiring constraint appears.

A board member introduces new strategic context.

A program milestone slips.

A competitor changes the market.

Different teams begin updating their understanding at different speeds.

Soon, they are operating from different versions of reality.

TeamSTEPPS treats situation monitoring and shared mental models as continuous. Team members need to keep scanning, sharing, and updating their understanding because situations change.

Peak's cadence serves a similar organizational need.

Weekly Camp updates the current execution picture.

Quarterly or Semiannual Sessions return to the One-Year Plan.

Annual Planning refreshes the longer-term horizon.

The objective is not to align once.

It is to remain aligned while reality continues changing.

That is considerably harder.

The Military and Aviation Lineage Strengthens the Multi-Team Insight

Putting TeamSTEPPS in historical context makes the broader pattern easier to see.

Military teams had to develop ways to coordinate people operating with distinct expertise under uncertainty.

Aviation applied team-performance and human-factors research to crews where technical competence was essential but insufficient without communication, situation awareness, leadership, and coordinated decisions.

Military and civilian healthcare adapted many of those lessons to clinical environments where multiple specialists, teams, and support systems needed to combine their work around a patient.

TeamSTEPPS then synthesized a substantial evidence base into a standardized healthcare teamwork system developed by AHRQ and DoD.

Now consider what is happening in complex frontier-tech companies.

The domain is different.

The consequences are different.

The teams are different.

But the organizational question is recognizable:

How do highly specialized groups maintain enough shared context and coordination to act as one larger system?

Peak OS arrived at its answer through a different path—hundreds of growth-company engagements.

That independent convergence is the part worth paying attention to.

Frontier Tech Is Inherently Multi-Team Work

Consider an autonomous systems company.

Systems Engineering owns the integrated architecture.

Hardware Engineering owns physical components.

Software owns algorithms and control systems.

Manufacturing owns production.

Quality owns validation.

Supply Chain owns component availability.

Program Management owns program integration.

Business Development owns customer relationships.

Finance owns capital planning.

People owns organizational capability.

No one team delivers the product.

The outcome exists across all of them.

Now add external teams:

government customers,

contract manufacturers,

critical suppliers,

regulators,

research partners,

strategic partners,

investors,

and the board.

The multi-team system extends beyond the org chart.

This is why some frontier-tech companies become organizationally complex at surprisingly small headcounts.

The question is not only:

How many people do we have?

It is:

How many specialized teams and dependencies have to converge for us to accomplish the Mission?

That can be a much better indicator of whether informal coordination is still sufficient.

SCALE Can Be Viewed as Multi-Team-System Behavior

The TeamSTEPPS comparison also illuminates Peak's five SCALE behaviors from another angle.

Symbiosis means specialized teams understand that organizational outcomes depend on their interdependence.

Communication allows relevant information to cross functional and hierarchical boundaries.

Alignment creates enough shared understanding around Mission, plans, priorities, and outcomes to coordinate decisions.

Learning lets teams improve the interfaces among them after execution exposes weaknesses.

Empowerment gives people and teams enough ownership to act without every coordination issue becoming a CEO decision.

Those behaviors reinforce one another.

Situation awareness without Communication stays trapped inside individuals.

Communication without Alignment produces more information but not shared direction.

Alignment without Empowerment forces decisions upward.

Empowerment without Symbiosis creates local optimization.

Execution without Learning causes the organization to repeat the same coordination failures.

A strong multi-team system needs the behaviors to work together.

TeamSTEPPS and Peak Should Not Be Presented as Equivalent Systems

The distinction matters.

TeamSTEPPS is an evidence-based healthcare teamwork framework with roots in decades of military, aviation, human-factors, and other high-risk team-performance research. It was jointly developed by AHRQ and the Department of Defense and adapted specifically for healthcare.

Peak OS is a business operating system synthesized through work with hundreds of growth-company teams.

Peak is not healthcare team training.

Weekly Camp is not a clinical huddle.

Symbiosis is not TeamSTEPPS Mutual Support.

A leadership team is not a medical multi-team system.

The useful comparison exists at a deeper organizational level:

When important outcomes require multiple specialized teams, performance depends on the quality of the system connecting those teams.

That conclusion has appeared repeatedly across high-risk team-performance research.

It also appeared independently in Peak through growth-company execution.

The Organization Is the Team

When a company is small, leaders ask:

Do we have a great team?

As it grows:

Do we have great teams?

Eventually there is another question:

Do those teams operate as one organization?

That final question is where organizational execution lives.

The Sales team can succeed while the company fails.

Engineering can succeed while the company fails.

Product can succeed while the company fails.

Finance can succeed while the company fails.

The unit that ultimately has to perform is the organizational system.

TeamSTEPPS makes that visible through the concept of a multi-team system.

Peak approaches it through Team-of-Teams and Symbiosis.

And the military and aviation roots of TeamSTEPPS make the broader lesson even more powerful.

For decades, different high-consequence environments have learned that technical expertise alone is not enough.

Specialists need ways to:

share relevant information,

maintain situational awareness,

create shared mental models,

understand roles,

coordinate dependencies,

support one another,

surface problems,

make decisions,

and continually update their understanding as conditions change.

Growth companies eventually encounter the same organizational requirement.

They still need excellent functional teams.

But once the company becomes a team of teams, the spaces between those teams become part of the work.

And for CEOs building aerospace, defense, robotics, advanced manufacturing, autonomy, physical AI, and other frontier-tech organizations, the next stage of scale may not require every function to become dramatically better.

It may require the system connecting those functions to become dramatically better.

Related Insights

What Is Peak OS?

What Is Organizational Execution?

What Is Organizational Intelligence?

What Is a Business Operating System?

What Is Operating Rhythm?