Focus

Who Owns Experimentation? Choosing an Operating Model: Centralised, Centre of Excellence, Hub-and-Spoke or Federated

Alexandre Suon · 2026-10-01

Every experimentation programme reaches the same question: who owns it? This focus compares the four experimentation operating models (centralised, centre of excellence, hub-and-spoke and federated), shows which fits your maturity, the signals that tell you to move, the roles and RACI each needs, and the guardrails to put in place before you let more people test.

Executive summary

1. Ownership is a design choice, and most stalled programmes never made it. In Speero's 2023 benchmark (agency data, 119 maturity-audit respondents), only 17% of 'aspiring' programmes strongly agreed they had a dedicated person responsible for experimentation, against 92% of the most mature ones. Whatever the model, one person must be accountable.
2. Four operating models cover almost every programme. Centralised (one team runs every test), centre of excellence (a central team sets the rules and coaches), hub-and-spoke (specialists sit inside business units, linked to a hub) and federated (product teams run their own tests on a shared platform). Vendors and researchers use different names for the same patterns.
3. The right model depends on volume and maturity, not ambition. Researchers studying Microsoft grouped products into phases running 1–9, 10–99, 100–999 and 1,000+ experiments a year. The median Optimizely customer runs 34 a year (vendor data). Booking.com runs about 25,000. Most e-commerce businesses belong in the first three models, not the fourth.
4. Federated testing works only on top of strong central foundations. Booking.com, Spotify, Netflix and Microsoft let product teams own their tests, and all keep a central team that runs the platform and supports them. Booking.com adds training, peer review and a searchable record of every past experiment.
5. Put six guardrails in place before you give more people the right to test. Training and certification, peer review, a QA checklist, shared metric definitions, guardrail metrics and a central test library. Without a dedicated team, 91% of programmes keep no knowledge base at all (Speero, agency data).
6. Fund the platform centrally and the tests locally. Central ownership of tools, licences and standards stops teams opting out of the rules; local ownership of test budgets keeps roadmaps close to the business. Move to the next model when the signals say so, and step back if trust breaks.

Section 1 · The question

Who owns experimentation is a design choice, and programmes that skip it stall

Most experimentation programmes start by accident. One analyst gets a testing tool, runs a few tests, and within a year other teams want tests too. Then the question arrives: who owns experimentation, and how should the work be split between a central team and the business?

An experimentation operating model is the way a company organises who generates test ideas, who builds and runs experiments, who analyses them, who decides what ships, and who sets the standards and owns the tools. The four common models are centralised, centre of excellence, hub-and-spoke and federated.

The operating model is not an org chart exercise. It decides how many tests you can run, how much people trust the results, and whether learning survives when key people leave. Get it wrong in one direction and a single team becomes a bottleneck. Get it wrong in the other and you get dozens of teams running tests nobody trusts, with conflicting metrics and no shared memory.

This article sits in the middle of our learning path on experimentation culture. If you are still building the case for testing, start with how to build a culture of experimentation and the business case for an experimentation programme. If you are launching a programme, read where to start: champions, sponsors and rituals first. Here we assume you already run tests and need to decide how to organise them.

The first finding is the simplest. Whatever the model, someone must own the programme. Speero, a CRO agency that runs maturity audits, published results in 2023 from 119 respondents audited between October 2021 and December 2022. Overall, 59% strongly or somewhat agreed they had a dedicated person responsible for experimentation. The gap between levels was stark: 17% of 'aspiring' programmes strongly agreed, against 92% of 'transformative' ones.

What this shows. The bars use slightly different measures (strongly agree at each end, strongly or somewhat agree overall), so read them as a direction, not a precise gap. The direction is clear: programmes that mature have a named owner. The data cannot prove that the owner causes maturity, but in our experience programmes without one rarely progress past a handful of tests a quarter.

For leaders. Before choosing a model, name one person accountable for the programme. That person can sit in marketing, product or data. What matters is that they have time, a mandate and a sponsor. In a federated model they run a platform and standards team rather than tests, but the role does not disappear.

Section 2 · The four models

Four operating models cover almost every programme, and they differ in who builds, who decides and who sets the rules

Practitioners and vendors describe these models with different names. CXL describes three: centralised, decentralised and a centre of excellence. Optimizely's field team describes five, including 'testing councils' and a hybrid. GrowthBook, an open-source testing platform, uses isolated teams, decentralised, centre of excellence and hybrid. A 2025 study by Lukas Vermeer, Nils Stotz, Ben Labay and Paul Drews, based on 19 expert interviews, uses centralised, decentralised and centre of excellence, and adds a second dimension: product versus feature-management operating models.

We use four names because they map to four real choices about where the people who build and analyse tests sit. The table translates the vocabularies.

What this shows. Read the exhibit from left to right as a shift of work from the centre to the business. The standards row never disappears: even in a federated model, a central team owns the platform, the metric definitions and the rules. What moves is building, analysis and the decision to ship.

Hub-and-spoke and centre of excellence are often confused. In a centre of excellence, the experts sit in the centre and business teams borrow them. In hub-and-spoke, the experts sit in the business units and are linked to the hub that trains and reviews them.

Section 3 · Centralised

A centralised team is the fastest way to start and the surest way to hit a ceiling

In a centralised model, one team does everything: it collects ideas, prioritises them, designs, builds and QAs tests, analyses results and presents recommendations. The team may be one person and an agency, or a squad of five.

CXL lists the main strengths: expertise in one place, a long-term optimisation strategy, no data silos, and institutional knowledge kept in one place. Optimizely's field team calls the smallest version, a few people partly allocated to testing, the 'individual team', and is blunt about why it exists: 'You have to start somewhere.' Fabijan, Dmitriev, Olsson and Bosch, who studied how experimentation evolved across Microsoft products, describe the same starting point: in the 'crawl' phase, a standalone data science team supports product teams that lack the expertise, and 'the main purpose of the first experiments is to gain traction and evangelize the results'.

When it fits

• You run fewer than about 50 tests a year, on one website or app.
• Testing is new, and you need consistent quality to earn trust.
• Only one or two teams have both the traffic and the appetite to test.
• You work with an agency or fractional team that brings the specialist skills.

How it fails

The failure mode is the queue. Business teams submit ideas, wait, lose interest and stop submitting. The central team ends up testing what it can build quickly, not what matters most. CXL adds two subtler risks: data scientists who 'may feel like outsiders when dealing with the businesses', and the difficulty of getting leaders and data scientists in sync. In our experience the root cause is that the team running the tests is not the team that owns the targets. Kameleoon's guest article by Farfetch's experimentation product lead puts it in one line: centralised models help less mature organisations accelerate adoption, but 'quickly become a bottleneck when you start scaling'.

Our view. Centralised is not a failure state. For a mid-sized retailer running 20 to 40 tests a year, it is often the right model for years. The mistake is staying centralised after demand clearly exceeds capacity, or growing the central team indefinitely instead of teaching others to test.

Section 4 · Centre of excellence

A centre of excellence keeps quality high while other teams start testing, provided it enables rather than gatekeeps

A centre of excellence (CoE) is a central team whose job shifts from running tests to making other teams able to run them. It owns the testing platform, the statistical methods, the QA process and the metric definitions. It still runs complex or high-risk tests itself, and it coaches business teams through their first ones.

Luís Trindade, then principal product manager for experimentation at Farfetch, described the CoE's mission as 'enablement': defining best practices and providing guidance, processes and tooling, so other areas 'do more, run better experiments'. Farfetch's CoE combined a lead with product, engineering and data skills, a principal engineer, two engineering teams of four or five people, a data science team, and non-dedicated ambassadors across departments.

Spotify shows the same idea at scale. Its engineering team describes 'an engagement team — a center of excellence for internal customer success' that provides support, training and best practices, while teams run their own experiments: close to 300 teams were experimenting regularly by 2022.

When it fits

• Demand for tests clearly exceeds what one team can build.
• Two to five business teams have the traffic and the will to test, but not the skills.
• You run roughly 50 to a few hundred tests a year.
• You need to keep one quality bar while capacity grows.

How it fails

GrowthBook warns that a CoE 'can easily become a bottleneck of excellence and limit the number of experiments', and the risk is real: a CoE that reviews and approves every test recreates the central queue with extra steps. CXL points to the other classic failure: employees unsure which team, central or individual, owns which optimisation responsibility and which receives the budget for new hires. A CoE needs a written mandate: what it owns, what it reviews, what it does not decide.

Section 5 · Hub-and-spoke

Hub-and-spoke puts testing skills inside the business units without losing shared standards

In a hub-and-spoke model, specialists (analysts, data scientists, developers or dedicated 'experiment owners') are embedded in business units or product squads. They work on that unit's roadmap every day, but they belong to a professional community run by the hub, which trains them, reviews their designs and keeps the methods consistent.

This is the 'walk' and 'run' pattern in Fabijan et al.'s Microsoft study: data scientists first embedded in product teams while communicating with the central team, then employed by the product teams themselves and trained by the central platform team as local experts. Zalando followed a similar path. Its engineering blog describes how, in its 2016–2020 'walk' phase, a company-wide initiative aimed to ensure 'each team has embedded A/B test owners (product analysts or data scientists)', alongside a central experimentation platform team.

When it fits

• Several business units (brands, countries, product lines) each have their own roadmap and enough traffic.
• Units want testing capacity they control, but you cannot afford inconsistent methods.
• You run a few hundred tests a year or more.
• You have, or can hire, enough specialists to place at least one in each unit.

How it fails

Spokes go native. Over time, embedded specialists adopt their unit's incentives, stop attending hub reviews and start declaring wins the hub would not accept. The second failure is isolation: CXL notes that decentralised specialists can be isolated from 'mentoring and peer feedback'. The fix is rhythm, not reporting lines: a weekly or fortnightly design review run by the hub, shared templates, and a rotation that brings spokes back to the hub for complex tests.

For leaders. Decide early whether spokes report to the hub (solid line) or to the business unit (solid line, dotted to the hub). Solid to the hub protects quality; solid to the unit protects relevance. Either can work, but leaving it vague guarantees conflict at the first performance review.

Section 6 · Federated

Federated testing is the destination for large product organisations, and it only works on a trusted central platform

In a federated model, product teams own the whole test lifecycle: they write hypotheses, build and launch tests, analyse results and decide what ships. A central team still exists, but it runs the platform, the metric definitions and the standards rather than the tests.

Booking.com is the best-documented example. In a 2017 paper, Raphael Lopez Kaufman, Jegar Pitchforth and Lukas Vermeer wrote that all the steps to validate product ideas are 'fully decentralized', from using past learnings to form hypotheses to 'analysing the results and making decisions'. On a daily basis, members of its departments run and analyse 'more than a thousand concurrent experiments'. Stefan Thomke reported in Harvard Business Review in 2020 that Booking.com runs some 25,000 tests a year.

The same paper is just as clear about what makes this possible. Each department has 'its own dedicated team to provide support and to work on improving the experiment platform'. The platform is 'a searchable repository of all the previous successes and failures, dating back to the very first experiment'. Data quality is monitored by computing common metrics in two separate pipelines maintained by different engineers. And the authors note that 'dedicating considerable time to trainings, both online and in classrooms, and to in person support is necessary for decentralizing experimentation at scale'. For more on how these companies operate, see how big tech experiments at scale.

What this shows. The median Optimizely customer runs 34 tests a year, in the 'walk' bracket. Even its top 3% run 500 or more, in 'run'. The companies usually quoted as federated models run 10,000 or more. If your programme runs 40 tests a year, copying Booking.com's organisation will not give you Booking.com's results; it will give you 40 inconsistent tests.

Netflix and Spotify follow the same pattern. Netflix treats its experimentation platform 'as an internal product, complete with its own product manager and innovation roadmap', with experimentation-focused data scientists who collaborate with product teams. Spotify's platform supports more than 300 teams running about 10,000 experiments a year, according to Tyson Singer, its senior vice president of technology and platforms, interviewed by The New Stack in 2025. Bojinov, Holtz, Johari, Schmit and Tingley argue in Harvard Business Review (2025) that companies should move 'away from a data-scientist-centric approach to one that empowers everyone else on the product, marketing, and sales teams to run experiments'.

Our view. Federated is a destination, not a starting point, and many e-commerce businesses never need to reach it. A retailer with one main site and a few hundred tests a year usually gets more from a strong hub-and-spoke model than from full federation. Federation pays off when many independent product teams ship to the same platform every week.

Section 7 · When to move

Move to the next model when the signals say so, and step back when trust breaks

Programmes rarely jump from one model to another in a reorganisation. They drift, and the drift is either deliberate or painful. Exhibit 3 gives the volume logic: Fabijan et al. grouped Microsoft products into four brackets of annual experiments (1–9, 10–99, 100–999 and 1,000+) corresponding to the crawl, walk, run and fly phases. Volume is a useful proxy, but the better triggers are what people experience day to day.

What this shows. Each step to the right gives more people the right to test. The orange boxes are reasons to move; the green boxes are what must already work before you do. The bottom line matters as much as the arrows: if sample ratio mismatch (SRM) failures rise or teams start publishing contradictory results, the programme has moved faster than its guardrails.

Signals you have outgrown your current model

• Queue time. Good ideas wait more than a quarter for build capacity.
• Shadow testing. Teams run tests outside the programme, in other tools or by 'soft launching' changes.
• Narrow coverage. Most tests come from one team or one page type, while other units with traffic do not test at all.
• Specialist overload. Your central analysts spend more time on test set-up than on analysis and coaching.
• Demand for autonomy. Business units ask to own their roadmap, not just submit ideas.

Signals to step back

• Rising SRM failures, broken tracking or tests launched without QA.
• Different teams reporting different numbers for the same metric.
• Wins declared on secondary metrics, or tests stopped as soon as they look good.
• Results not recorded anywhere a newcomer could find them.

Stepping back usually means pulling one activity, such as analysis sign-off or launch QA, back to the centre until the standard holds again. Vermeer et al. found that each team structure brings different challenges depending on whether the company runs a product operating model or a feature-management one (roughly, teams owning outcomes versus teams delivering features), and that targeted changes, 'such as introducing a Center of Excellence or adjusting operating models', can enhance scalability and alignment.

For leaders. Review the operating model once a year, with the programme metrics in front of you: tests per team, time to decision, share of tests passing QA and SRM checks. The programme metrics and maturity self-assessment article covers which ones to track.

Section 8 · Roles and RACI

Every model needs the same seven roles; what changes is who holds them

Operating models move work around, but the work itself does not change. In our experience, every programme needs these seven roles, even if one person holds three of them.

The RACI below shows how responsibility is split in a centre-of-excellence or hub-and-spoke programme, the two models most growing programmes use. R is responsible (does the work), A is accountable (owns the outcome, one per activity), C is consulted and I is informed.

What this shows. The most important cell is the ship or stop decision. It belongs to the product owner, not the experimentation team, because the person who owns the area must live with the result. The experimentation lead is accountable for everything that makes that decision trustworthy: design, QA, monitoring and analysis.

Two adjustments for the other models. In a centralised model, the experimentation lead and the central analysts take most R cells, and the product owner is consulted more than responsible. In a federated model, the product owner becomes accountable for test design and analysis too, and the experimentation lead's accountability narrows to the platform, the standards, training and the test library. For hiring and skills by role, see hiring and training an experimentation team.

Section 9 · Guardrails

Give more people the right to test only after six guardrails are in place

Democratising experimentation means giving more people the right to launch tests. It is the right goal, and our experimentation manifesto argues for it. But every company that does it well built guardrails first. The six below are the minimum we recommend before moving from a centralised model to a centre of excellence, and certainly before hub-and-spoke or federated.

What this shows. No beginner or aspiring programme in Speero's sample kept a knowledge base, and 91% of programmes without a dedicated team had none. Decentralised teams did only slightly better than average, at 57% without one. A test library does not appear by itself when more people test; someone must own it, which is why it sits with the experimentation lead in Exhibit 5.

For the review step, a 2019 study by Fabijan, Dmitriev, Olsson, Bosch, Vermeer and Lewis offers a template: ten items to check in the design before a test starts, three while it runs and nine in the debrief. You do not need all 22 on day one, but checking before, during and after is the right structure for peer review.

AI makes guardrails more important, not less

AI coding assistants and agents now let a marketer describe a variation in plain language and get working code in minutes. We tested this ourselves in a step-by-step walkthrough of a prompt-built A/B test. Testing vendors are also adding agents that suggest hypotheses, draft variations and summarise results; we cover what they ship in AI agents in experimentation.

For operating models, the effect is simple. AI removes the developer bottleneck that kept many programmes centralised, so more people will be able to launch tests sooner. It does not remove the need for a sound hypothesis, a valid design, QA, metric definitions or a readout someone has reviewed. If anything, faster building raises the risk of many fast, untrusted tests. Treat AI as a reason to put the six guardrails in place earlier. Agents connected through the Model Context Protocol (MCP) to your test library and analytics can help enforce them, for example by checking a test plan against your metric definitions, but a named person should still sign off.

Section 10 · Budget and tooling

Fund the platform centrally and the tests locally, so nobody can opt out of the standards

In our experience, budget disputes are one of the most common reasons operating models break. CXL lists confusion over which team, central or individual, receives the budget for new hires as a core risk of the centre-of-excellence model. The cleanest rule we have found is to separate what must be shared from what should be local.

Tool choice deserves one more word. A federated model needs a platform that non-specialists can use safely: self-serve set-up, automatic SRM and guardrail checks, and a searchable results history. A centralised model can live with a tool that only experts use. When you choose or renew a platform, score it against the model you expect to run in two years, not the one you run today. Our vendor-neutral tool selection scorecard includes these criteria.

Disclosure: Henkan & Partners provides fractional experimentation teams and works with several testing vendors. We have tried to describe each model on its merits, including those that need no outside support.

Section 11 · What to do next

What to do next: name an owner, pick a model for today and write down the rules

1. Name one accountable owner

Before you discuss models, agree who is accountable for the programme, how much of their time it gets, and who sponsors them. Exhibit 1 shows why: mature programmes almost always have this person.

2. Place yourself on the maturity scale

Count the tests you completed in the last 12 months and the teams that ran them. Use Exhibit 3 to see which bracket you are in, and choose the model that fits today, not the one you aspire to. Most programmes under 100 tests a year belong in a centralised or centre-of-excellence model.

3. Write the RACI and the mandate

Adapt Exhibit 5 to your organisation, with one accountable person per activity. Write a one-page mandate for the central team: what it owns, what it reviews and what it does not decide. Share it with every business unit lead.

4. Install the guardrails before you widen access

Check the six guardrails in Table 3. Put the missing ones in place, starting with the test library and metric definitions, before you let more teams launch tests. To get started faster, download the Experimentation Culture Kit: it includes a one-page charter, ritual agendas, a stakeholder map, objection cards, a RACI template, a health scorecard and a maturity self-assessment.

5. Review the model once a year

Set a date to review the model against the signals in Exhibit 4, with your programme metrics in front of you. Move forward when demand and guardrails allow; step back on one activity if trust breaks. Explaining the change to each stakeholder is its own skill, covered in how to talk about experimentation to every stakeholder, and keeping energy up during the transition is covered in building momentum in an experimentation programme.

6. Get an outside view if you are stuck

If you cannot agree on the model, or the programme has stalled after a reorganisation, an external review can help separate structure problems from skill or data problems. Talk to us.

FAQ

Frequently asked questions about experimentation operating models

Frequently asked questions

What is an experimentation operating model?

It is the way a company organises who generates test ideas, who builds and runs experiments, who analyses them, who decides what ships and who sets the standards and owns the tools. The four common models are centralised, centre of excellence, hub-and-spoke and federated.

What is an experimentation centre of excellence?

A central team that owns the testing platform, statistical methods, QA process and metric definitions, runs complex tests itself and coaches other teams to run their own. Its mission is enablement. It fails when it becomes an approval queue for every test.

Should experimentation be centralised or decentralised?

It depends on volume and maturity. In our experience, centralised suits programmes running up to about 50 tests a year; a centre of excellence or hub-and-spoke suits programmes running from about 50 to several hundred; full decentralisation suits large product organisations running thousands. Even decentralised programmes keep a central platform and standards team.

What is the difference between hub-and-spoke and a centre of excellence?

In a centre of excellence the experts sit in the central team and business teams borrow them. In hub-and-spoke the experts sit inside business units and are linked to a hub that trains them, reviews their work and keeps methods consistent.

Who should own A/B testing in an e-commerce company?

One named experimentation lead should own the programme, its standards and its tools, wherever they sit (marketing, product or data). The ship or stop decision for each test should belong to the owner of the area being tested, usually a product owner or trading lead.

When should we democratise experimentation?

When demand for tests clearly exceeds central capacity and six guardrails are in place: training and certification, peer review, a QA checklist, shared metric definitions, guardrail metrics and a central test library. Democratising before these exist produces many tests that nobody trusts.

Does AI change who should own experimentation?

AI tools can build variations and draft analyses, which removes the developer bottleneck that kept many programmes centralised. They do not remove the need for sound hypotheses, QA, metric definitions and reviewed readouts, so AI is a reason to install guardrails earlier, not to skip them.

What is the crawl, walk, run, fly model?

A maturity model from Fabijan, Dmitriev, Olsson and Bosch (2017), based on a study of experimentation at Microsoft. Programmes evolve from a standalone central team running a few experiments (crawl) to product teams running thousands a year autonomously (fly), with technical, organisational and business changes at each phase.

Key terms

Experimentation operating model

How a company splits ideation, building, analysis, decisions and standards for experiments between a central team and the business. It matters because it sets how many tests you can run and how far people trust them.

Centralised model

One team runs every test for the business. It matters because it is the fastest way to start with consistent quality, but becomes a bottleneck as demand grows.

Centre of excellence (CoE)

A central team that owns tools, methods and quality and coaches others to test. It matters because it lets testing spread without lowering the quality bar, if it enables rather than gatekeeps.

Hub-and-spoke model

Specialists embedded in business units, linked to a central hub that trains and reviews them. It matters because it puts testing capacity where the roadmaps are while keeping methods consistent.

Federated model

Product teams own the whole test lifecycle on a shared self-serve platform. It matters because it allows thousands of tests a year, but only with strong central guardrails.

Democratisation

Giving more people the right to design and launch experiments. It matters because it raises volume and ownership, and raises the risk of untrusted results without guardrails.

RACI

A matrix that marks who is responsible, accountable, consulted and informed for each activity. It matters because it removes ambiguity about who decides, especially the ship or stop decision.

Executive sponsor

A senior leader who sets targets for the programme and protects its budget. It matters because programmes without one struggle to change decisions above team level.

Champion

A volunteer in a business team who spreads the practice locally. It matters because champions extend a small central team's reach without adding headcount.

Test library

A searchable record of every experiment's hypothesis, design, result and decision. It matters because learning otherwise leaves with the people who ran the tests.

Guardrail metric

A metric a test must not harm, with a threshold agreed in advance. It matters because it lets more people test without risking revenue or the customer experience.

Sample ratio mismatch (SRM)

When the observed traffic split differs from the planned one more than chance allows. It matters because it signals a broken test, and rising SRM failures signal a model moving faster than its guardrails.

Crawl, walk, run, fly

The four phases of the Experimentation Evolution Model, from a 2017 study of experimentation at Microsoft by Fabijan et al. It matters because it links experiment volume to the organisation needed to support it.

Sources

All sources were checked in October 2026. Speero figures come from an agency's maturity audits and are labelled agency data. Optimizely, GrowthBook, Eppo and Kameleoon content is vendor content, and Optimizely benchmark figures are vendor data; the Kameleoon article was written by a Farfetch employee. Spotify figures come from its engineering blog and from its technology leadership quoted by The New Stack. Exhibits 2, 4 and 5, Tables 2 and 4 and the structure of Table 3 are Henkan & Partners frameworks; the vocabulary mapping in Table 1 and the model-per-phase labels in Exhibit 3 are our interpretation.

1. Fabijan, A., Dmitriev, P., Olsson, H. H. & Bosch, J. (2017). The Evolution of Continuous Experimentation in Software Product Development. ICSE 2017.
2. Fabijan, A., Dmitriev, P., Olsson, H. H., Bosch, J., Vermeer, L. & Lewis, D. (2019). Three Key Checklists and Remedies for Trustworthy Analysis of Online Controlled Experiments at Scale. ICSE SEIP 2019.
3. Kaufman, R. L., Pitchforth, J. & Vermeer, L. (2017). Democratizing online controlled experiments at Booking.com. arXiv.
4. Vermeer, L., Stotz, N., Labay, B. & Drews, P. (2025). Aligning Experimentation with Product Operations: A Taxonomy for Structuring Experimentation Teams. SEAA 2025, Springer LNCS; author page.
5. Thomke, S. (2020). Building a Culture of Experimentation. Harvard Business Review.
6. Bojinov, I., Holtz, D., Johari, R., Schmit, S. & Tingley, M. (2025). Want Your Company to Get Better at Experimentation?. Harvard Business Review.
7. Speero (2023). The State of Experimentation Programs 2023. Agency data.
8. Speero (2025). Experimentation Maturity Benchmark Report 2025: Methods & Process. Agency data.
9. CXL (2017, updated 2022). How to Structure Your Optimization and Experimentation Teams.
10. Optimizely (2019). Experimentation team structure tips. Vendor content.
11. Optimizely (n.d.). Top 10 takeaways from running 127,000 experiments. Vendor data.
12. GrowthBook (n.d.). Experimentation Programs. Vendor documentation.
13. Eppo (2025). Building High-Impact Team Structures for Experimentation. Vendor content.
14. Kameleoon / Trindade, L. (2022). What is a 'Center of Excellence' in experimentation?. Vendor blog.
15. Zalando Engineering (2021). Experimentation Platform at Zalando: Part 1 - Evolution.
16. Spotify Engineering (2025). Beyond Winning: Spotify's Experiments with Learning Framework.
17. The New Stack (2025). Confidence: Spotify Gives Developers a Platform for Experiments.
18. Netflix Technology Blog (2022). Netflix: A Culture of Learning.