When One Team's Priority Depends on Another Team's Capacity: How Leadership Teams Resolve Cross-Functional Tradeoffs

A priority can belong to one team.

Capacity often does not.

That distinction creates some of the hardest decisions inside a growing company.

Sales has an important enterprise opportunity, but closing it requires Product and Engineering work that is not on the roadmap.

Product believes a customer capability should move forward, but Engineering is already committed to reliability and infrastructure work.

Marketing wants to accelerate a launch, but Product is not ready.

Customer Success needs a product change to address churn, but the same engineering capacity is required for a strategic initiative.

People wants to increase hiring, while Finance is trying to protect runway.

Each team can be right from the perspective of its function.

The problem is that the organization cannot execute every locally rational priority at the same time.

This is where cross-functional execution stops being primarily a communication problem and becomes a tradeoff problem.

One of the most important principles I have learned working with growth-company teams is this:

When one team's priority requires another team's constrained capacity, it is no longer only that team's priority. It has become an organizational decision.

The leadership team's job is not to determine which executive argues most persuasively.

It is to create enough shared context, visibility, ownership, and decision clarity that the organization can decide where its limited capacity creates the greatest value.

Strong Functions Naturally Create Competing Priorities

As organizations grow, functions become more sophisticated.

That is necessary.

Sales should understand what it needs to hit revenue goals.

Product should understand the roadmap.

Engineering should understand technical capacity and reliability requirements.

Marketing should understand demand generation.

Finance should understand capital constraints.

People should understand talent requirements.

Customer Success should understand what customers need.

Strong executives are supposed to advocate for those realities.

The problem begins when functional priorities are treated as though they exist independently.

They do not.

A Sales priority may require Product.

A Product priority may require Engineering.

Engineering hiring may require Finance and People.

A Marketing launch may depend on a Product release.

A customer-retention objective may depend on changes across Product, Engineering, Sales, and Customer Success.

In Peak Teams, the One-Year Plan is intentionally reviewed cross-functionally: marketing leads should connect with sales metrics, product work with engineering releases, and financial resources with hiring plans. Peak OKRs similarly treat important objectives as cross-functional initiatives rather than isolated departmental work.

That is the operating reality of a Team-of-Teams.

The functions remain distinct.

Their execution is interconnected.

The Conflict Is Often Not Sales Versus Engineering

Consider a common situation.

A CRO comes to the leadership team with an enterprise opportunity.

The customer is strategically valuable.

The contract could materially affect the quarter.

But the customer requires a capability the company does not currently have.

Sales says:

“We need this to close the deal.”

Product says:

“The capability is valuable, but it wasn't in this quarter's plan.”

Engineering says:

“We can do it, but something else has to move.”

That last sentence is where the real conversation begins.

The issue is not whether Engineering is being cooperative.

It is not whether Sales is being unreasonable.

It is not even initially whether the customer request is a good idea.

The issue is:

What should the organization stop, delay, reduce, resequence, or resource differently in order to create the capacity required for this opportunity?

Until that question is answered, leadership has not actually made a decision.

It has simply added demand.

Capacity Is Part of Strategy

Leadership teams can sometimes think about strategy and capacity as separate subjects.

Strategy determines what we want to do.

Operations figures out how to fit it in.

That works poorly in growth companies.

Capacity is one of the constraints through which strategy becomes real.

Peak Teams notes that rapidly growing companies commonly overestimate their capacity while underestimating the time and resources required to reach important goals.

That problem gets worse when capacity is shared across many objectives.

Imagine Engineering has capacity for three major initiatives.

The company has already committed to three.

Then Sales produces a strategically significant customer request.

Product identifies another emerging opportunity.

Security discovers a risk requiring immediate work.

Leadership now has six demands against capacity for three.

No meeting technique can remove that mathematical reality.

The leadership team has to prioritize.

Autonomy Does Not Mean One Function Can Allocate Another Function's Capacity

Strong organizations need functional autonomy.

Executives should not need the CEO to approve every local decision.

But autonomy needs boundaries.

A CRO should have significant authority over Sales.

A CTO should have significant authority over Engineering.

A CMO should have significant authority over Marketing.

The complexity appears when one leader's decision creates work inside another leader's function.

Sales can decide how to pursue an account.

It cannot independently decide that Engineering will spend six weeks building something for that account.

Product can advocate for a new capability.

It cannot assume that Engineering capacity automatically follows.

Marketing can choose a campaign strategy.

It cannot independently guarantee a launch date that depends on another team's work.

The moment a decision materially consumes another team's constrained capacity, the organization needs a shared tradeoff mechanism.

That protects functional autonomy rather than undermining it.

Without that mechanism, leaders either fight over resources or repeatedly escalate to the CEO.

The CEO Should Not Become the Permanent Capacity Allocator

When cross-functional tradeoffs are unclear, they tend to move upward.

Sales and Product disagree.

Call the CEO.

Product and Engineering cannot agree on sequencing.

Call the CEO.

Finance and People disagree about hiring.

Call the CEO.

A customer commitment creates a conflict.

Call the CEO.

Soon the CEO becomes the organization's central resource-allocation system.

That can work when the company is small.

It becomes a major constraint as the organization grows.

The CEO still has an important role.

Some decisions genuinely belong there.

But the operating system should make enough direction, priorities, ownership, measures, and decision authority clear that every cross-functional tradeoff does not require CEO arbitration.

Peak's Roles and Responsibilities are designed to clarify accountability, decision authority, and how individual areas connect to the broader team. Clear ownership allows people to operate with greater autonomy rather than continually seeking approval.

The goal is not to eliminate escalation.

It is to make escalation intentional.

Start by Asking Whether the Priority Is Actually a Company Priority

Functional leaders naturally view their priorities through the reality they see every day.

That information is valuable.

It is also incomplete.

The first tradeoff question should therefore be:

How does this request connect to the company's larger plan?

Is this opportunity directly tied to a One-Year Plan outcome?

Does it advance one of the most important quarterly objectives?

Does it materially improve a company KPI?

Does it build a capability the organization has already identified as strategically important?

Or is it highly valuable primarily from inside one function?

This distinction matters.

Something can be a very good Sales opportunity without being the best company priority.

Something can be technically important without being the best use of organizational capacity right now.

Something can be valuable to Product while another capability is more important to the One-Year Plan.

The organization needs shared direction precisely because good opportunities will compete with one another.

Alignment gives leadership a basis for deciding.

Then Identify the Actual Constraint

Leadership teams sometimes debate priorities when they have not yet defined what is constrained.

Engineering capacity?

Product-management bandwidth?

Capital?

Hiring?

Executive attention?

Customer implementation capacity?

Legal review?

Data availability?

Operational support?

Time?

Sometimes the debate changes substantially once the constraint is made explicit.

Suppose the Sales request appears to require six weeks of Engineering work.

After discussion, the team discovers that only one technical component is actually blocking the deal.

A smaller solution may produce most of the value.

Or the team discovers that Engineering is not the true constraint at all.

Product needs to define requirements.

Security needs to approve an architecture.

Finance needs to approve pricing.

The first assumption about the capacity conflict can be wrong.

Before making the tradeoff, leadership needs to understand exactly what resource is scarce.

Make the Opportunity Cost Visible

Every capacity decision has two sides.

What will we gain by doing this?

And:

What will we not do because we chose it?

The second question is routinely underweighted.

Suppose an enterprise feature could help close $1 million in new revenue.

That sounds compelling.

But Engineering capacity has already been committed to work intended to reduce churn by several points.

Moving the team may delay that work by two months.

Now the decision is not:

Would we like another $1 million customer?

Of course.

It is:

Is this opportunity more important than the company outcome we would delay to create the required capacity?

That is a real tradeoff.

The original priority should not disappear from the conversation simply because the new opportunity is exciting.

Leadership needs to see both.

A Useful Cross-Functional Tradeoff Test

This is not a named Peak OS framework, but it is a useful synthesis for the decision leadership teams need to make.

When one team's priority requires another team's constrained capacity, work through seven questions.

1. What company outcome are we trying to improve?

Move above the functional argument.

What matters to the company?

Revenue?

Retention?

Product capability?

Reliability?

Market expansion?

Runway?

Customer experience?

A strategic partnership?

The discussion becomes more productive when leaders stop arguing from departmental positions and begin evaluating organizational outcomes.

2. How material is the opportunity or risk?

Not every request deserves the same attention.

What is the expected value?

How confident are we?

What happens if we do nothing?

Is the issue urgent or merely important?

Is the opportunity reversible?

Does it build a capability with value beyond the immediate situation?

A feature that serves one customer is different from a capability that unlocks an entire market.

3. What capacity is actually required?

Be specific.

Which team?

Which people?

How much time?

What other resources?

What decisions?

What support from other functions?

The more concrete the capacity requirement becomes, the easier the tradeoff becomes to evaluate.

4. What will move if we say yes?

This is the opportunity-cost question.

What current priority stops?

What gets delayed?

Which KPI or OKR may be affected?

Which customer commitment changes?

Which team becomes dependent on the new sequencing?

If leadership cannot answer this question, it probably has not fully evaluated the request.

5. Can we change the path instead of making a binary choice?

Not every capacity conflict requires a simple yes or no.

Can the scope be smaller?

Can delivery happen in phases?

Can another team contribute?

Can an external resource help?

Can the timing change?

Can the customer need be solved another way?

Can the existing objective be reframed?

Some of the best cross-functional decisions emerge when the team stops debating two fixed alternatives and creates a third.

6. Who has authority to make the tradeoff?

The team should know when the decision belongs to an objective owner, a functional executive, the leadership team, or the CEO.

Input can be broad.

Decision ownership should not be.

Organizations slow dramatically when every tradeoff requires consensus.

The objective is to hear the relevant perspectives, understand the implications, and then allow the appropriate owner to decide.

7. What changes throughout the system after the decision?

A decision is incomplete until its consequences become visible.

Which OKR changes?

Which timeline moves?

Which team needs to know?

Which dependency changed?

What commitment was replaced?

What metric should leadership watch?

What happens in the next Weekly Camp?

This prevents the leadership team from making a tradeoff while the organization continues executing the old assumptions.

The Best Decision May Be “No”

Growing companies often celebrate saying yes.

Yes to the customer.

Yes to the new market.

Yes to the feature.

Yes to the partnership.

Yes to the experiment.

But organizational focus is built just as much through what leadership declines.

A request can be valuable and still receive a no.

Not because the requesting function lost.

Because another use of the company's capacity is more important.

This is easier for teams to accept when the reasoning is visible.

“We don't care about Sales” creates conflict.

“This opportunity is valuable, but accepting it would require us to delay the reliability work tied to our highest company priority, and we've decided that reliability remains the greater organizational constraint” creates context.

People may still disagree.

But they can understand the decision.

That is alignment without requiring consensus.

The Best Decision May Also Be to Change the Plan

The reverse can happen.

A new opportunity can be important enough that the organization should change its existing commitments.

Plans are not sacred.

Operating rhythm exists partly so teams can compare their plans against reality and make intelligent changes.

A customer request may reveal a market need leadership underestimated.

A strategic partnership may create a new distribution opportunity.

Customer feedback may show that an existing Product priority is less important than leadership believed.

A capacity conflict can therefore create learning.

The answer may be:

Yes, this is more important.

We are moving the capacity.

But if so, leadership should make the entire tradeoff explicit.

The old priority does not remain silently active.

That is how organizations end up pretending to have five top priorities when they really have capacity for three.

Never Add a Priority Without Asking What Gives Way

This may be the most important practical rule in the article.

When capacity is constrained, adding a priority without subtracting or changing something else is not prioritization.

It is overcommitment.

This problem is common because leadership decisions and functional capacity can become separated.

The executive team says yes to something.

The functional leader returns to a team already operating at capacity.

Now the team has to solve the impossible equation.

Often they try.

Existing work remains.

The new priority is added.

People stretch.

Timelines quietly become less credible.

Everything moves slower.

Eventually leadership sees several objectives going off course.

What appears to be an execution problem may actually be the accumulated result of leadership repeatedly adding work without making the corresponding tradeoffs.

Capacity Should Be Visible During Planning, Not Only During Conflict

The best time to resolve these issues is before they become crises.

That is one reason cross-functional planning matters.

When the company builds its One-Year Plan and quarterly OKRs, functional leaders should not simply present their own priorities independently.

They should examine where those priorities interact.

Product and Engineering.

Marketing and Sales.

Finance and People.

Sales and Customer Success.

Operations and Product.

In Peak Teams, functional leaders bring their objectives into shared planning, where the whole team discusses and iterates them to create alignment rather than allowing functions to operate separate plans.

This is also where the broader Team-of-Teams planning model becomes valuable.

Information moves down from the larger company direction.

Operational reality moves up from teams closer to the work.

Dependencies move sideways between functions.

That interaction helps leadership discover capacity conflicts before commitments are made.

Teams Closest to the Work Often Understand Capacity Best

An executive may believe a team has room.

The people doing the work may know differently.

That does not mean teams below leadership get veto authority over strategy.

It means leadership should use their information.

Engineering leaders may know an initiative is more technically complicated than it appears.

Customer Success may know that a “small” customer change will create significant support requirements.

Sales may know that what appears to be one customer's request is showing up across the entire pipeline.

Finance may understand the capital consequences of adding people to solve the constraint.

Cross-functional decision quality improves when leadership gets information from above, below, and across the organization before allocating shared capacity.

The decision remains owned.

The intelligence should be broad.

Do Not Turn Capacity Negotiation Into Politics

Without a shared system, resource allocation can become political.

The most persuasive executive wins.

The function closest to the CEO gets priority.

The loudest customer drives the roadmap.

The newest opportunity receives disproportionate attention.

Executives learn that to protect their teams they need to overstate urgency.

That behavior compounds.

Soon every request is critical.

Every customer is strategic.

Every initiative is a top priority.

Nothing is actually prioritized.

Shared planning, visible objectives, explicit capacity, and clear ownership change the nature of the discussion.

Leaders no longer have to defend their importance.

They can evaluate the tradeoff against a shared organizational picture.

Functional Metrics Can Create the Wrong Decision

There is another subtle problem.

A leader may be behaving rationally against the metric they own.

The CRO wants the capability because it supports revenue.

The CTO resists because it threatens reliability.

The CPO prefers another capability because it supports product adoption.

The CFO wants to avoid additional hiring because of runway.

Every executive can be doing exactly what their function is measured to do.

That is why company-level outcomes matter.

Leadership teams cannot resolve cross-functional tradeoffs by asking each executive to maximize their own function.

They need a shared understanding of what the organization is trying to accomplish.

The company's result matters more than any one functional optimization.

Cross-Functional OKRs Can Turn Dependency Into Shared Work

This is one of the reasons I value cross-functional OKRs.

An important organizational outcome can have one clear owner while key results involve several functions.

For example:

Objective: Successfully launch the enterprise product.

Product owns a key result around requirements and roadmap.

Engineering owns delivery.

Marketing owns launch preparation.

Sales owns go-to-market readiness.

Customer Success owns implementation readiness.

The objective creates shared context.

The key results create visible contribution.

Peak's OKR model explicitly uses this kind of cross-functional structure: one objective can include contributions from Product, Engineering, Marketing, and Sales, with each part supporting the broader organizational outcome.

Now if Engineering capacity becomes constrained, leadership can see what organizational outcome is affected rather than treating the issue as an isolated engineering problem.

Use the Operating Rhythm to Catch the Tradeoff Early

Even good planning cannot predict everything.

Capacity changes during the quarter.

A hire leaves.

A technical issue appears.

A customer opportunity emerges.

An objective takes more work than expected.

That is why the operating rhythm matters after planning.

Weekly visibility helps teams see:

What is on course?

What is off course?

Where is one team waiting on another?

Which dependency is becoming a constraint?

What new priority has appeared?

Does this require a tradeoff?

Then Triage gives the team a place to resolve important issues instead of allowing them to create a chain of side conversations and emergency meetings.

A capacity conflict should become visible while the organization still has choices.

Not three days before a deadline.

Solve the Tradeoff at the Lowest Appropriate Level

Not every capacity disagreement belongs in the executive meeting.

If two teams can resolve a sequencing problem within their existing authority, they should.

If an objective owner can adjust a key result without materially affecting another company priority, they should.

If functional leaders can coordinate within the boundaries of the plan, they should.

Escalation becomes appropriate when the tradeoff changes company priorities, reallocates substantial shared capacity, changes an important customer commitment, requires authority the teams do not have, or materially affects another leader's outcome.

This is what healthy empowerment looks like.

The company does not centralize every decision.

It creates enough clarity that people know which decisions they can make and which decisions require broader organizational context.

Make the Decision, Then Let People Run

Once the tradeoff is resolved, leadership should resist repeatedly reopening it.

Everyone had input.

The relevant information was considered.

The appropriate owner made the decision.

Now the organization should commit.

That is a critical team behavior.

Strong leadership teams can disagree before the decision and still execute together afterward.

Without this discipline, the capacity conflict never really disappears.

The executive who did not get their preferred outcome continues lobbying.

Teams receive mixed signals.

Work gets started and stopped.

The CEO is asked to revisit the decision.

Execution loses momentum.

The goal of the tradeoff process is not merely to produce the right answer.

It is to produce enough clarity that teams can move quickly after the answer.

Capacity Conflicts Are Organizational Intelligence

There is another reason to track these tradeoffs.

They reveal where the organization itself may need to change.

If every major company priority depends on the same engineering team, that tells leadership something.

If Product repeatedly becomes the bottleneck between Sales and Engineering, that tells leadership something.

If hiring constraints continually block the plan, that tells leadership something.

If Customer Success is repeatedly absorbing consequences of commitments made elsewhere, that tells leadership something.

One conflict is a decision.

A pattern of conflicts may reveal a structural constraint.

The organization may need different roles.

More capacity.

A redesigned process.

Different sequencing.

Better planning.

A different decision-rights model.

A new capability.

This is where cross-functional tradeoffs become more than resource allocation.

They become organizational learning.

The Goal Is Not to Eliminate Cross-Functional Tension

A company with no cross-functional tension may not be making difficult enough choices.

Sales should push for customers.

Product should push for the right product.

Engineering should protect technical reality.

Finance should protect financial reality.

Customer Success should represent customer outcomes.

People should represent organizational capacity and talent.

Those tensions contain useful information.

The objective is not to remove them.

It is to create a system in which the tension produces better company decisions instead of functional conflict.

That requires shared direction.

Visible priorities.

Realistic capacity.

Clear ownership.

Explicit opportunity costs.

Defined decision rights.

Cross-functional coordination.

And an operating rhythm capable of revisiting assumptions as reality changes.

When those elements exist, leaders do not have to win against one another.

They can make the tradeoff together.

The question shifts from:

“Whose priority wins?”

to:

“Given what we are trying to accomplish as a company, where should our limited capacity create the most value right now?”

That is the question a Team-of-Teams needs to be able to answer as it scales.

Related Insights

What Is Peak OS?

What Is Organizational Execution?

What Is Organizational Intelligence?

What Is a Business Operating System?

What Is Operating Rhythm?