Handle deadlines and misses

## How to Approach This Question This is a STAR (Situation, Task, Action, Result) question that maps directly to Amazon's Leadership Principles — especially **Ownership**, **Deliver Results**, **Earn Trust**, **Dive Deep**, and **Bias for Action**. Two things win the room: - **Engineering judgment under pressure:** decomposition, estimation with uncertainty, critical-path focus, deliberate scope control, and risk management. - **Ownership of a miss:** transparency, early escalation with options, and systemic safeguards — plus evidence those safeguards later worked. Quantify everything you can (dates, latency, error rate, adoption, revenue protected, cost saved) and name the specific trade-offs you proposed and why. --- ## Part A — Tight Deadline (Example + Reusable Playbook) **Situation** We had 10 business days to ship a new "Bulk CSV Upload" feature for a strategic customer demo; missing the date risked the deal. Dependencies: object storage, validation rules owned by another team, and UI changes. **Task** Deliver a functional MVP that handles the core use cases, is safe (no data loss), observable, and demo-ready by the deadline. **Action** 1. **Estimation (with uncertainty)** - Built a work breakdown structure (WBS): upload/status API, async ingestion pipeline, v1 validation rules, UI flow + progress, observability (metrics/alerts), E2E tests + docs. - Estimated each task with three points and combined them with PERT: `E = (O + 4M + P) / 6`, variance ≈ `((P − O)/6)^2`; sum the variances for overall uncertainty. Example (backend API, O=1d, M=2d, P=4d): `(1 + 4×2 + 4)/6 = 2.17d`. - Sanity-checked against team capacity: `capacity (dev-days) = engineers × focus_factor × days`. Example: `3 × 0.7 × 10 ≈ 21 dev-days`. If the Must-have work sums to ~18 dev-days, only ~3 remain for Should/Could — that gap is the early signal you must cut scope or add help. - Communicated ranges and confidence (P50 ≈ 9–10d, P90 ≈ 12–13d) and flagged that hitting 10 days required tight scope focus and frictionless dependencies. 2. **Prioritization** - Identified the critical path: storage integration → ingestion pipeline → API → UI wiring → E2E tests. Parallelized off-critical-path work (docs, dashboards). - Wrote a Definition of Done for the MVP: files ≤ 10MB / 10k rows, schema + required-field validation, progress feedback, idempotency, metrics, and a rollback plan. 3. **Scope negotiation** - Proposed phasing to stakeholders with explicit trade-offs: - **MVP (by Day 10):** single-file uploads, synchronous validation summary, best-effort performance. - **Phase 2 (post-demo):** multi-file batching, cross-row validations, localization, background retries for partial failures. - Made the cost of each cut concrete (e.g., limited file size and simpler validation reduce risk and timeline; non-critical UX polish deferred). Negotiated a change freeze during the demo window. 4. **Communicating trade-offs and risks** - Daily 15-minute checkpoint with a written update: R/Y/G status, burndown, risks, and blockers; twice-weekly stakeholder checkpoint. - Maintained a lightweight RAID/risk log (Risks, Assumptions, Issues, Dependencies) with owners and mitigations: dependency on the validation rules, storage throttling, CSV edge cases → mitigated with stubbed validation first, a canary on small files, rate limiting/backpressure, and a feature flag + rollback. - Shipped behind a feature flag with a staged canary (5% → 25% → 50% → 100%) and pre-defined abort criteria (e.g., abort if p95 latency > 300ms or error rate > 0.5%). **Result** - Shipped the MVP on Day 9 behind a feature flag; the demo succeeded. - 0 data-loss incidents, p95 ingestion 6.5s for 10k rows, 100% of demo flows passed. Delivered Phase 2 the following sprint. **Reusable playbook:** Decompose → estimate with ranges (PERT or t-shirt) → identify critical path → timebox spikes for unknowns → define MVP + DoD → negotiate phases → status with clear R/Y/G → guardrails (feature flags, canary, rollback). Commit to the P90 externally; plan to the P50 internally. --- ## Part B — Missed Commitment (Example + Safeguards) **Situation** We committed to migrate to a new authentication library by the end of a sprint to align with a platform upgrade. **The miss** We missed by one week. **Root cause (Dive Deep)** - Underestimated hidden coupling: the new library had subtly different token-refresh semantics that broke long-lived sessions under load. - Integration tests passed locally, but staging lacked realistic session lifetimes and traffic, so the defect was invisible until canary. - We did not timebox a spike to validate critical flows end-to-end; estimates assumed drop-in compatibility, and a cross-team approval dependency was not surfaced early. **How I handled stakeholders / escalation (Earn Trust)** - The moment canary metrics turned bad (session invalidations, elevated 401s), I posted a **red** status with findings, impact, and a clear slip range (+5 to +8 days) rather than letting risk accumulate silently. - Presented concrete options: (a) roll back and re-plan; (b) partial rollout behind a feature flag to internal users; (c) extend by one week to build a compatibility shim and expand staging tests. - Escalated to the engineering manager and dependent teams, assigned a DRI, set up a short war room, and kept a decision log. We chose to roll back immediately and take the one-week extension to ship the shim and harden staging. **What I learned** - Unknowns must be explicit tasks with timeboxed spikes and acceptance criteria — not silent assumptions. - Passing unit tests is insufficient; integration parity in a production-like environment (realistic traffic and session duration) is what catches this class of bug. - Communicate risk as soon as probability × impact becomes material; stakeholders prefer early clarity to late surprises. **Safeguards implemented (and that they later worked)** - *Planning:* discovery spikes for unknowns baked into estimates; 50/90 estimation with commitments to P90; a risk register with owners reviewed weekly; a 20–30% contingency buffer for work with external dependencies; no start without confirmed dependency SLAs/approvals. - *Engineering:* feature flags default-off for risky changes with canary rollout and automatic rollback conditions; staging-parity improvements (synthetic long-lived sessions, load and chaos tests for token refresh/expiry); preflight checklists for migrations (backwards compatibility, observability, rollback, runbooks). - *Execution/communication:* R/Y/G with explicit entry/exit criteria and an automatic "red" if key SLOs regress in canary; decision logs and DRI assignment for complex changes. - *Evidence:* subsequent migrations landed within P90 dates, and the canary caught a regression twice with zero customer impact thanks to auto-rollback and runbooks. --- ## Common Pitfalls to Avoid - Single-point estimates with no uncertainty range. - Treating dependencies as "done" without integration validation. - Overloading the MVP with non-essential polish. - Silent risk accumulation — escalate early, with options and data, not after the deadline has already slipped. ## Checklist for Your Own Answer - Situation and business impact are clear and quantified. - Estimation method and confidence are stated (e.g., PERT, P50/P90, capacity math). - Critical path and scope trade-offs are explicit. - Risk management and a concrete communication cadence (R/Y/G, decision log) are described. - For the miss: honest root cause, proactive early escalation with options, durable safeguards, and evidence they later worked.

Rubric: a strong answer uses STAR with quantified results and ties behavior to Amazon's Ownership / Deliver Results / Earn Trust / Dive Deep principles. Part A should show structured estimation with uncertainty (PERT E=(O+4M+P)/6 or capacity = engineers × focus × days, P50 vs P90), critical-path-driven prioritization, deliberate scope phasing with explicit trade-offs, and a risk/communication cadence (R/Y/G, RAID log, feature-flag + canary + rollback guardrails). Part B should show honest root-cause analysis, early proactive escalation with concrete options (rollback / partial rollout / extend), and systemic safeguards (spikes for unknowns, P90 commitments, staging parity, preflight checklists) plus evidence they later worked. Red flags: single-point estimates, dependencies assumed done without integration validation, and late/silent risk disclosure.