Prompt and scenario
An outage has consumed 80% of this month’s error budget, but the product lead still wants to release an important feature on schedule. You own reliability but do not have unilateral veto power. Explain how you would prepare the facts, communicate, offer options, drive a decision, and run a retrospective if the outcome is poor.
What the interviewer is testing
- Whether you turn conflict into shared goals and verifiable facts instead of blaming the other person.
- Whether you distinguish risk thresholds, business deadlines, and irreversible impact, then offer staged options.
- Whether you can influence a decision without formal authority while making ownership and follow-up traceable.
- Whether you show real self-reflection, listening, and cross-functional collaboration.
Clarifying questions to ask first
- Which service, user journey, and time window does the 80% represent, and what SLO risk remains?
- Is the launch date, revenue, or customer commitment truly immovable, or can scope and rollout size change?
- Are the incident cause, rollback time, monitoring coverage, and current mitigations confirmed?
- Who is the final decision-maker, and is there an error-budget policy, release gate, or escalation path?
A 30-second answer
I would translate the 80% budget consumption into user impact, remaining risk, and recovery time, then confirm the data before meeting the product lead. I would acknowledge the date goal and explain the worst-case impact, reversibility, and uncertainty of a full rollout. I would offer a staged release, reduced scope, a repair-first delay, or explicit rollback conditions instead of simply saying “no.” Once we agree on decision gates, I would record the owner and triggers and track the result after launch. Whatever happens, I would document the reasoning in a blameless retrospective and improve monitoring and policy.
Deep dive
1. Translate the metric into a decision-relevant impact
An error budget is shared language between a service objective and acceptable failure, but a percentage alone is not enough. I would add affected user journeys, error classes, time trend, remaining budget, recovery time, and confidence. If the evidence is server-side while user experience is unverified, I would state the uncertainty rather than create pressure with false precision.
2. Listen to business constraints before naming the shared goal
I would ask why the date matters: a contract, market window, customer demo, or internal promise. That separates immovable constraints from negotiable preferences. We can frame the shared goal as preserving as much release value as possible without exceeding acceptable user risk, so reliability and delivery are not competing scoreboards.
3. Start with options rather than a veto
I would prepare at least three choices: delay and repair first; release to low-risk tenants or internal users; or keep the date while disabling high-risk capabilities with automatic pause, rollback, and error-rate gates. For each, I would list user impact, revenue or commitment impact, implementation cost, rollback time, and approvers. If evidence is weak, run a short reversible experiment to reduce uncertainty.
4. Make authority and escalation explicit
If policy says to pause releases after budget exhaustion, I would cite the policy and invite product, engineering, and a manager to review an exception rather than blocking privately. If policy does not cover the case, I would put facts, options, recommendation, and residual risk in a decision record with an owner and review time. Escalate the disagreement, not the person.
5. Put observable guardrails around the rollout
Before a staged release, define success metrics, stop thresholds, an observation window, and a rollback rehearsal. Thresholds may include user-facing error rate, completion of critical flows, latency, and budget burn rate; example numbers must come from the service baseline. Staff an on-call owner, alerts, and one communication channel so everyone can see the stage, owner, and next decision time.
6. Use the retrospective to repair the system and relationship
If the result is poor, reconstruct the timeline and information available at the time rather than turning the discussion into who insisted on the wrong opinion. Record missing signals, untested assumptions, policy usability, communication timing, owners, and dates. A good result also deserves review because a successful exception can hide an unsustainable risk.
A complete strong answer
I would confirm the service scope, user impact, remaining window, and confidence of the error-budget data, then understand the real constraint behind the launch date. In the conversation, I would restate the product goal and explain the possible full-rollout consequences in shared user-risk terms. I would offer repair-first delay, low-risk staged release, and reduced scope with automatic rollback, listing impact, cost, thresholds, and owners for each. If a release gate exists, I would run the documented exception review; if not, I would create a written decision record and escalate to a shared owner. After launch I would watch user metrics, burn rate, and rollback conditions, then capture communication improvements in a blameless retrospective.
Common failure modes
- Saying “an exhausted budget means no release” without checking policy, authority, or business constraints.
- Discussing only technical metrics without translating them into user impact, commitments, and reversibility.
- Describing the product lead as an obstacle instead of demonstrating listening and a shared goal.
- Suggesting a “canary” without a rollout size, observation window, stop threshold, or rollback owner.
- Blaming a person after the outcome instead of reviewing the information and system gaps that existed then.
Follow-ups and extensions
Follow-up 1: What if the product lead insists on a full rollout?
I would confirm that the risk and alternatives are understood and record the evidence, decision-maker, exception reason, guardrails, and review time. If the choice violates policy, I would use the escalation path to a shared owner; within my authority, I would perform my role without secretly blocking or hiding information.
Follow-up 2: What if the metrics conflict?
Prioritize by user journey, separating safety, critical flows, and non-critical experience, then state data delay and confidence intervals. Narrow the rollout and extend observation until the risk supports a reversible decision.
Follow-up 3: How do you prove the communication improved the team?
Check whether decision records contain facts, options, owners, and triggers. Observe whether later releases detect risk earlier, roll back faster, and use the same metrics across teams. Use concrete outcomes rather than “everyone felt smoother.”
Follow-up 4: How do you stop an error budget becoming a weapon between teams?
Treat the budget and SLO as an agreed mechanism, review thresholds and exception flow regularly, use user-facing measures, and publish decision records. Any team may raise risk, but the decision basis must be auditable and reproducible.