You are embedded at a customer and two of their stakeholders want incompatible things from what you are building. Neither of them is your manager. How do you get unstuck?

Short answer

Stop negotiating between opinions and get the disagreement written down as two named decisions with their consequences, then push it to whoever owns the budget; as an outsider your leverage is that you can make the conflict visible without being a party to it.

Embedded delivery matters here because the two customer stakeholders want incompatible things answer has to show the boundary, not just the happy path.

You have no authority, which is the whole problem and also the solution

An embedded engineer sits outside the customer's reporting lines. Nobody in the room reports to you, you cannot break a tie, and you cannot make either person's objection go away by outranking them. Candidates who have only worked inside a single organisation tend to answer this question with tools they no longer have: they propose a decision, they call a meeting to align, they suggest the two stakeholders compromise. All of that assumes standing you do not possess.

What you do have is a position nobody inside the organisation occupies. You are not competing with either of them for headcount, promotion or credit, you can be seen talking to both without it meaning anything politically, and you can say "I need a decision to keep building" as a statement of fact rather than as a manoeuvre. That neutrality is a genuine asset and it is the only one you have, so the tactics that spend it — quietly building what one of them asked for, agreeing with whoever is in the room — are the tactics to avoid.

First check whether the conflict is real

A surprising share of apparent stakeholder conflicts are two people using the same words for different things, or different words for the same thing. The operations lead wants "the daily numbers by 7am" and the finance lead wants "figures reconciled to the ledger", and these sound incompatible because one implies speed and the other implies a close process. They are often satisfiable at once by producing an early provisional figure and a later reconciled one, clearly labelled. Nobody had spotted that because the two had never described their requirement in the same sentence, and inside their organisation there was no neutral party who spoke to both.

So before treating it as arbitration, restate each position back to its owner in the other's vocabulary, and specifically ask each what breaks for them if the other version ships. The answers are frequently different in kind — one is a regulatory obligation, the other is a preference about presentation — and a difference in kind resolves itself without anyone conceding.

Make the disagreement a written decision with a price

When the conflict is real, the useful move is not to resolve it but to convert it from a difference of opinion into a decision with an owner, a date and a stated cost. Verbal disagreements can persist indefinitely because neither party pays for the delay. A one-page note that says "we are blocked pending a choice between A and B; A costs roughly this and forecloses that; B is available sooner but cannot support the audit case; we need an answer by Thursday or we will proceed with A" cannot persist, because now the delay is visible and attributable.

Written for the customer, that note looks like this:

Decision needed by: Thursday 21st
Owner: Head of Claims Operations (budget holder for this engagement)

Option A - per-adjuster queue (requested by Operations)
  Ships in this sprint. Cannot produce a portfolio-level view without
  a second data model later. Rework cost if reversed: ~2 weeks.

Option B - portfolio view first (requested by Risk)
  Two sprints. Adjusters keep their current spreadsheet until it lands.
  Reversible: the queue view can be added on top of this model.

Consequence of no decision: I build A on Friday, because idle weeks
are the one option that helps neither of you.

The last line matters more than the options. A default that takes effect on a date converts an open argument into a deadline, and it is honest rather than coercive: you are telling both parties what will happen if they do not act, in time for them to act.

Route it to whoever pays, not whoever is loudest

Decision rights in a customer organisation rarely match the org chart you were shown in week one. The person who signed the engagement is a reliable starting point, because their money is what stops if you stall, and their interest in the answer is therefore structural rather than political. Ask them, in advance of needing it, a question most engineers never ask: when two of your teams disagree about what I should build, who decides? Getting that answer while nothing is contested is worth several weeks later, and it is the single most useful piece of information you can gather in your first fortnight on site.

Escalating is not tattling if you do it in the open. Tell both stakeholders you are writing the trade-off up and sending it to the sponsor, show them the note before you send it, and invite them to correct their own option's description. Almost nobody objects to an accurate account of their own position, and the act of getting them to check it often produces the compromise on its own.

Picking a side quietly is the failure that ends the engagement

The tempting shortcut is to build what the more available, more enthusiastic or more technically credible stakeholder asked for and hope the other never notices. It fails predictably, and it fails late: the work lands, the excluded stakeholder sees their requirement absent, and they now have both a grievance and a reason to discredit the whole engagement. Because you are an outsider, you are the cheapest thing in the room to blame, and the argument that you were only doing what you were told does not survive the discovery that you knew there was a disagreement.

The related failure is the opposite: building a hedge that satisfies both descriptions and neither purpose. A configurable version of both options, a report with every field on it, an abstraction that defers the choice — these look diplomatic and they mean you have shipped the disagreement into the codebase, where the customer's own team will maintain it long after you have gone.

Your job is not to resolve the customer's internal disagreement. It is to make it cost something visible, on a date, to the person who can end it.

---

© 2026 Preptima. Originally published at preptima.com.