Cross-functional execution is where many COO roles are born and where many COO roles go to die.

The problem is obvious: important work rarely fits inside one function. Enterprise deals require sales, product, legal, security, finance, implementation, and support. Product launches require product, engineering, marketing, sales, enablement, support, and customer success. International expansion requires legal, finance, people, product, operations, and GTM. Cost programs require every leader to make tradeoffs.

When this work breaks down, companies look to the COO.

That is reasonable. The COO often should own the cross-functional operating model. But there is a trap: the COO becomes the person through whom all cross-functional work must pass.

That is not leverage. That is congestion.

The COO should design flow, not absorb all friction

A weak cross-functional system depends on heroic coordination. Someone chases updates, negotiates between teams, remembers dependencies, escalates blockers, cleans up missed handoffs, and keeps the whole thing alive through personal energy.

Many COOs are good at this. That is why it is dangerous.

If the COO personally carries every major initiative, the company learns that cross-functional ownership is optional. Leaders wait for the COO to convene, clarify, arbitrate, and follow up. The COO feels useful. The system gets weaker.

The COO's real job is to build a model where cross-functional work has clear owners, decision rights, dependencies, escalation paths, and review rhythms without needing the COO as permanent project glue.

The COO should intervene to improve the system, not to become the system. A good rule: every time the COO personally saves a cross-functional initiative, they should also ask what operating mechanism would have prevented the rescue from being necessary.

Start with the type of cross-functional work

Not all cross-functional work should be managed the same way.

A strategic product launch, a customer escalation, an annual planning cycle, an enterprise readiness program, a margin improvement initiative, and an acquisition integration are different operating objects. They need different cadence, authority, documentation, and escalation.

The COO should categorize cross-functional work:

Run-the-business coordination: recurring handoffs between functions, such as sales-to-CS, product-to-support, marketing-to-sales, finance-to-people, or roadmap-to-enablements.

Strategic initiatives: time-bound efforts tied to company priorities, such as moving upmarket, launching a new product, improving gross margin, or entering a new region.

Customer-critical execution: specific commitments or escalations where multiple functions must coordinate around customer outcomes.

Transformation programs: structural changes that alter operating model, cost structure, systems, or organization.

Crisis response: urgent, high-stakes work requiring temporary centralization and fast escalation.

Each type needs a different operating pattern. Treating everything as a project creates bureaucracy. Treating everything as informal coordination creates chaos.

Assign one accountable owner

The most common cross-functional failure is shared ownership.

Shared input is fine. Shared accountability is usually fake.

Every major cross-functional effort needs one accountable owner. That owner does not need to do all the work or outrank every participant. They need to own the outcome, drive the operating rhythm, surface tradeoffs, and escalate when needed.

The owner should be chosen based on the outcome, not politics.

  • A product launch may be product-owned if the core risk is product readiness, or GTM-owned if the core risk is market execution.
  • An enterprise customer issue may be CS-owned if the outcome is retention and delivery, with product owning specific commitments.
  • A cost program may be finance-owned, but the COO may own cross-functional operating decisions.
  • A systems migration may be business operations-owned with executive sponsorship.

The COO should resist becoming the owner by default. Default COO ownership is a sign the company has not clarified the real outcome.

Define the decision spine

Cross-functional work fails when decisions are scattered across meetings.

Every major initiative needs a decision spine:

  • What decisions must be made?
  • Who owns each decision?
  • What input is required?
  • What forum will decide?
  • What is the deadline?
  • What happens if teams disagree?

Without a decision spine, teams spend weeks aligning on context while the real tradeoffs stay unresolved.

The COO can help by forcing initiatives to name the decisions early. For example:

  • What is in scope versus out of scope?
  • What launch date are we committing to?
  • What customer commitments are allowed?
  • What quality bar must be met?
  • What resources are protected?
  • What work stops if this becomes priority?
  • What risks require executive escalation?

This turns cross-functional execution from coordination into managed tradeoff.

Separate sponsor, owner, and contributors

Cross-functional work gets foggy when sponsorship, ownership, and contribution collapse into one vague group. The COO should force three roles apart:

  • Sponsor: the executive who wants the outcome and can protect tradeoffs.
  • Owner: the person accountable for day-to-day execution and decision flow.
  • Contributors: functions or teams responsible for defined workstreams.

The COO may be sponsor for some work and architect for the system, but should rarely be the default owner of every initiative. If everything important needs COO ownership, the company has not built cross-functional capacity.

Build lightweight initiative architecture

A practical cross-functional initiative model includes:

Outcome: what changes if the initiative works.

Owner: one accountable person.

Executive sponsor: the leader who can resolve tradeoffs beyond the owner's authority.

Decision rights: who decides what.

Milestones: not activity lists, but meaningful progress gates.

Dependencies: what each function must deliver and by when.

Risks: what could break the outcome.

Escalation triggers: when the issue moves to executive level.

Review cadence: how often progress, risks, and decisions are reviewed.

Exit criteria: when the initiative is done or should be stopped.

This is not heavyweight. It is the minimum structure required to prevent ambiguity from becoming motion.

Do not turn every dependency into a meeting

Cross-functional work often generates meetings because meetings feel like control. The COO should be careful. More meetings can increase visibility while decreasing ownership.

A better rule: meetings should exist for decisions, tradeoffs, risk review, and learning. Updates can often be written. Dependency tracking can be visible asynchronously. Escalations should be structured.

The COO should ask of every cross-functional meeting:

  • What decision or tradeoff happens here?
  • Who must attend for that decision?
  • What preparation is required?
  • What output is produced?
  • What would break if this meeting disappeared?

If the answer is vague, the meeting is probably compensating for unclear ownership.

The COO as bottleneck detector

The COO should watch for patterns:

  • Every initiative needs COO presence to move.
  • Teams wait for executive alignment before making local decisions.
  • Owners provide updates but avoid asking for tradeoffs.
  • Functional leaders send delegates without decision authority.
  • Risks are escalated as surprises.
  • Cross-functional work depends on personal relationships rather than role clarity.
  • Postmortems identify the same handoff problems repeatedly.

These are not merely execution issues. They are operating model defects.

The COO's response should be to improve ownership, forums, decision rights, or resource allocation — not simply to work harder.

The goal is distributed execution

A great COO makes cross-functional execution less dependent on the COO over time.

That does not mean disappearing. It means the COO reserves their attention for operating design, high-stakes tradeoffs, executive accountability, and system learning. Routine cross-functional work should move through capable owners with clear rules.

The highest compliment is not “Nothing moves without the COO.”

The highest compliment is “The company knows how to move complex work without losing ownership, speed, or reality.”

That is the difference between coordination and operating architecture.