Handle conflict, priorities, and harsh clients

Describe a specific project where you and a tech lead clashed strongly over model selection while a deadline loomed. How did you bring the conflict into the open, organize the decision (trade-offs, risks, evidence), and get stakeholders aligned on priorities? Walk through what you did on your own — experiments, analyses — to back your position. Now imagine an external client who is harsh, demanding an immediate ship and brushing aside your concerns: how did you hold boundaries, report status and risk, and keep their trust? If that client escalates while your manager is unreachable, what concrete steps would you take in the next 24 hours, and how would you record the decisions so they cannot be re-litigated?

Overview: This English-language prompt assesses conflict handling, stakeholder management, technical judgment around model choice, risk assessment, escalation, and documentation within a Data Scientist role, probing Behavioral & Leadership competencies in a cross-functional, client-facing setting.

Solution What follows is a structured, instructional example you can tailor. It demonstrates how to convert a disagreement into a principled decision, safeguard delivery timelines, and keep stakeholders aligned.

---

1) Situation and Disagreement (STAR: Situation/Task)

• Situation: Our team was building a real-time ranking model for personalized notifications, with a p95 latency SLO below 100 ms and tight memory limits (edge deployment). An external client pilot was due in two weeks.
• Disagreement: The tech lead favored a Transformer-based model (marginally better offline accuracy). I pushed for gradient-boosted trees (e.g., XGBoost) because of latency, footprint, and faster iteration within the deadline.
• Assumptions: roughly 50M predictions per day; on-device and battery sensitivity; a regulatory requirement for explainability when reviewing decisions.

2) Surfacing Conflict and Structuring the Decision (STAR: Action)

I brought the conflict into the open and kept it constructive:

• Booked a 30-minute "decision review" with the tech lead and the PM, framing it as a constrained choice rather than a personal clash.
• Suggested a lightweight DACI/RAPID structure:
  • Driver: me (analysis and options prepared)
  • Approver/Decider: Eng Manager and PM together
  • Contributors: tech lead, privacy reviewer, SRE
  • Informed: client POC
• Drafted a two-page decision memo covering:
  1. The problem and its constraints
  2. Options with their trade-offs and risks
  3. Success criteria and gating metrics
  4. Rollout plan and rollback criteria

Weighted decision criteria:

• Predictive quality (0.4)
• Latency and footprint (0.3)
• Robustness and operability (0.2)
• Delivery risk against the deadline (0.1)

Options:

• A) XGBoost (trees): AUC 0.86, p95 latency around 45 ms, model size about 20 MB, mature tooling
• B) small Transformer: AUC 0.88, p95 latency near 180 ms, model size roughly 250 MB, an unproven serving path

Sample risk-register entries:

• B could break the latency SLO and raise on-call exposure at launch
• A gives up a little AUC but is stable, simpler to explain, and easier to calibrate

3) Independent Validation (STAR: Action)

Time-boxed experiments (48 hours) to shrink the uncertainty:

• Data hygiene: temporal splits to prevent leakage, with stratified sampling per segment.
• Baselines: logistic regression first, then XGBoost, then a distilled Transformer prototype.
• Calibration and error analysis: reliability curves, SHAP for feature effects, and per-segment metrics.
• Latency and size tests: p95/p99 measured in staging, plus memory and CPU profiles.
• Robustness checks: drift sensitivity (train on the two weeks before, test on the most recent week) and stress tests with missing features.

A quick numeric trade-off illustration:

• Assume per-day error costs: FP cost = $0.05 (annoyance), FN cost = $0.50 (missed engagement).
• Daily predictions: 50M; prevalence 5%.
• A: precision 0.40, recall 0.55, giving expected cost

$$\approx 0.40 \times \mathrm{FPs} \times 0.05 + 0.45 \times \mathrm{FNs} \times 0.50$$

• B: precision 0.42, recall 0.58
• If B cuts FN by 3 percentage points absolute yet raises p95 latency by 135 ms, and a latency breach cuts send-through by about 2% under load, the net expected value can flip. I put numbers on this with a simple expected-cost model:

$$\text{Expected cost} = \mathrm{FP\_count} \times C_{\mathrm{FP}} + \mathrm{FN\_count} \times C_{\mathrm{FN}}$$

• plus a penalty for SLO breach derived from historical drop-offs.

That placed both options on a common business-impact scale.

Result: B's AUC gains turned into modest business lift but carried heavy SLO risk. A met the SLO with headroom at comparable expected value.

4) Aligning Stakeholders and Choosing a Path (STAR: Result)

• Presented a one-page summary with a heatmap of criterion scores, an expected-value comparison, and a staged rollout plan.
• Proposed shipping A now while running B in shadow for a week, then revisiting with data. The approver agreed on delivery-risk and SLO grounds.
• Outcome: A launched behind a canary rollout $1\% \rightarrow 10\% \rightarrow 50\% \rightarrow 100\%$, a feature flag, and a rollback plan. It delivered a +1.6 pp CTR lift over baseline at p95 latency 52 ms with zero incidents. The shadow run of B fed a later iteration.

5) Handling a Harsh Client Pushing to Ship Immediately

Principles: stay concise, quantify risk, offer options, set boundaries.

• Boundary setting: "We will not ship past a p95 of 100 ms; releasing the Transformer today would likely overshoot that by roughly 80 ms, risking throttling and user complaints."
• Offer options:
  1. Ship A to GA today while B runs in shadow; reassess in 7 days on real data.
  2. A limited 1% pilot of B behind a kill switch, with explicit risk acceptance.
  3. Push B out one week to finish performance hardening.
• Communicate status and risk:
  • A red/yellow/green risk dashboard, plus written daily updates carrying metrics and next steps.
  • A crisp rollback rule: "If p95 goes above 100 ms for 15 minutes or the error rate goes above 0.5%, we auto-disable."
• Maintain trust: anchor every claim in data, show live dashboards, give the client read-only monitoring access, and recap agreements by email.

6) If Client Escalates and Manager Is Unavailable: 24-Hour Action Plan

0–2 hours: Triage and authority

• Confirm who holds interim decision authority — an Eng Manager delegate or the PM — and record it in Slack or email.
• Restate the decision criteria and SLOs in writing.

2–6 hours: Data and experiments

• Run a focused performance test of B at the expected QPS, capturing p95/p99, memory, and error rates.
• Finish the A-versus-B expected-value model using the latest costs, reviewed with the client.

6–10 hours: Risk mitigation path

• Stand up a 1% canary for B in staging or a low-traffic slice, with the kill switch and alerts enabled.
• Prepare a rollback runbook and on-call coverage.

10–14 hours: Stakeholder alignment

• Hold a 30-minute checkpoint with the client: side-by-side metrics, options with their consequences, and one clear recommendation.
• Record their choice and any risk acceptance it requires.

14–24 hours: Execute and document

• Execute the agreed plan (e.g., ship A to GA with B shadowed), monitor it, and publish a short report.
• Send a decision-summary email covering context, options, criteria, the decision, owners, timelines, and explicit risk acceptance where it applies.

7) Documentation to Prevent Re-litigation

Create a lightweight Architecture/Decision Record (ADR):

• Context: goals, constraints, SLOs
• Options considered: A, B and variants
• Criteria and weights, plus the data used (links to notebooks and dashboards)
• Decision and rationale: why this one, why not the others
• Risk acceptance: who approved it and under what conditions
• Rollout plan: gates, kill switch, rollback
• Follow-ups: which data would trigger a re-evaluation

Make it operational:

• Keep the ADR in the repo and link JIRA tickets and experiment artifacts to it.
• Meeting notes carrying attendee acknowledgments, with an e-sign or a Slack emoji-ack for traceability.
• Version the decisions — ADR-012-v1 (pilot), ADR-012-v2 (GA) — with timestamps.

Common Pitfalls and Guardrails

• Pitfall: arguing accuracy while ignoring latency and operability — reason with end-to-end SLOs and business cost modeling instead.
• Pitfall: analysis paralysis — time-box the experiments and agree on a deadline.
• Guardrails: feature flags, canary releases, auto-rollback, p95/p99 alerts, shadow mode, calibration checks, and per-segment fairness audits.

Takeaway

A principled process — clear criteria, time-boxed validation, staged rollout, rigorous documentation — resolves disagreements fast, protects the launch, and holds trust even under outside pressure.