Negotiation Strategy and Tactics Questions

Direct answer

Pick one real story where engineering and product genuinely wanted different things, and tell it in the standard behavioural-interview shape (Situation, Task, Action, Result, often called STAR, plus a reflection): the competing priorities and why each was reasonable, what I did to understand both sides, the specific compromise and what each side gave up, and the result including what I would do differently. Honest numbers from the real event matter more than a flattering outcome. Below is a shape to follow, using an illustrative example that you must replace with your own facts.

Story shape

1. Situation (2 sentences): the product, the pressure, the two positions.
2. Task: your role in resolving it.
3. Action (the core): how you found the interests, the options you offered, how you decided.
4. Result: what shipped, what was deferred, what was measured.
5. Reflection: one lesson.

Illustrative example (replace with a real one)

Situation. Product wanted to launch a recommendation feature in six weeks to meet a market window. The machine learning engineers wanted ten weeks to improve model robustness (how well it holds up on unusual inputs) before exposure to users.
Task. I was the engineering lead accountable for the launch decision and had to get both teams to a plan they would each defend to their own management.
Action.

• I asked each side for the specific risk: product feared a competitor launching first; engineering feared poor recommendations hurting trust.
• I turned that into a test: which failures were acceptable and which were not.
• I proposed launching in six weeks to 10 percent of users with a fallback to simple rules when the model's confidence (its own score of how sure it is) was low, with a robustness target to hit before expanding to everyone.
• Product gave up the full launch date; engineering gave up the full ten-week hardening.
• We agreed the expansion criteria in advance: an error-rate threshold (the maximum share of bad recommendations allowed) and a review date.
  Result. Say what really happened: whether the limited launch hit the window, what the monitoring showed, and when the full rollout happened. Give measured outcomes only if you have them; if you do not, describe the qualitative outcome honestly. A finished version might read: "We launched on day 42 to 10 percent of users. In the first two weeks the fallback rules handled about a fifth of requests, which we had not expected, and we found one segment where recommendations were poor. We fixed it, hit the agreed error-rate threshold in week 9, and went to 100 percent in week 10. Product got the market window; engineering got its hardening, just later." These figures belong to the example only; use yours or say you did not measure.
  Reflection. Agreeing the rollout criteria up front stopped the debate from recurring.

A second angle: matching scope to data or compute limits

The same story shape works outside machine learning: a BI analyst might launch a dashboard for the two regions with clean data first, and a PM might ship to one customer tier while a reliability fix is finished. The pattern is a narrower first release, an agreed bar for widening it, and a date to review.
If the conflict is about what the data or compute can support, show how you aligned the scope to it: for example, narrowing the first release to the segments with enough data, or using a smaller model that fit the compute budget, and stating that the broader scope depended on collecting more data. This shows the compromise came from evidence, not opinion.

What makes it strong

• Both sides' reasons are fair; neither is the villain.
• The compromise is specific and each side gave something real.
• There is an agreed check afterwards.
• You say what you would change.

Pitfalls

• Do not claim a perfect win; interviewers distrust it.
• Do not invent precise metrics; if you did not measure it, say so.
• Do not make yourself the hero; credit the team.

Direct answer

I would use an interest-based approach, which means negotiating over the underlying need (the interest) rather than the stated demand (the position). A position is "we cannot migrate this quarter"; the interest might be "we must hit a quarterly target and cannot absorb unplanned work." I understand why each team resists (their commitments and what they fear losing), separate what is non-negotiable from what is tradeable, and offer concessions that cost me little but matter to them: timing, migration help, exceptions with an end date, and shared credit. Authority and escalation are the last tool, not the first. The result should be a repeatable process, not a one-off deal.

Step 1: map the teams

For each team write: their current commitments, what the change costs them, what they gain, who decides, and their trust in me. Resistance is usually rational: a team with a quarterly target will resist work that does not count towards it.
Filled-in example for one team: Payments team. Commitments: PCI audit due in six weeks. Cost of change: about 15 engineer-days of migration. Gain: none this quarter. Decider: their director. Trust in me: low, we have not worked together. That row tells me to offer migration help and a date after the audit, and to reach the director through the team lead first.

Step 2: fix the non-negotiables

Decide up front what cannot move (a security fix, a legal requirement, the end state of the standard) and what can (sequence, date, approach, support). Say so openly: "The goal is fixed. The route and date are open."

Step 3: concessions I might offer

• Timing: align the change with each team's quiet period.
• Help: my engineers do the migration or provide a compatibility layer (a thin piece of code that lets their old interface keep working with the new standard).
• Time-limited exemption: an approved exception with an expiry date and owner.
• Credit: count the work towards their goals, or share the outcome publicly.
• Reciprocity: support for something they need.
  Ask in return: a date, a named contact, participation in a design review.

Variations

Example

Team lead: "We cannot migrate this quarter."
Me: "I understand. What if my team does the migration for your two services, and you review and own it from there? We would aim for the next quiet period."
Team lead: "That could work if it lands after our audit."
Me: "Agreed. In return, can you name a contact and join one design review next month, and we confirm the date in writing today?"

Pitfalls

• Do not promise a concession you cannot fund.
• A concession should not undermine the goal; exemptions without end dates become permanent.
• Escalating before listening costs goodwill that you will need again.
• If resistance is concentrated in one team, handle them one to one before any group meeting, so no one loses face in public.

Direct answer

When someone presses for the lowest headline price but keeps talking about fast user growth, the growth is probably the real interest and the price is a proxy for "I need to afford growth." I would test that with a few open questions, then offer a structure that makes the starting price low and ties our revenue to their growth, so we both benefit when they succeed.

Working out what they really need

Questions I would ask (a short script):

• "You have mentioned growth a few times. What does success look like in twelve months, in users?"
• "What is the cost that worries you most: the first-year fee, or the cost as you scale?"
• "What happens if growth is slower than planned? And if it is faster?"
• "Who else needs to be comfortable with this number: finance, product, legal?"

I listen for: a budget cap this year, uncertainty about growth, a board target, and cash constraints. I then repeat it back and check: "So the priority is a low first-year commitment, and a price that does not punish you for growing. Is that right?"

How it changes the offer

Instead of cutting a flat fee, I offer a platform fee plus usage structure (illustrative). A flat fee of $240,000 per year compares with $60,000 platform fee plus $0.60 per monthly active user (MAU, a user active in a month):

$\text{annual cost} = 60{,}000 + 0.60 \times \text{MAU} \times 12$

At 20,000 MAU the headline cost is 15% lower than the flat fee ($36,000 of $240,000), which answers "lowest headline price". The break-even is 25,000 MAU, because $60,000 plus $7.20 times 25,000 equals $240,000. If they grow, we earn more, which is why we can afford to start low. The assumption the result is most sensitive to is their growth: if they stay at 10,000 MAU we earn $132,000, below the flat fee, so I would add a minimum annual commitment as a trade for the lower start.

I could also add growth-supporting items that cost us less than they are worth to them: onboarding help during launch, a volume tier that lowers the rate once they pass a user count.

The multi-party angle

Buyers rarely decide alone. Product wants growth, finance wants a low and predictable cost, legal wants risk limits. I map each stakeholder's interest, then build a package that gives each something: a usage-based price (finance gets low entry cost, product gets room to grow), a cap on annual increases (finance predictability), and clear data and liability terms (legal). I ask the champion (my internal supporter at the buyer) to test the package with each function before the next meeting.

Trade-offs and pitfalls

• Usage pricing can make their bills unpredictable; a cap or committed tier helps.
• If the growth talk is only posturing and price really is the only issue, my probing will show that; then I trade price for term and prepayment.
• Do not assume the interest; test it, or I may redesign the offer around a guess.

Direct answer

I would write a one-page request that states the business outcome, the exact ask (two named skill profiles for six weeks), the cost of not doing it, and what the lending teams lose, then take it first to the owner of the shared pool and the managers of the people I want, before anyone is surprised in a meeting. The ask is easier to approve when the lender sees a small, dated, reversible loan with a clear payback.

Who to engage and in what order

1. The pool or resource owner (often an engineering director or resource manager): the person who can say yes.
2. The managers of the specific engineers, because they know the real current load and any hidden commitments.
3. My sponsor (the senior executive who cares about the outcome and will back the priority), to back the priority if there is conflict.
4. A finance or planning partner, if headcount or cost is tracked.
5. The engineers themselves, once approved, so they commit willingly and know the plan.

The request, as I would write it

• Outcome: what the six weeks delivers and the date it matters (for example, a launch tied to a customer commitment).
• Ask: 2 engineers, 6 weeks, with the skills needed (name them), start date, and a check-in at week 3.
• Size: 2 x 6 = 12 engineer-weeks. At an illustrative $4,038.46 per engineer-week (a $210,000 loaded annual cost, meaning salary plus benefits, tools and overhead, divided by 52), that is 12 x $4,038.46 = $48,462 (using the rounded $4,038 gives $48,456; the difference is rounding).
• Value: the cost of delay is what each week of lateness costs the business. Derive it from inputs you can ask for: product or finance for the revenue the project unlocks per week (or the penalty or customer commitment at risk), and sales for deals waiting on it. Illustratively, if each week of delay costs $25,000 in lost or deferred revenue, six weeks of delay is $150,000, and $150,000 / $48,462 = 3.1, about three times the loan cost. Say clearly that this input is an estimate and show the range (for example $10,000 to $40,000 a week gives $60,000 to $240,000).
• Give: what the lender gets back (a handover of documented work, priority support later, a shared win) and what is the lowest-impact period to lend from.
• Fallback: if two engineers is impossible, one engineer for 12 weeks or one engineer plus a contractor, with the later date stated.
• Risk: what happens if the loan runs over, and the stop rule (a pre-agreed trigger, such as "if week 3 shows less than half the milestones done, the engineers return to their teams").

Opening line

"I am asking for a loan, not a transfer: two engineers for six weeks, back on the dates you choose. Here is what it protects and what it costs, and here are two smaller versions if this one does not fit."

Related case: a compliance programme needing more engineers and three more months

Treat it as a deadline-driven ask. Separate the fixed external date (a regulator or audit window) from the internal plan. Show the scope that must be done by the fixed date versus what can follow, ask for the extra engineers against that must-do scope, and quantify the exposure of missing it (fines, audit findings, lost deals). If the date is fixed, the negotiation is about what else gives way, not about whether to do it.

Trade-offs and pitfalls

• Do not ask for more than needed and expect to be cut; cut the ask to what the outcome requires.
• Do not go around the managers to the executive first; it burns trust.
• Name the displaced work; lenders resent hidden costs more than visible ones.

Direct answer

Scarce compute is a negotiation over how to use a shared resource, so I would come with a precise, small, time-boxed request, evidence that it is worth it, and ways to reduce the platform team's pain: off-peak running, preemptible jobs (jobs that can be paused or bumped when higher-priority work needs the machines, then resumed) and staged use. I recommend a staged ask in place of one big reservation, because it earns trust and reduces how much the platform team must give up at once.

Prepare the request

Define it in units the platform team uses. Example (illustrative): the full plan needs 32 GPUs (graphics processors used for training) for 14 days. That is 32 x 24 x 14 = 10,752 GPU-hours, from a pool of 128 GPUs, so 25 percent of the pool for two weeks. Write also the expected output (a trained model or a benchmark), the date it matters, and the cost of delay.

Make it smaller and cheaper to say yes to

The conversation

"I am asking for a share, not for exclusive control. Here is the plan, the first 576 GPU-hours to prove it works, and the conditions under which I would release the capacity back. What would make this easier for your team to support?"
Listen for the platform team's constraints: other teams' commitments, reliability targets (uptime and job-completion promises they have made), cost limits. Then adapt the schedule.

The allocator's view

If I were the one deciding between two teams wanting the same capacity, I would want a fair policy, not a favour: a priority rule that weighs business value per GPU-hour and deadlines, guaranteed baseline quotas per team (a floor each team can always use), burst capacity (spare headroom lent out for urgent work), preemptible low-priority queues, and transparent usage reporting. The first two matter most: the rule and the floor. For example, if Team A's request is 10,752 GPU-hours for a launch worth $400,000 and Team B's is 4,000 GPU-hours for an experiment with no date, the one-page case lets me compare value per GPU-hour (about $37 versus unknown) and a deadline, not who argues harder. Ask each team for the same one-page case so decisions compare like with like, and publish the outcome.

Trade-offs and pitfalls

• Asking big then bargaining down damages trust; ask for what you can justify.
• A promise to release capacity must be honoured, or the next request will fail.
• If phase 1 shows the plan needs less compute than expected, say so promptly; that builds credibility.
• What flips my call: a hard external deadline with high cost of delay justifies requesting the full block and escalating through a sponsor.