Negotiation Strategy and Tactics Questions

Direct answer

My own commitments to clients can only be as good as the vendor's commitments to me, so I insist on service-level agreement (SLA, the contract's availability promise with remedies) terms that let me pass service quality through: an availability figure high enough that my combined promise is achievable, a clear definition and measurement, credits and termination rights that are meaningful relative to what I owe my clients, and transparency on incidents. I then trade volume, term length and payment structure for those terms, and I would not trade away the termination right or the measurement definition for a lower price.

Terms I insist on

1. Availability commitment sized to my promise. My availability multiplies with the vendor's, so the vendor must deliver more than I promise my client (see the numbers below).
2. Clear definition and measurement: what counts as downtime, where it is measured, and who has the data. A vendor-measured status page (the vendor's own public page of uptime) alone is not enough; I want access to logs or the right to dispute.
3. Credits and caps that scale with severity, with the cap high enough to matter.
4. Termination for chronic failure and a right to exit early without penalty.
5. Incident handling: notification within a stated time, a root cause analysis (a written explanation of what failed and why) within a stated period, named escalation contacts.
6. Support response targets and recovery objectives (RTO, recovery time objective, how long to restore; RPO, recovery point objective, how much data loss is tolerable).
7. Change notification and data export so a forced migration is survivable.

Worked example (illustrative figures)

I operate my part at 99.98 percent and promise my client 99.95 percent. The vendor commits 99.9 percent. My client pays 120,000 USD a month with a 5 percent credit at the first tier; the vendor charges 40,000 USD a month with a 10 percent credit at its first tier. A credit is a discount on the next invoice paid when the availability promise is missed, and the first tier is the mildest miss threshold. My client's service depends on my part and the vendor's part both working, so the two availabilities multiply: combined = own x vendor. To keep my promise I need own x vendor >= promise, which rearranges to vendor >= promise / own.

own = 0.9998          # availability of the part you operate yourself (illustrative)
promise = 0.9995      # what you promise your client
needed_vendor = promise / own
print(f"vendor must deliver at least {needed_vendor*100:.3f}% for a {promise*100:.2f}% client promise")

MIN = 30 * 24 * 60
vendor_sla = 0.999
print("combined with a 99.9% vendor:", round(vendor_sla * own * 100, 3), "%",
      "->", round(MIN * (1 - vendor_sla * own), 1), "min downtime/month")

vendor_fee, client_fee = 40_000, 120_000
vendor_credit = 0.10 * vendor_fee      # tier-1 credit we would receive
client_penalty = 0.05 * client_fee     # tier-1 penalty we would owe
print("vendor credit", vendor_credit, "vs penalty we owe", client_penalty, "gap", client_penalty - vendor_credit)

p_miss = 0.10   # assumed chance of a tier-1 miss in any month (illustrative); expected value = probability x credit
print("expected monthly credit value:", p_miss * vendor_credit, "= price cut of", p_miss * vendor_credit / vendor_fee * 100, "%")

Output:

vendor must deliver at least 99.970% for a 99.95% client promise
combined with a 99.9% vendor: 99.88 % -> 51.8 min downtime/month
vendor credit 4000.0 vs penalty we owe 6000.0 gap 2000.0
expected monthly credit value: 400.0 = price cut of 1.0 %

Reading it: the division works because 0.9998 x 0.9997 = 0.9995, so 99.97 percent from the vendor is the least that still lands on my 99.95 percent promise. The vendor must deliver at least 99.97 percent for me to keep a 99.95 percent promise, but a 99.9 percent vendor commitment gives a combined 99.88 percent, about 51.8 minutes of downtime a month. The vendor's credit (4,000 USD) is also smaller than what I would owe my client (6,000 USD) at the first tier, so I carry a gap of 2,000 USD each time both credits fire. That is the best case: the vendor's credit triggers only if it misses its own 99.9 percent commitment, so a vendor running exactly at 99.9 percent (combined 99.88 percent, below my 99.95 percent promise) pays me nothing while I still owe my client 6,000 USD. This is why the availability figure has to be fixed before the credit size. I either ask for credits that track my downstream exposure, or I promise less to my client. In the room: "My client's first-tier penalty to me is 6,000 USD a month, so a first-tier credit of 4,000 USD leaves me carrying the difference. Can we raise the first-tier credit to 15 percent, which is 6,000 USD, or commit to 99.97 percent?"

How I trade

• I give: a longer term, a volume commitment, an earlier payment schedule, a reference.
• I get: a higher availability tier, a higher credit cap, a termination right, better incident terms.
• Credits versus price: a vendor may offer a lower unit price in exchange for weaker credits. Expected value is probability times amount: a 10 percent chance of a 4,000 USD credit is worth 0.10 x 4,000 = 400 USD a month on average, which I compare with a certain price cut because both are what the vendor gives me each month in the long run. With the assumed 10 percent chance of a first-tier miss, the expected credit is 400 USD a month, equal to a 1 percent price cut of the 40,000 USD fee, so a price cut above 1 percent that does not weaken my termination right is a good trade, but I would never trade the termination right. The conclusion is sensitive to the miss probability, so I use the vendor's actual history.
• Payment structure and volume discounts: volume discounts are fine if they do not lock me in; I prefer a ramp, with early-termination terms that let me exit if the service fails, and credits that apply automatically.

Aligning objectives and leverage

I set my own internal availability target (service-level objective, SLO) stricter than my client promise, and I ask the vendor to commit to a matching SLO and a joint review (a regular meeting where both sides go through measured performance and open incidents). If the vendor resists change, my leverage is a credible alternative: a second vendor, a multi-vendor design or an in-house fallback. I would prepare that alternative before the call, because its presence moves the vendor more than any argument.

Pitfalls

• Accepting credits as the only remedy: credits compensate, they do not restore service.
• Ignoring exclusions (the list of events that do not count as downtime): planned maintenance, "emergency" maintenance and third-party failure can be written to swallow the SLA.
• Promising my client more than the vendor chain permits.

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.

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.

Direct answer

I treat it as a negotiation about interests, not dates: the two weeks is Product's position, six weeks is Engineering's estimate, and neither is the real interest. I would find out why two weeks (a customer demo, a contract promise, a competitor) and what the minimum useful outcome is, then offer options that change scope, sequence or risk, and agree the plan in writing with acceptance criteria.

Key negotiation points

1. What is driving the date? A hard external deadline is different from a preference.
2. How confident is the estimate? Ask Engineering for a range and the biggest unknown, not one number.
3. What is the minimum viable subset of each feature that delivers the outcome? Agree acceptance criteria for each in words a tester can check.
4. Technical debt: if shortcuts are taken, say what they are, write the paydown ticket, and agree when it will be done, so debt is a conscious loan. A shortcut is, for example, hard-coding a value that should be configurable, or skipping automated tests for a feature: it ships sooner but every later change to that code costs more, like interest. The paydown ticket would read "add tests and make the value configurable, 3 days, scheduled for the sprint after launch."
5. Capacity: adding people late rarely speeds up a project (onboarding and coordination cost); check what other work competes.
6. Who decides trade-offs if the plan slips? Agree in advance.

Options on the table (illustrative estimates: F1 = 1.5 weeks, F2 = 2 weeks, F3 = 2.5 weeks, total 6)

Check: 1.5 + 0.5 = 2 weeks; remaining F2 is 1.5 weeks, so 2 + 1.5 = 3.5; then F3 2.5 gives 6. The numbers add up to the original six weeks, so Option B gives early value without pretending the total effort shrinks.

How we reach agreement

In the conversation: "Help me understand what happens on day 14 if only feature 1 is live." If the answer is a demo to one customer, Option B or C probably satisfies the interest.
PM: "We need all three on day 14."
Engineering lead: "All three is six weeks. What does the customer need to see?"
PM: "Feature 1 working, and some sign that 2 and 3 are coming."
Engineering lead: "Then feature 1 plus the core of feature 2 by day 14, rest of 2 at week 3.5, feature 3 at week 6. Can you accept that and a re-estimate after week 1?" I would recommend B if the deadline is real and C if the thin versions still meet the goal. Then I write up a half-page plan: features and acceptance criteria per milestone, the debt ticket, a checkpoint at the end of week 1 to re-estimate, and the named owner who may change scope.

A lightweight framework for any product-versus-engineering trade-off

Ask four questions: (1) what outcome and by when, and why? (2) how sure are we of each estimate? (3) what can be cut, sequenced or staged? (4) what risk are we accepting, and who signs for it?

Trade-offs and pitfalls

• Agreeing to the date and quietly absorbing the gap damages trust the next time estimates are given.
• Splitting the difference (4 weeks) without changing scope just creates a different missed date.
• If the two-week date is a promise to a customer with penalties, the conversation changes: scope or resources must move, and leadership may need to decide.

Direct answer

I would first make the number concrete, because 99.999 percent sounds like a label but means about 26 seconds of downtime per 30-day month. Then I would be honest that no provider can commit to that on dependencies it does not control, show what each availability level costs, and propose a structure that meets the real business need: a tiered commitment by service component, a measurement and credit regime with a cap, and a path to a higher level if the customer funds it. The commitment I sign has to be one I can keep: an SLA (service-level agreement, the contractual availability promise with remedies) I will probably breach is neither honest nor commercially workable.

Step 1: make the number concrete

MIN_PER_MONTH = 30 * 24 * 60  # 43,200 minutes in a 30-day month

for target in (99.9, 99.95, 99.99, 99.999):
    allowed = MIN_PER_MONTH * (1 - target / 100)
    print(f"{target}% -> {allowed:.2f} min ({allowed*60:.0f} s) of allowed downtime per 30-day month")

# Components in series: a request needs every one of them up at the same moment, so availabilities multiply.
print("three 99.99% services in series:", round(0.9999 ** 3 * 100, 4), "%")

# A service credit is a discount on the next invoice, paid when measured availability misses the promise.
# Tiers: below 99.95% earns 10%, below 99.9% earns 25%, below 99.0% earns 50% of the monthly fee.
def credit_pct(measured):
    if measured < 99.0:  return 50
    if measured < 99.9:  return 25
    if measured < 99.95: return 10
    return 0

fee = 50_000
for measured in (99.97, 99.93, 99.6, 98.5):
    print(f"measured {measured}% -> credit {credit_pct(measured)}% = {fee*credit_pct(measured)/100:,.0f} of a {fee:,} monthly fee")

Output:

99.9% -> 43.20 min (2592 s) of allowed downtime per 30-day month
99.95% -> 21.60 min (1296 s) of allowed downtime per 30-day month
99.99% -> 4.32 min (259 s) of allowed downtime per 30-day month
99.999% -> 0.43 min (26 s) of allowed downtime per 30-day month
three 99.99% services in series: 99.97 %
measured 99.97% -> credit 0% = 0 of a 50,000 monthly fee
measured 99.93% -> credit 10% = 5,000 of a 50,000 monthly fee
measured 99.6% -> credit 25% = 12,500 of a 50,000 monthly fee
measured 98.5% -> credit 50% = 25,000 of a 50,000 monthly fee

The 99.999% line is 26 seconds a month. The same output shows why: "in series" means a customer request passes through every service in turn and fails if any one is down, so the chance that all three are up is 0.9999 x 0.9999 x 0.9999, about 99.97%, lower than any single one. A promise higher than the product of the dependencies you rely on is a promise you cannot keep, so my cloud provider's own SLA and my own architecture set the ceiling.

Step 2: find out what the customer actually needs

I ask what an hour of downtime costs them and which functions must not fail (payments, ordering) versus those that can (reports, back office). Often the real requirement is "the transaction path must not fail during trading hours", not "every feature, every minute".

Step 3: offer alternative structures

• Tier by component: 99.99 percent (about 4.3 minutes a month) for the critical transaction path; 99.9 percent (about 43 minutes) for supporting services. The 99.99 percent tier is only honest if the critical path really can reach it. If it needs three services at 99.99 percent in a chain, the arithmetic above gives 99.97 percent, so I either shorten the chain on that path, or duplicate the weak links so one can fail while a second serves (independent copies in parallel: both down together is 0.0001 x 0.0001, a far smaller chance, though failures that share a cause make the real figure lower), or offer 99.95 percent instead. The platform's own 99.99 percent is the ceiling for anything built wholly on it.
• Measurement rules that are honest: a clear definition of "available", measured at an agreed point (for example at the customer-facing API, not inside my own network), with planned maintenance windows (announced periods when the service may be down) and customer-caused faults excluded.
• Credits instead of unlimited penalties: a service credit is a discount on a later invoice; I use tiers like those in the code (10 percent below 99.95, 25 percent below 99.9, 50 percent below 99.0) with an overall cap, for example 50 percent of the monthly fee, so the penalty exposure is bounded and priced.
• Termination right for chronic failure (for example missing the SLA in three months of any six), which gives the customer a real remedy without open-ended penalties.
• Architecture options at a stated price: multi-region active-active (running the service live in two or more geographic regions at once, so losing one region does not cause an outage) as a paid add-on, so the customer can see what higher availability costs.

Step 4: handle the budget and uncertainty

Because the demand would triple my infrastructure and operating cost, I would phase it: start at 99.9 percent, with a contractual path to 99.95 and then 99.99 as usage and budget grow, each step tied to a stated price. If their usage is uncertain, a committed baseline plus pay-as-you-go above it avoids paying for capacity that is not used. I trade: a longer term or larger commitment from them in exchange for the higher tier from me.

Step 5: show the constraint, do not just assert it

To reduce the demanded uptime I show evidence: the dependency chain (the services a request passes through, one after another) with each component's own SLA, the architecture options with costs, and incident history. "We cannot sign 99.999 percent" is an assertion; "the platform we run on commits to 99.99 percent, so anything above that in a single region would be a promise we cannot keep, and a second region is the priced route to go higher" is a constraint they can check.

In the room I would say: "I can commit to 99.99 percent, about four minutes a month, on the payment path, which is the part that costs you money when it stops, and 99.9 percent on reporting and back office. If we miss 99.99 percent, you receive credits of 10, 25 or 50 percent of that month's fee depending on how far we fall short (for the payment path I start the tiers at the 99.99 promise itself, for example 10 percent below 99.99, 25 percent below 99.95 and 50 percent below 99.9; the tiers in the code above are the ones for a 99.95 promise), and you can terminate if we miss three months in any six. If you need more than 99.99 percent on payments, I can price a second region as an option, and you can see what it costs."

Trade-offs and pitfalls

• Signing the number to win the deal: the penalty exposure and the credibility damage cost more than the contract is worth.
• Credits that exceed the fee: at some point the penalty is a bet against my own platform.
• Walk-away: if procurement insists on uncapped penalties for a figure I cannot deliver, I decline that term and offer the tiered structure; I would rather lose the deal than win one I must breach.