Handle deadlines and misses

# How to Approach This Question - Use STAR (Situation, Task, Action, Result) and quantify results (latency, errors, adoption, revenue, dates). - Show engineering judgment: decomposition, estimation (including uncertainty), critical path, scope control, and risk management. - Show ownership when describing the miss: transparency, corrective action, and systemic safeguards. --- ## Part A — Tight Deadline (Example + 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, data validation rules from data science, and UI changes. Task - Deliver a functional MVP that handles core use cases, is safe (no data loss), observable, and demo-ready. Action 1) Estimation - Broke work into a WBS (work breakdown structure): - Backend API (upload, status): O=1d, M=2d, P=4d - Asynchronous ingestion pipeline: O=2d, M=3d, P=5d - Validation rules (v1): O=0.5d, M=1d, P=2d - UI flow (upload + progress): O=1d, M=2d, P=3d - Observability (metrics, alerts): O=0.5d, M=1d, P=1.5d - E2E tests and doc: O=1d, M=2d, P=3d - Used PERT for each task: E = (O + 4M + P) / 6 and summed expected durations. - Example for backend API: (1 + 4*2 + 4) / 6 = 2.17d - Communicated ranges and confidence (P50 ≈ 9–10d, P90 ≈ 12–13d) and flagged that hitting 10d requires scope focus and frictionless dependencies. 2) Prioritization - Identified critical path: storage integration → ingestion pipeline → API → UI wiring → E2E tests. - Parallelized non-critical tasks (docs, dashboards) off the critical path. - Defined a Definition of Done for MVP: handles files ≤ 10MB, 10k rows, basic validation (schema + required fields), progress feedback, idempotency, metrics, and rollback plan. 3) Scope Negotiation - Proposed phasing to stakeholders: - MVP (by Day 10): single-file uploads, synchronous validation summary, English-only error messages, best-effort performance targets. - Phase 2 (post-demo): multi-file batching, advanced validations (cross-row rules), localization, background retries for partial failures. - Explicit trade-offs: limited file size and simpler validation reduce risk and timeline; non-critical UX polish deferred. 4) Communicating Trade-offs and Risks - Established a daily 15-minute checkpoint with a written update: status (R/Y/G), burn-down chart, risks, and blocks. - Maintained a lightweight RAID log: - Risks: dependency on data science rules, storage throttling, CSV edge cases. - Mitigations: stubbed validation first; canary with small sample files; rate limiting and backpressure; feature flag + rollback. - Documented impact of scope cuts on user experience and demo script. Result - Shipped MVP on Day 9 behind a feature flag; demo succeeded. - Metrics: 0 data-loss incidents, p95 ingestion time 6.5s for 10k rows, 100% demo flows passed. - Delivered Phase 2 items in the following sprint. Why this works - Shows structured estimation, critical path focus, proactive scope control, and transparent risk management. Playbook You Can Reuse - Decompose → Estimate with ranges (PERT or t-shirt sizes) → Identify critical path → Timebox spikes for unknowns → Define MVP and DoD → Negotiate phases → Communicate status and risks with clear R/Y/G → Implement guardrails (feature flags, canary, rollback). Formulas and Tips - PERT expected time: E = (O + 4M + P) / 6, variance ≈ ((P − O)/6)^2; sum variances for overall uncertainty. - Communicate P50 vs P90 dates; plan to the P90 for commitments, use P50 internally. - Prioritization frameworks: MoSCoW (Must/Should/Could/Won’t), critical path, and risk-first sequencing. --- ## Part B — Missed Commitment (Example + Safeguards) Situation - We committed to complete a migration to a new authentication library by the end of a sprint to align with a platform upgrade. Commitment Miss - We missed by one week. Root Cause - Underestimated hidden coupling and test environment gaps: - The new auth library had subtle differences in token refresh semantics that broke long-lived sessions under load. - Integration tests passed locally but staging lacked realistic session lifetimes and traffic patterns. - We did not timebox a spike to validate critical flows end-to-end; estimates assumed drop-in compatibility. Communication and Escalation - As soon as we identified failing canary metrics (session invalidations, increased 401s), we: - Flagged risk in stand-up and posted a red status update with current findings, impact, and options. - Proposed options: rollback and re-plan; partial rollout behind feature flag to internal users; or extend date by one week to build compatibility shim. - Escalated to engineering manager and dependent teams; set up a war room with a DRI and clear decision log. - Chose to rollback immediately and take a one-week extension to implement the shim and expand staging tests. What I Learned - Unknowns must be explicit tasks with timeboxed spikes and clear acceptance criteria. - Integration parity matters: passing unit tests is insufficient; test in a production-like environment with realistic traffic and session duration. - Communicate risk as soon as probability × impact becomes material; stakeholders prefer early clarity to late surprises. Safeguards Implemented - Planning - Add discovery spikes for "unknown unknowns" in estimates; use 50/90 estimates and commit to P90. - Maintain a risk register with owners and mitigations; review weekly. - Engineering - Feature flags for all risky changes; default off with canary rollout and automatic rollback conditions. - Staging parity improvements: synthetic long-lived sessions, load tests, and chaos tests for token refresh and expiry edges. - Preflight checklists for migrations (backwards compatibility, observability, rollback plan, runbooks). - Execution and Communication - R/Y/G status with explicit entry/exit criteria; automatic "red" if key SLOs regress in canary. - Decision logs for scope/schedule changes; DRI assignment for complex changes. Result After Safeguards - Subsequent migrations landed within P90 dates; canary caught a regression twice with zero customer impact due to auto-rollback and runbooks. --- Common Pitfalls to Avoid - Single-point estimates without uncertainty ranges. - Treating dependencies as "done" without integration validation. - Overloading MVP with non-essential polish. - Silent risk accumulation; escalate early with options and data. Checklist for Your Own Answer - Situation and business impact are clear and quantified. - Estimation method and confidence are stated (e.g., PERT, P50/P90). - Critical path and scope trade-offs are explicit. - Risk management and communication cadence are described. - For the miss: honest root cause, proactive communication, concrete safeguards, and evidence they worked later.