Handling Competing Priorities From Two Stakeholders

The worst version of this fight I ever refereed was between our Head of Risk and our VP of Sales, and it played out over a single field on a merchant onboarding form. Sales wanted the field optional so signups would convert. Risk wanted it mandatory so we could screen for a specific category of fraud we had been burned by twice. Both were right. Both had numbers. Both had my calendar booked for the next two weeks.

That is the real shape of competing priorities. It is rarely a clean disagreement about facts. It is two people who are each doing their job well, pulling the same limited engineering capacity in opposite directions, and both assuming you will eventually see that their side is obviously correct. Here is what I have learned about sitting in that chair.

Both People Are Usually Right

Early in a leadership career, the instinct is to treat the conflict as a puzzle with a hidden correct answer. Gather enough data, you tell yourself, and the truth will fall out and one side will stand revealed as mistaken. It almost never works that way in a healthy company. If two senior people are fighting hard over priorities, it is usually because both are optimizing for something the business genuinely needs, and the tension between those things is real and permanent.

Sales is measured on pipeline and close rate. Risk is measured on losses and regulatory exposure. Neither of those goals is wrong, and neither goes away if you win the argument today. The friction between growth and safety is not a bug in your org chart. It is the org chart working. Once I accepted that, I stopped trying to prove one stakeholder wrong and started trying to make the trade-off visible and deliberate instead of accidental.

Translate Both Asks Into One Currency

These arguments feel unwinnable because each side speaks a different language. Sales talks in conversion percentages and deal velocity. Risk talks in loss rates and audit findings. You cannot compare a 4 percent conversion lift to a 30 basis point increase in chargebacks until you force both into the same unit. For us, that unit is almost always money over a defined time horizon, plus a separate, explicit column for regulatory risk that money cannot buy back.

On the onboarding field fight, I asked both teams to put a number on it. Sales estimated the optional field cost them roughly 8 percent of completions, which at our volume was a real revenue line. Risk pulled the actual fraud we had eaten from that category over eighteen months. When we laid the two numbers side by side, the fraud exposure was about triple the revenue at stake, and that was before counting the regulator's likely reaction. The argument did not need me to adjudicate anymore. The numbers did most of the talking.

Say The Quiet Part Out Loud

A lot of priority conflict is really a conflict about who absorbs the cost of saying no. When you keep both projects nominally alive and just let engineering quietly starve one of them, you have not resolved anything. You have made a decision by neglect and let your team take the blame for the slippage. I did this for far too long once, keeping a Sales-driven integration and a Risk-driven monitoring rebuild both marked as "in progress" for a quarter, when in reality neither was getting enough attention to ship.

The honest move is to state the trade-off in plain words to both people, in the same room where possible. Something like: we are doing the monitoring rebuild first, the integration slips six weeks, and here is why. It feels worse in the moment. It is far better than the alternative, where both stakeholders think they are winning and then discover in eight weeks that they were both losing.

A priority you have not funded with real engineering hours is not a priority. It is a wish you have written down to avoid an uncomfortable conversation.

Look Hard For The Third Option, But Not Forever

Before you force a straight either-or, spend real effort looking for the design that gives both sides most of what they need. In the onboarding case, we landed somewhere neither had proposed: the field became conditionally required, triggered only for the merchant categories where the fraud actually clustered. Low-risk merchants saw a shorter form and converted fine. High-risk ones hit the screening. Sales recovered most of their conversion, Risk kept the coverage that mattered, and engineering built one rules check instead of two competing systems.

That kind of resolution is the best outcome, and it is worth genuine effort to find it. But I want to be careful here, because the search for a clever third option can become its own form of avoidance. If two days of whiteboarding has not produced a design that meaningfully serves both, stop. Some trade-offs are genuinely zero-sum, and dragging out the hunt for a magic compromise just delays the decision while both stakeholders lose confidence that anyone is actually in charge.

Anchor The Decision To Something Above Both Of Them

When the trade-off is real and you have to pick, the decision should not rest on which stakeholder is more persuasive or shouts louder in the meeting. It should rest on the company's stated priorities for the year. This is where a clear, written strategy earns its keep. If leadership has said this year is about defending margin and staying clean ahead of a licensing renewal, then a Risk ask that protects the license outranks a Sales ask that adds marginal top line, and everyone can see why without it feeling personal.

I insist on one thing: the tie-breaker has to be external to the two people in the room. "I decided" is a weak answer that breeds resentment. "Our number one goal this quarter is X, and this serves X" is a decision the losing side can actually accept, because you did not rank them as people. You ranked the work against a goal they both signed up for. If you do not have that shared goal written down, the priority fights are a symptom, and the real work is getting your leadership team to agree on what matters first.

Protect The Engineers From The Crossfire

Here is a failure mode I feel strongly about. When two stakeholders are fighting, they will each try to go directly to individual engineers to get their thing done faster, usually framed as a quick favor. One senior backend engineer of mine spent most of a sprint context-switching because both a Sales director and a Risk lead had been dropping into his DMs with "tiny" urgent requests. His actual assigned work stalled, and he was the one who looked unproductive in standup.

My job is to be the shock absorber. The engineers should feel the output of the prioritization decision, not the raw force of the argument. That means all the asks come through one intake, the roadmap is the single source of truth, and if a stakeholder wants to change priority they change it with me, not by lobbying a developer in a hallway. A few things I hold firm on:

• No priority is "in flight" until it has an owner, an estimate, and a place in the sequenced backlog that everyone can see.
• Urgent interrupts cost something visible: if we pull in your request, here is exactly what slips, named out loud.
• Engineers are allowed, and expected, to route side-channel requests back to me without guilt.
• The person who lost the prioritization call does not get to re-litigate it through a junior engineer's inbox.

Write The Decision And The Reasoning Down

Memory is a liar, especially under pressure. Three weeks after you make a hard priority call, both stakeholders will remember the outcome differently, and the one who lost will remember it as more arbitrary than it was. So I write a short decision record every time: what we chose, what we consciously did not do, the numbers we used, and the goal it laddered up to. Half a page, no ceremony.

This does two things. It stops the same argument from restarting every month, because the reasoning is on the record and if you want to reopen it you need new information, not just renewed enthusiasm. And it protects everyone when the decision turns out wrong, which some of them will. When a call I made on deprioritizing a fraud rule came back to bite us, the record showed we had weighed it deliberately with the data we had. That is a very different conversation with the board than one where it looks like nobody was steering.

Revisit On A Clock, Not On Emotion

The last piece is giving the losing side a real path back. A priority decision is a snapshot of what mattered on a particular Tuesday with particular numbers. Those numbers move. The Sales ask I deferred last quarter might be the obvious top priority this quarter once the licensing renewal is behind us. So I put the deferred item on a scheduled review rather than leaving its owner to wonder whether it is dead.

Telling someone "not now, and we look at this again at the start of next quarter with fresh data" is worlds apart from "no." It keeps their trust, it stops them from hoarding political capital to fight you again, and it means the person who was right-but-early actually gets their moment when the timing catches up. Most of the resentment I have seen from these fights comes not from losing but from feeling like the loss was permanent and unexamined.

Conclusion

If there is one thing I would tell my younger self about standing between two strong stakeholders, it is this: your value is not in being the smartest person about their domains, because you are not. Your value is in being the one who makes the trade-off explicit, ties it to something bigger than either ego in the room, funds it with real hours, and writes it down so it stays decided. The moment I stopped trying to make everybody happy and started trying to make the choice legible, the fights got shorter and the resentment mostly drained out of them. You will still be wrong sometimes. Just be wrong on the record, for reasons you can defend, and be quick to reopen the call when the numbers change.