The pattern is familiar enough to be a genre. Performance degrades to the point of complaint. A sprint is allocated. Engineers profile, find real problems, fix them, and the numbers improve. Six months later the numbers are back where they started, and someone proposes another sprint.
The technical work in these sprints is usually correct. The problem is that performance is being treated as a project, and it is not one. It is a property that degrades continuously under normal development pressure — which makes it an organizational problem wearing technical clothing.
Why sprints decay
Feature work has an owner, a deadline and a person who notices if it does not happen. Between performance sprints, performance has none of those things.
Every individual decision that degrades it is locally reasonable. Adding a library to ship faster. Rendering a component that mostly does not need to re-render. Deferring an optimisation because the deadline is real and the regression is small. No single decision is wrong. The aggregate is a steady slide, and nobody's name is on it.
A sprint resets the number. It does not change any of the incentives that produced the number.
What a standing team changes
We stood up a dedicated App & Web Performance team with a remit across the whole customer estate rather than inside any one squad. Three things changed, and only one was technical.
Someone is accountable between crises. The most important shift. Performance now has an owner during the long stretches when it is not on fire, which is precisely when it degrades.
Measurement became continuous and public. Per-release scorecards, tracked across releases rather than sampled during incidents. Teams optimise for what is visible; making the trend visible did more for behaviour than any amount of advocacy.
Expertise accumulated instead of dispersing. Performance investigation is a genuine specialism — profiling, instrumentation, knowing which measurements lie. When that work is distributed across squads, everyone rebuilds the same shallow understanding. A standing team compounds it.
The preventative work is the point
The most valuable output of that team does not show up as a speed improvement.
We reduced unoptimised rendering paths by 85% — the pattern where parts of a screen redraw because they are reacting to data that has not meaningfully changed. On any given release, fixing those produced no headline number. They were not what customers were noticing.
But that class of work is what stops performance decaying as features are added on top. It does not make the app faster today; it makes the app not get slower over the next twenty releases. That distinction is nearly impossible to sell as a project and straightforward to justify as a standing function.
The measurement that matters
Track quality indicators per release, across releases. A single good measurement tells you about a sprint. A consistent direction across many releases tells you whether the practice is working. Ours improved in every release rather than in one push — which is the only evidence that actually predicts whether the gains hold.
Central team, distributed responsibility
The obvious failure mode of a central performance team is that it becomes the place performance is someone else's job. Squads ship whatever they like; the performance team cleans up.
Avoiding that is mostly about what the team is for. Ours works primarily on measurement, tooling, standards and the hard cross-cutting investigations that no single squad can justify. The routine work of not shipping a regression stays with the squad that would have shipped it — which only functions because the scorecards make each squad's contribution visible.
The rule I would state plainly: a central team should own the ability to see and the standards to meet, not the obligation to fix everything. The moment it owns the fixing, the incentive that produced the problem is fully restored.
What it costs
Headcount that could be shipping features, permanently rather than temporarily. That is a real trade and worth being honest about.
What it buys is a platform where performance is a maintained property rather than a periodically rediscovered emergency — and, less obviously, one where a major framework migration can be delivered with customer-facing performance held flat, because the measurement discipline to prove it already existed.
You cannot hold a line you were never measuring.