Direct answer
Tell a story where the cut was deliberate and bounded. You protected the checks that guard against harm that is hard to undo or hard to notice (data correctness, privacy or governance sign-off, a way to switch the change off), and you accepted risk where mistakes are cheap to detect and reverse. You added a stand-in control for each thing you skipped (a cheaper safeguard that covers the same risk, called a compensating control), and you paid the debt back afterwards.
How to decide what to protect
| Question | Protect if... | Accept risk if... |
|---|
| Can we undo it? | Hard or impossible to reverse | Flag off or rollback in minutes |
| How wide is the damage? | All customers or money or personal data | One internal screen |
| Would we notice quickly? | Fails silently | Alert fires within minutes |
Story (illustrative)
Situation: 3 weeks to ship a machine-learning model that scores support tickets by urgency, tied to a customer launch. The full plan had an offline accuracy evaluation (scoring the model on past tickets before it touches live traffic), integration tests, a full-scale load test (simulating production traffic volume to see whether the system holds up), and a privacy review (the privacy or legal team checks the model's use of customer text and can block the launch; that is the governance sign-off).
- Protected: the privacy review (started in week 1 in parallel, not saved for the end); the accuracy check on a labelled held-out sample (past tickets with known correct urgency that the model never trained on) against the bar agreed up front; a kill switch (one flag that turns the feature off instantly); and a latency alert (an alarm that fires when responses get slow) plus an error alert.
- Accepted: no full-scale load test; instead a staged rollout (5%, 25%, then 100% of traffic over a week). No automated tests for the admin settings page; a manual checklist instead.
- Accuracy versus speed: agents act on the score within seconds, so a quick, simple model gave a rough score instantly, and a bigger, slower model re-scored every ticket overnight. The same idea works in any product: show a fast estimate now and verify it later. The screen labelled scores "estimated" until re-scored, and a nightly report of tickets where the two scores differed was the compensating control. A wrong score here means a ticket is mis-ordered for a few hours, not lost data.
What happened afterwards
At 25% a latency alert fired on large accounts (a slow database query only visible with real traffic). We dropped back to 5% with the flag within the hour, added an index and resumed. Nobody outside saw an outage. The following sprint started with 3 days on the skipped tests, logged in the debt register (a shared list of shortcuts we owe repayment on, each with an owner and a date).
Lesson and pitfalls
- Next time I would ask for a load test on a production-sized copy in week 1, since it was cheap.
- Wrong turns: cutting testing silently, skipping the thing that is irreversible, or cutting with no named payback date.
- Governance reviewers respond well to an early, minimal-scope request; surprising them at the end is how deadlines and standards collide.
