As the owner of a bug bar, how do you keep fix deadlines and the ship gate credible under launch pressure?

## The pressure is the point A bug bar that has never been tested by a deadline has not been tested. The whole artifact exists for the week when a High lands on a feature the company has already announced. Everything below is about making that week boring. ## Set the clocks so they can actually be met Per-band fix deadlines — a bank might run 7 days for Critical, 30 for High, 90 for Moderate — are commitments, and a commitment nobody meets is worse than no commitment, because it teaches the organisation that the bar is decorative. Two disciplines keep them real: - **Derive the clock from observed capacity**, not from aspiration. If the last four quarters show Highs closing in a median of 45 days, a 14-day clock is a lie you are writing down. - **Measure and publish** on-time fix rate per band and the age distribution of open findings. This is the evidence that either defends the bar or tells you to change it. The clock also needs a defined start: normally when the band is assigned, not when someone gets around to triaging it, or the clock becomes a queue-management tool. ## Keep the gating set small Severity and gating are separate columns for a reason. The temptation is to make every band block something, on the theory that this maximises safety; the actual effect is that the gate fires constantly, leadership learns to override it, and the override becomes routine. A gate that blocks rarely and absolutely is worth more than one that blocks often and negotiably. In practice: Critical blocks the build unconditionally; High blocks a major release but not a patch; everything else is tracked against its clock. ## Route acceptance away from the security engineer When the pressure arrives, the wrong conversation is "is this really a High?" and the right one is "who is accepting the consequence of shipping with a known High, and for how long?". Design the bar so that: - The band itself is not up for negotiation, because it is a lookup against pre-agreed rows. - Shipping anyway is a **business decision made by a named accountable owner**, recorded, with an expiry date and a fix commitment attached. - The security engineer's job in that meeting is to state the exposure accurately, not to defend a number. This single separation is what stops severity inflation and deflation both: nobody needs to game the band, because the band is not the lever. ## Keep a floor that never moves Some consequence classes should not be tradeable at all. An agricultural-sprayer autonomy vendor whose products drive themselves through a field can reasonably carry a separate safety band — say, anything that lets someone with maintenance or physical access alter spray-rate or boundary limits — and write into the bar that this band has no acceptance path and no schedule override. The value is not the specific rule; it is that the organisation decided, in the calm, which category it will never trade, so nobody has to win that argument in the heat. ## Change the bar deliberately, never mid-argument The most corrosive failure is amending the bar to resolve the finding in front of you. If the rows are genuinely wrong, that is real information — but the change lands in the next calibration review and applies to future findings. Otherwise the bar becomes a record of who was under the most pressure and when. A workable cadence: review the bar quarterly or per major release, with security and engineering leadership jointly signing it, using three inputs — findings that matched no row, bands that were repeatedly contested, and the on-time fix data. ## What gaming looks like Watch for these, because they are how a bar dies quietly: - **Band drift near release dates.** Compare the band distribution of findings raised in the last two weeks before a ship date against the rest of the quarter. A visible shift downward is a process finding, not a coincidence. - **Reclassification on appeal**, where the second opinion is always the lower one. - **Clock laundering**, where a finding is closed and immediately reopened as a new one, resetting the deadline. - **Scope narrowing**, where the finding is re-described as affecting a component the bar rates lower. - **Permanent acceptances**, where the expiry date is never enforced and the exception becomes the design. ## Shared ownership A bar that security wrote alone is security's document, and it will be treated as an external tax. The version that survives is co-signed by engineering leadership and, for regulated products, by whoever answers to the regulator — because on the day the clock is inconvenient, the people defending it need to include the people who would otherwise be arguing against it. ## The interview signal This is a judgment question with no single right answer, and the answer that lands has four moves in it: pre-agreement, a small and absolute gate, acceptance routed to an accountable owner with an expiry, and measurement that feeds a scheduled recalibration. A candidate who answers only "hold the line" has not run one of these; a candidate who answers only "be pragmatic" has not defended one.