Ship-or-Delay Call on a Major Bug Two Days Before a Key Customer Release

It is Wednesday, and a release that a key customer is counting on is due Friday. The engineering manager has just told you about a major bug in it. What do you do? ```hint Size it before you choose Before picking between shipping, holding or something in between, pin down what the bug breaks, who would hit it, and how sure engineering is about a fix date. ``` ### Clarifying Questions - What does the bug affect: security or customer data, overall stability, or one feature that may have a workaround? Does the key customer actually use that part of the product? - Is Friday a contractual or go-live commitment for the customer, or a target we set ourselves, and what happens if it slips? - Is this release built only for this customer, or is it a general release that every customer will receive? - Can engineering switch the affected functionality off, and how confident is their estimate for a fix? ### What a Strong Answer Covers - Fast triage of the bug: severity, reproducibility, how many users and which accounts are exposed, and the fix estimate and its risk - The full set of options (ship as is, ship with the feature disabled or a documented workaround, a targeted release for the key customer, a short slip) and explicit criteria for choosing among them - Who joins the decision and by when, so the customer hears early rather than on Friday - How the key customer and everyone else are told, by whom, and with what commitment - Execution and follow-through: a go/no-go checkpoint, rollback and support readiness, the fix plan, and a retrospective on why the bug surfaced so late ### Follow-up Questions - The fix will take about a week and the customer says Friday cannot move because their own rollout depends on it. What now? - How would your answer change if the bug exposed customer data instead of breaking a feature? - What would you change in the release process so a major bug is not found two days before a committed date?