Negotiation Strategy and Tactics Questions

Direct answer

Positional bargaining is when each side states a fixed demand ("we want $100,000", "we want this specific tool") and defends it, conceding step by step; the outcome is a split between positions. Interest-based negotiation looks behind the positions to the underlying needs, concerns and goals (the interests), and then looks for options that serve both. The distinction matters because positions are often incompatible while interests frequently are not, and because positional fights harm relationships and waste value.

Comparison

Worked example 1: a price negotiation

A buyer says: "I will pay $40 a unit." The supplier says: "The price is $50." Splitting at $45 is the positional answer. Asking "what is behind that number?" reveals interests: the buyer's budget is fixed and they want a reliable long-term source; the supplier wants predictable volume and cash soon after delivery. With those visible, a new option appears: the buyer commits to two years of volume and pays in 15 days instead of 60, and the supplier agrees to $44. Neither side's position was split; both interests were served, and the price moved because something else of value was traded.

Worked example 2: an architecture debate

Two engineering teams disagree about how to run a new service. Team A says: "We must use Kubernetes" (software that runs and manages many containers across servers). Team B says: "We must use serverless functions" (small pieces of code the cloud provider runs on demand, billed only while they run). These are positions, and a compromise ("half and half") would give a worse system than either.

Asking "what would that give you?" reveals interests:

• Team A: portability across clouds, control over runtime, existing platform skills.
• Team B: low operational burden (little ongoing maintenance work), scale to zero (no running cost when nobody is using it), fast delivery.

With interests visible, new options appear: containers on a managed serverless runtime (a cloud service that runs containers without anyone managing servers) that give portability and low operations, or serverless for event-driven parts and Kubernetes for long-running services (programs that stay up all the time), decided against shared criteria (operating cost, on-call load meaning how often engineers are woken to fix problems, and time to deliver). The debate moves from who wins to which option best meets the interests.

How to move from positions to interests

1. Ask "why is that important?" and "what would that let you do?"
2. Acknowledge the interest before offering an option.
3. Separate inventing options from deciding.
4. Test options against objective criteria (cost, risk, benchmarks), not authority.

Trade-offs and pitfalls

• Interest-based does not mean soft: you still advocate for your interests and need a BATNA (best alternative to a negotiated agreement: what you would do if no deal is reached, which tells you when to walk away).
• On a pure single-issue price fight there is little to expand; positional tactics are unavoidable there.
• Sharing interests exposes you; share the ones that unlock value, not your bottom line.

Direct answer

I would not walk in with "no". (Terms used below: cost of delay is the money lost for each week the launch slips; margin is revenue minus the direct cost of serving it; a feature flag is a switch in the code that turns a feature on for chosen users only; rollback means switching the feature off again; a post-mortem is the written review after an incident; risk acceptance is a written statement that a named person knowingly accepts a stated risk.) I would bring a one-page plan that shows the sponsor what the date risks in numbers, offers three or four options that protect the date's real purpose, and asks for a decision. The plan has four parts: the data (defects, test coverage, known risks), the cost of each option, a recommended option, and the trigger that would change my recommendation. My recommendation will usually be a staged release: hold the date for a reduced scope or a limited audience, and move full launch behind explicit quality criteria.

What I bring

Data: open defects by severity and trend, test coverage on the critical path, performance and load-test results against the target, security and compliance gaps, and a short list of the three failures that would hurt most. I show the evidence, not an opinion.

Why the date matters: I ask what the date protects (a customer commitment, a conference, a competitor, a quarter-end). A date tied to a real external constraint is treated differently from a number in a plan.

Options:

Worked example (illustrative figures)

Delay of 3 weeks costs 30,000 USD of margin per week, so 90,000 USD. Shipping on the date with a 30 percent chance of a serious incident costing 250,000 USD (support, credits, rework, lost renewals) has an expected cost (probability times cost) of 0.30 x 250,000 = 75,000 USD, before counting reputational damage. Looked at only like this, the two options are close, so I do not argue the number; I show the staged rollout.

Staged rollout, built the same way:

• Incident size: with only 5 percent of users on the feature, I assume the damage scales with the number of users exposed, so a serious incident costs about 5 percent of 250,000 = 12,500 USD, and the flag lets us switch it off before it spreads.
• Expected incident cost: the probability stays 30 percent, so 0.30 x 12,500 = 3,750 USD.
• Slower ramp: widening from 5 to 100 percent of users takes about 2 weeks, with average coverage of about two thirds, so about one third of 2 weeks of margin is deferred: 2 x 30,000 x (1/3) = 20,000 USD. The two thirds assumes a front-loaded ramp (for example 5 percent for the first days, then 50, then 100). A straight-line ramp from 5 to 100 percent averages about 52 percent, so about 28,500 USD is deferred and the total becomes about 32,250 USD, still the cheapest of the three.
• Total expected cost: 3,750 + 20,000 = 23,750 USD, against 75,000 (ship as is) or 90,000 (delay). That keeps most of the date's value and is a number the sponsor can accept.

The result is most sensitive to the incident probability and the "damage scales with users" assumption, so I say clearly where each estimate comes from and what would change it.

Reframing and related cases

• Security controls (sales leader wants it now): I show the exposure: the customer it protects, the contract clause it would breach, the cost of a disclosed incident versus the cost of a short delay. For example, a 2-week delay costing 60,000 USD of margin against a contract clause with a 200,000 USD penalty if a breach is disclosed.
• Skipped refactor: I quantify the long-term cost. For example, skipping a 30 engineer-day refactor saves 30 days now, but the workarounds cost 6 engineer-days every month, so the shortcut costs more than it saved from month 6 onward (6 x 5 = 30 days at the end of month 5).
• Compressed compliance deliverable (scope versus safety): I cut scope to the compliant core and refuse to cut the safety, since a launch with a compliance gap carries unlimited downside.
• Engineering later versus product earlier: I reframe it from a dispute between teams to a shared risk with a shared decision: "what is the smallest launch that we are both willing to defend in the post-mortem?"

How I handle the conversation

I open with their goal: "I want you to hit this date with something we are proud of. Here is what the data says, and here are the options." I let the sponsor choose between options, and record a risk acceptance in writing if they pick A, so the decision belongs to the person who owns the outcome.

Pitfalls

• Arguing quality in the abstract without evidence.
• Offering only "no" or only "yes".
• Letting the sponsor's date harden into a promise to customers before the plan is agreed.
  My recommendation changes if the date is tied to a hard external deadline with a penalty larger than the incident cost, in which case I choose reduced scope with a tight rollout.

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

I would make it easy and valuable for the other team to say yes: explain the decision the data supports and why it matters to their goals too, shrink the request to the smallest change that works, offer to do part of the work myself, and agree a date. In the meantime I would use clearly labelled temporary measures so my work is not blocked. Escalation comes last, and only about priority, not about blame.

Step 1: understand their side

Ask: "What is on your plate, and what would make this cheap for you?" Common reasons for reluctance are a full backlog, no benefit to them, privacy or performance worries, or unclear requirements. Each needs a different response.

Step 2: make the ask precise and small

Write a ticket they can pick up without a meeting: which events or fields, where they fire, naming, example payload, and acceptance test. A vague "please track engagement" will wait forever; "emit event checkout_started with user id and cart value when the checkout page loads" will not. State the cost in their terms, for example "about one engineer-day, one release".

Step 3: lower their cost and raise the value

• Offer to do the work: open the pull request (a proposed code change) myself, following their conventions, so they only review.
• Bundle: align it with a release they already have.
• Share the benefit: show how the data will help them (a dashboard of their feature's usage).
• Trade: offer something they need in return, such as analysis for their roadmap.

Step 4: temporary heuristics in the meantime

While waiting, use a proxy: infer the behaviour from existing logs or server requests, sample manually, or take a rough estimate. Label it clearly as provisional ("estimated from page loads, accuracy about plus or minus a few points, to be replaced"), and set a removal date. This protects the project without pretending the proxy is the real measure.

Example exchange

Me: "I need checkout drop-off by step. I wrote the spec and a draft change; it is about one day for your team to review and ship. In return I will give you the funnel for your own roadmap. Can it go into the next release?"
Them: "We are full this sprint."
Me: "Then can it go in the sprint after, and I will use a log-based proxy until then?"

Escalation

If still blocked, go to the managers jointly: "Here is the impact of the delay and the options. Can you help us agree a priority?" Not a complaint, a decision request.

Pitfalls

• Do not go around the team without telling them.
• Do not let a temporary proxy become permanent; track the replacement.
• Check privacy and performance concerns early; they are legitimate reasons for delay.