You are introducing performance budgets across a dozen product teams' repositories. How do you roll them out so the checks are still enforced a year later rather than disabled or routinely bypassed?

## What actually kills these programmes Performance gates rarely fail on technical grounds. They fail in three recognisable ways, and the rollout plan is mostly about pre-empting each one. **Noise.** The check fails on changes that did nothing, people re-run it, and within weeks a failure carries no information. From then on real regressions ship. **No owner.** The gate fires on a shared route that four teams contribute to. Nobody's roadmap includes fixing it, so it is escalated, then bypassed, then removed. **No legitimate exit.** A launch is blocked by a budget, the deadline is real, someone finds the skip mechanism, and the skip becomes institutional knowledge. Once bypassing is normal the gate is decorative. A year-one plan that does not address all three is a plan to delete the check in month four. ## Phase one: measure, do not enforce Ship the job everywhere in warn mode. Its only job at this stage is to produce numbers and put them where people can see them. Derive each initial budget from the route's current measurement plus headroom, so that day one is green everywhere — a rollout that opens with every repository red teaches teams that the check is someone else's noise. This phase also buys the data you need for every later decision: the current spread of each metric, which routes are already near a sensible ceiling, and how long the job takes. ## Phase two: earn the right to block Before anything blocks a merge, the check has to be **fast** and **quiet**. Fast means it does not meaningfully lengthen the pull-request cycle — measure only representative routes, keep the cheap deterministic assertions on every change, and push exhaustive sweeps to a nightly run on the main branch. Quiet means you have measured the job's own false-failure rate by running unchanged commits repeatedly, and it is close to zero. Then promote in order of trust: byte and request-count budgets first, since they are reproducible for a given commit; measured metrics later, and only where the threshold sits comfortably outside the noise band. A gate that only ever blocks on things it is certain about will be defended by the same engineers who would have deleted a noisy one. ## Ownership Every budget needs a team whose name is on it, recorded next to the number. Budgets on shared surfaces — the app shell, the design system bundle, the third-party tag set — are the ones that go feral, because a failure lands on whoever happened to touch the file. Those need explicit owners even more than product routes do, and often a separate budget of their own so a platform regression does not present as a product-team failure. Ownership also means the failure message has to reach the owner in usable form. "Total blocking time regressed" sends people to a dashboard. "scripts on /checkout: 214 kB, budget 170 kB — largest additions: date-picker 38 kB, moment locales 22 kB" is a review comment that fixes itself. ## The escape hatch, on purpose There will be a launch that matters more than a budget. Design that path rather than letting people find it: a documented exemption, recorded in the repository, requiring a named approver, carrying an **expiry date** and a linked follow-up issue. The expiry is the load-bearing part — an exemption without one is a budget increase with extra steps. The contrast is with an undocumented mechanism: a label that skips the job, an environment variable, a commented-out line. Those leave no record, produce no follow-up, and spread by word of mouth until the check is effectively off. ## Tie the number to something people believe Teams comply with budgets they think are real. That means connecting the budget back to observed outcomes — the routes where field data is worst, the pages where a slow experience costs conversions — and revisiting budgets that turn out to be arbitrary. A budget nobody can trace to a consequence gets argued away the first time it is inconvenient, and losing that argument once undermines every other budget you set. ## Measure the policy, not just the pages The programme needs its own metrics, reviewed on a regular cadence: - **Bypass rate** — exemptions granted and skips used per month. Rising means the budgets are wrong or the check is not trusted. - **False-failure rate** — failures that a re-run clears. Above a few percent, stop tightening and go fix the harness. - **Budget movement** — how many ceilings went up versus down. All-up over a year means the ratchet is not being used and you are running a very slow-motion regression. - **Coverage** — routes with an owned budget versus routes without. Those four numbers tell you whether you have a policy or a decoration, which is the only question that matters twelve months in.