The release candidate is ready, the functional tests are green, and the product manager has a date. Then someone asks whether it has been load tested. The performance team's next slot is in two weeks.

This is the traditional model: a small group of specialists, a shared pre-production environment, and a big load test at the end, used as a gate. When it works, it catches problems before customers do. When it doesn't, it catches them too late to fix, or it gets skipped. Contractors told Congress that end-to-end testing of Healthcare.gov began two weeks before launch. MongoDB's performance team has described, in a peer-reviewed paper, how its own end-of-cycle testing led to delayed releases or regressions shipped to customers.

The usual answer is to "shift left" and hand testing to developers. The evidence says that is only half right. Our conclusion, and how our largest customers operate: decentralize ownership of performance, and centralize the platform that supports it.

What a central team gets right, and what it costs

A dedicated performance team exists for good reasons: specialists who can model a workload and tell a real regression from noise, one consistent methodology, a view of the whole system, and tight control over who can point heavy traffic at what. Those strengths are real. Here is what they cost as the organization grows.

• Testing becomes an event: When a load test means booking the shared environment and gathering the specialists, it gets scheduled rather than done. LoginRadius described the result: "That pushed performance testing to the back burner; it only ran when absolutely necessary." Yet DORA's definition of continuous integration includes developers getting feedback from performance tests every day.
• Feedback arrives late, and to the wrong person: A regression introduced in week one surfaces in week ten, mixed with dozens of other changes. The person who finds it rarely caused it, so it lands as a ticket about code its author has moved on from. MongoDB described exactly this diagnosis burden before moving its tests into CI.
• Teams wait in line: DORA treats testing on demand, without waiting for an integrated environment, as a core capability of high-performing teams. Intuit, describing its own specialist model, said every team needing a load test joined a queue. With finite capacity, a central team covers what is most visible. At IMA Group, much of the rest shipped untested.
• Tests model last quarter's traffic: Big suites are rebuilt rarely, while users and software keep changing. Facebook's engineers made this point when they built Kraken to load test with live traffic: a capacity model is hard to keep current.
• A late gate is easy to overrule: On September 30, 2013, a stress test of a key Healthcare.gov component reached 1,100 users before response times became too high. The target was 10,000. The site launched the next day. Officials later disputed how representative that test was, which is the point: one late result is easy to argue with.

These costs compound. Hard-to-run tests happen rarely, rare tests cover big batches of change, big batches are slow to diagnose, and late results get overruled. Adding specialists to the central team doesn't break that loop.

Where decentralization goes wrong

Handing every team a load testing tool doesn't solve this. The research is clear about the failure modes.

• Developers left alone write few tests, and many are flawed: In a study of 111 open-source Java projects, the median project had 246 lines of performance test code against 3,980 of functional tests. A study of 123 projects found benchmarking mistakes in widespread use.
• The tooling is hard: A SPEC Research Group survey found that tool complexity holds back performance testing in DevOps.
• Component tests miss system behavior: Microservice baselines are noisy, and some bottlenecks only appear when dozens of services are loaded together. That is why Shopify, whose teams own their services, still runs coordinated platform-wide scale tests before Black Friday.
• Autonomy isn't accountability: At Spotify, by one former engineer's account, the alignment and accountability parts of the squad model were never completed.

Centralized execution isn't the problem either: Meta runs a shared performance platform, ServiceLab, across its services. Moving the test is not the same as moving the ownership.

The model: central platform, distributed ownership

Google's SRE model keeps services with product teams while SRE owns capacity planning. Netflix built its canary analysis tool, Kayenta, centrally, and service owners choose the metrics it judges. Team Topologies calls this a platform team plus an enabling team. Specialists don't disappear. They stop being a queue and start building the paved road.

Six principles, and how Gatling Enterprise Edition supports them

Each failure mode above has a countermeasure. Here is how we see them, and the Gatling Enterprise Edition capability behind each.

1. Tests live in the service repo, in the team's language: Friction is a big reason developers write few performance tests. Gatling tests are code in Java, JavaScript, TypeScript, Kotlin or Scala, reviewed in pull requests like any other change. Intuit ships a pre-configured performance test folder with every new repo. EPI Company writes its tests in Kotlin because, says Ulrich Winter, "that really lowers the barrier for developers to contribute."

2. The platform takes the hard shared work: Gatling Enterprise Edition runs managed load generators, or Private Locations inside your own network, so product teams never maintain test infrastructure. At Nickel and InPost, product teams own their scenarios while a platform team handles environments, secrets and permissions. "We stopped maintaining boxes," says InPost's Mateusz Piasta.

3. Pass/fail is agreed before the test runs: Thresholds live in the simulation as assertions, such as forAll().responseTime().percentile(95).lt(300), or as SLOs set in Gatling Enterprise Edition, which take precedence when both exist. Sophos teams test against service-level agreements set by product management. Tikamoon's rule is shorter: "No Gatling run, no production."

4. Methodology is standardized centrally: If one team uses a closed injection model and another an open one, their p95 numbers can't be compared. The platform team should settle conventions like this once, in templates. Campaigns in Gatling Enterprise Edition score every test on methodology, objectives and stability over its last three runs.

5. Runs are compared over time: Noisy environments make a single run against a fixed threshold misleading. Run comparison, the trends view and AI Trend Analysis show where a regression appeared. That is how InPost caught a doubling of requests per second, caused by a needless HTTP-to-HTTPS redirect, before it reached production.

6. Governance stays central, and system-level tests stay coordinated: Gatling Enterprise Edition gives each team its own credit quota, roles and isolated workspace, while platform owners keep visibility across all of them. Attentive's service owners each name a contact for cross-service game days that run every morning through the API. InPost's five-day simulation of the full parcel journey found bottlenecks "from code to cables."

What it looks like in practice

Sophos: no central QA team

When Sophos moved to microservices, it chose not to build a central QA or performance team. Each microservice team tests its own APIs against business-defined service-level agreements and reuses simulations across teams, while leadership tracks results and regressions in shared dashboards. Around 200 people now use the platform, with 100+ simulations covering 75 to 80% of backend APIs. Seeing their own services under load, teams also found endpoints that were wasting cloud resources.

Intuit: the same model at 8,000 engineers

Intuit's specialist model meant late feedback, regressions in production, a queue for every team, and around 30 fragmented tools. Principal Engineer Chaitanya Bhatt rebuilt it as a platform: test scaffolding in every repo, CI/CD onboarding, pre-built templates, and central governance. The Gatling Enterprise Edition API lets Intuit provision teams, simulations and roles from its internal developer portal. Gatling users grew from fewer than 100 in 2018 to more than 3,000, running 80,000+ tests a year with 97% coverage of critical services. Intuit didn't remove the center. It turned it into a platform.

Other ways to split it

Attentive has no testing department, but a Developer Experience team runs the shared tooling. IMA Group and SNCF Connect & Tech both replaced central testing units with team ownership. In the other direction, Aircall grew a dedicated performance department as demand rose, and Criteo runs five performance engineers supporting 70+ colleagues. The goal isn't to remove specialists. It's to stop them being the only place testing happens. More examples are in our customer stories.

When not to decentralize

• Small organizations: Without people to staff a platform, decentralizing just means nobody runs the tests.
• Tightly coupled systems: Test ownership won't fix architectural coupling. The system-level test is the one that matters.
• No CI/CD or observability: Teams get numbers they can't act on. Build those first.
• Regulated environments: These need an auditable gate, but that fits a federated model. At Nickel, a BNP Paribas subsidiary, product teams own their scenarios, load runs from Private Locations inside Nickel's network, and results go through a mandatory Change Advisory Board review.

How to start

1. Make the platform self-service through an API and CI integration.
2. Move scenarios into team repos, starting with a few willing teams and templates.
3. Add short checks to CI, and keep long tests for later stages.
4. Standardize injection models, percentiles and pass/fail conventions.
5. Keep coordinated capacity and peak-event tests with a named owner.

Measure results, not adoption: time from commit to regression detection, performance incidents in production, and time to repair them. And pilot first, because DORA's 2024 report associates new internal platforms with an initial dip in throughput and stability.

Ownership is the point

A central team that owns every test becomes a queue. Developers who own tests without standards or support produce numbers nobody trusts. Give each team ownership of its own performance, and give the platform everything teams can't do alone. As IMA Group's Mehdi Chilla puts it: "Performance testing should be part of the natural workflow, not an exceptional activity."

See how Intuit runs this across 8,000 engineers in Chaitanya Bhatt's 45-minute session, or compare Gatling Community and Enterprise Edition.