How would you turn an on-call pager-load cap into a policy the organization actually respects, rather than a number on a dashboard?

## Why caps fail Most teams that have an on-call health problem also already have a number. Someone put "max 2 pages per shift" in a wiki. It changes nothing, and the reason is structural rather than cultural: the cap describes a state, but nothing in the organisation *does* anything when the state is violated. When the pager is bad, the team is also behind on delivery, and the person who would have to enforce the cap is the person under delivery pressure. The cap loses every time. So the design problem is not choosing the number. It is arranging for the breach to have a consequence that does not depend on someone finding the courage in a bad week. ## The three pre-commitments **1. The threshold, in shift terms.** Pages per shift, expressed as a rate over a window — for example, more than a stated number of shifts in a rolling month exceeded the limit. Rate over a window beats a single-shift trigger, which fires on one bad night and gets ignored. **2. The automatic consequence.** This is the whole policy. Options, roughly in increasing strength: - *Cleanup takes precedence.* Until the rotation is back under the cap, alert cleanup and reliability fixes rank above roadmap work. The cost is explicit: named commitments slip. - *Feature launches pause for the affected service.* Stronger, because it also stops adding new failure modes to a rotation that cannot absorb them. - *Operational ownership reverts.* The service's pager routes back to the team that built it until it meets the agreed operational standard. This is the model Google's SRE organisation is known for, and it works precisely because SRE support is a service that can be withdrawn. It only exists as a lever where a separate operating team exists in the first place; be honest in an interview about whether it applies to the org you are describing. **3. The exception path.** There will be legitimate exceptions — a migration, a launch. So define them: exceptions require a named approver, a stated reason, and an expiry date. An exception without an expiry is a repeal. ## The gaming problem Any metric attached to a consequence gets optimised, including in ways you did not intend. Pager load can be improved without improving anything by silencing alerts, raising thresholds until nothing fires, or reclassifying pages as tickets that nobody reads. This is not a hypothetical; it is the default outcome if the cap stands alone. The defence is a counterweight metric published beside it, so the trade is visible: - **Actionable rate** — falling pager load with a stable-or-rising actionable rate is genuine improvement. - **Customer-reported and externally detected incidents** — if these climb while pages fall, detection was traded away. - **Reliability outcomes** — user-visible failures should not be getting worse while the pager gets quieter. A cap paired with a detection metric is hard to game; a cap alone is trivially gameable. ## Making it boring The policies that survive are the ones that appear in a routine forum. Pager load should be reported in the same review as delivery status, every cycle, whether or not it is bad. Two benefits: the trend is visible before it is a crisis, and by the time a breach occurs the number is familiar rather than something the team is suddenly waving in an escalation. Anything that only ever gets raised as a complaint reads as a complaint. It also needs a sponsor with the authority to let commitments slip. A cap enforced by an engineer against a director's roadmap is not a policy; it is an argument that engineer will lose. ## Choosing the number Copying an external figure uncritically is a weak answer. Google's SRE guidance of at most two incidents per 12-hour shift comes with a staffing model behind it. A team of six covering everything themselves may have to start from where they are: set the cap slightly below the current p90 shift, enforce it, and ratchet it down each quarter. A cap you can actually hold and lower beats an aspirational number that is breached from day one and therefore ignored. ## What the interviewer is checking That you understand incentives, not that you can recite a threshold. The strong answer has: a pre-agreed consequence with a real cost, a named decider, expiring exceptions, a counterweight metric against gaming, and a sponsor. The weak answer is a number and a hope that people will care.