Two engineering teams in your program each insist their work has to come first, and both leads have dug in. You have no authority over either. How do you get to a decision?

Short answer

Convert a priority argument into a sequencing question with a stated cost, because two teams can both be right about importance while only one ordering is cheaper. Find the shared constraint, price each ordering against it, then take the residual disagreement to the one person who owns both.

The practical prioritisation test is whether the two teams disagree which work comes answer gives the interviewer something concrete to challenge.

The argument is almost never about importance

When two leads both say their work must come first, they are usually answering a question nobody asked. Importance is not the same as ordering, and a program does not need to know which workstream matters more; it needs to know which ordering finishes both for the least total cost. Those are different questions with different evidence, and the first is unanswerable while the second usually has one defensible answer.

So the first move is to stop the comparison of worth and ask what each team is actually competing for. In practice it is one of a small number of shared constraints: the same reviewer or architect, the same test environment, the same shared service that can only take one breaking change per release, the same integration window, or simply the same calendar quarter with a fixed headcount. Naming the constraint out loud changes the conversation, because two leads arguing about priority are cooperative the moment they understand they are both queueing for the same staging environment. The argument was never really with each other.

Price each ordering rather than each workstream

Once the constraint is named, both orderings can be costed, and the costing is the work that earns you the decision. The useful currency is delay to a committed outcome, not story points or team sentiment.

Laid out that way, the ordering stops being a matter of opinion. B first misses a fixed external date and A first does not, so A goes first even if B's work is more valuable in the abstract. That is the shape of the answer an interviewer is listening for: the decision falls out of a constraint that exists in the world rather than out of who argued more persuasively.

The table also exposes the cases where the answer is genuinely uncomfortable. If both orderings miss a commitment, then the honest finding is that the program is over-committed and no sequencing rescues it. Presenting that clearly is far more valuable than picking an order and hoping, and a TPM who cannot say "both cannot happen" is not doing risk management, they are doing scheduling theatre.

Escalate with a recommendation, and to the right person

If the two leads still disagree after the constraint and the costing are on the table, the disagreement is real and needs a decision-maker. The correct one is the lowest person in the organisation who owns both teams' outcomes, not the most senior person you can get a meeting with. Going higher than necessary is a common failure: it produces a decision that neither lead feels part of, and it teaches both of them that disagreeing with you gets them summoned to a VP.

What you bring to that person is a recommendation with the residual disagreement stated fairly, not a request for arbitration. Something close to this:

Both teams need the shared staging environment in the same three-week window. My recommendation is A first, because B's downstream dependency has three weeks of float and A's submission window closes on the eighth. B's lead disagrees on the grounds that his team then idles for two weeks; I have proposed the observability work as filler and he considers it low value. I need a decision on the ordering by Thursday to hold the environment booking.

That paragraph does four things at once: it names the constraint, gives the recommendation with its reason, represents the other position honestly rather than strawmanning it, and states the decision needed and by when. An escalation missing the last element is a complaint.

flowchart TD
    A[Two leads both claim<br/>first position] --> B[Name the shared constraint]
    B --> C[Cost both orderings<br/>against committed dates]
    C --> D{One ordering clearly<br/>cheaper}
    D -- Yes --> E[Decision falls out;<br/>confirm with both leads]
    D -- No --> F{Both orderings miss<br/>a commitment}
    F -- Yes --> G[Program is over-committed;<br/>surface scope decision]
    F -- No --> H[Escalate to owner of both<br/>with a recommendation]

Note the middle branch. The path most candidates never draw is the one where sequencing cannot fix the problem, and that is precisely the finding a program manager exists to produce.

Where this goes wrong afterwards

The failure that costs the most is treating the meeting as the end of the work. A decision the losing lead did not participate in tends to get quietly re-litigated through the plan: their team's estimates for the deprioritised work drift, the shared engineer keeps getting pulled back, and six weeks later you discover the original order is what actually happened. Buy-in is not politeness here, it is the mechanism by which the decision survives contact with two teams' daily choices.

The practical version of that is unglamorous. You tell the lead who lost the ordering what they get in exchange — an earlier slot next quarter, the environment booking guaranteed rather than contested, a named engineer freed up — and you write the decision down where both teams and both managers can see it, with the reason attached. The reason matters more than the decision, because the next time the constraint shifts, the written reason is what lets the ordering be revisited on evidence instead of re-argued from scratch.

A priority argument between two teams is usually a queue for one shared resource; find the queue and the ordering argues itself.

© 2026 Preptima. Originally published at preptima.com.