Describe conflict resolution, prioritization, and collaboration

# Recommended structure - Use STAR+R: Situation, Task, Actions, Results, Reflection. - Anchor discussion in data, trade-offs, and decision-making frameworks (e.g., 5 Whys, SLO/error budget, RACI/DACI, MoSCoW, feature flags, canaries). # Example answer (Software Engineer) ## Situation Our team owned a high-traffic notifications service. Three weeks before a quarterly launch of a new "smart digest" feature, our p95 latency doubled (≈220 ms → ≈480 ms) and error rate rose to ~2.3%. Product pushed to hit the date; SRE proposed a freeze; mobile wanted stability to avoid app-store regressions. The conflict centered on scope and sequencing: ship the feature on time vs. pause to fix reliability. ## Task As an IC without formal authority, I needed to (a) identify the root cause, (b) align priorities across Product, SRE, Mobile, and Backend, and (c) deliver both reliability and a viable launch plan. ## Actions 1) Identify root cause (data-first): - Instrumented additional tracing and 1% request sampling to get end-to-end spans. - Ran a blameless mini-postmortem and a 5 Whys analysis. - Found an N+1 pattern: a new ranking path called three downstream services serially. Cache TTLs were misaligned (30 min upstream vs. 5 min local), causing cache churn and a stampede on cold starts. - Verified via load testing: fan-out magnified under peak traffic; fallback path did heavy DB joins. 2) Align priorities and decision criteria: - Proposed an SLO: p95 ≤ 250 ms, error rate ≤ 0.5%. Used current burn rate to define an error budget. - Wrote a 1-pager with options, costs, and risks: - A: Delay launch, refactor fully (high reliability, miss date). - B: Ship as-is (on time, fails SLO, likely user impact). - C: Two-track plan: short-term mitigations + a reduced-scope feature behind a flag, then follow-on refactor. - Facilitated a 30-minute decision review using DACI (Driver: me; Approver: EM; Contributors: PM, SRE, Mobile). - Team chose C, with go/no-go gates tied to SLOs. 3) Drive resolution (execution plan): - Short-term mitigations (3 days): - Align cache TTLs; add request coalescing to avoid duplicate work. - Add a circuit breaker and rate limiting around the slowest dependency. - Precompute the heaviest join into a small cache warmed by a background job. - Canary + ring deployment; feature flag for instant rollback. - Reduced-scope MVP (1 week): - Defer less impactful personalization signals to later. - Keep digest server-side only; postpone client-side animation and deep links. - A/B enablement to validate impact and guard stability. - Created a RACI for tasks, a dedicated Slack channel, and 15-minute daily standups with a live checklist and rollback plan. 4) Balance competing deadlines: - Timeboxed mitigations to 3 days; if SLO not met, escalate to delay launch. - Sequenced work so reliability gates preceded feature ramp. - Maintained a single source of truth dashboard: p95, error rate, cache hit rate, on-call pages. 5) Lead without authority; collaborate cross-team: - I facilitated alignment, authored the decision doc, and clarified owners without changing reporting lines. - Paired with SRE on alerts/runbooks; worked with Mobile for client gating; synced with PM on user impact and scope; coordinated QA on test plans. ## Results - Met the launch date with phased rollout (25% → 50% → 100%). - p95 latency dropped from ~480 ms to ~220 ms; error rate fell from ~2.3% to ~0.4%. - On-call pages decreased ~60% week-over-week. - A/B test showed +3.1% CTR lift on the digest with no stability regressions. - Captured learning in a postmortem, added load-test coverage, and documented cache patterns and circuit-breaker defaults. ## Reflection (what I learned and would do differently) - Learnings: - Data-driven frameworks defuse conflict: SLOs and error budgets turned opinions into measurable gates. - Feature flags and canaries are essential guardrails when balancing scope vs. stability. - A clear decision doc (DACI) plus RACI for execution minimizes churn. - Do differently: - Establish SLOs and error budgets earlier in the quarter to avoid last-minute disputes. - Run a pre-mortem before high-risk launches; add synthetic load tests for new fan-out paths. - Stakeholder-map earlier (e.g., Mobile release train) to surface hidden constraints sooner. # Why this works (teaching notes) - Root cause: Show how you isolated the issue (tracing, 5 Whys, experiments) and validated with tests. - Priorities: Use explicit criteria (SLOs, OKRs, error budgets) and a decision framework (DACI/RACI, MoSCoW). - Resolution: Split into short-term mitigations and longer-term fixes; use flags/canaries for safety. - Leadership without authority: Facilitation, documentation, and clear ownership often matter more than title. - Outcomes: Quantify impact (latency, error rate, pages, user metrics). Tie back to business goals. # Guardrails and pitfalls - Guardrails: feature flags, canaries, rollback plan, success metrics dashboard, timeboxed mitigations, go/no-go gates. - Pitfalls to avoid: debating opinions instead of data; ambiguous ownership; skipping observability; all-or-nothing scope; no rollback path.