CRO Team Size Benchmarks by Company Size
What the published data really says about CRO team size, why no headcount benchmark by company size exists, and how to size a team from your own traffic.
📚 This article is part of the guide How to Build an Experimentation Culture (2026).
There is no reliable published benchmark for CRO team size by company size, and the ones circulating in sales decks rarely name a source. What does exist in the public record is more useful than a headcount table anyway: data on whether programs have a dedicated owner at all, on how many tests real practitioners actually finish per month, and on the traffic arithmetic that caps what any team can measure. This article covers what the published data genuinely supports, why a headcount copied from another company is the wrong input, and a transparent method for sizing your own team from throughput. It is part of the guide on how to build an experimentation culture.
What the published data actually supports
Three sources carry most of what can be honestly said about experimentation staffing today. None of them publishes an average headcount by company size, and that absence is itself the finding.
| Source | Sample and method | What it supports |
|---|---|---|
| Speero, State of Experimentation Programs 2023 | 119 respondents who completed the maturity audit between October 2021 and December 2022, recruited through the company’s own newsletter, site and social channels | Whether programs have a dedicated owner, and how that correlates with maturity |
| Convert, CRO Agency and Vendor Ecosystem Report (published July 2025, updated April 2026) | 237 agencies identified globally, 40 hour-long interviews and more than 200 survey responses from agency leaders | Agency-side headcount distribution and test throughput per practitioner |
| VWO, Experimentation Maturity Benchmark Report 2025-2026 | Survey of experimentation programs; the sample size is not disclosed on the public page | Where programs report being bottlenecked, at the level of execution volume |
The single most quotable number for staffing comes from Speero: only 59 percent of respondents strongly or somewhat agreed that they had a dedicated person responsible for experimentation. Split by maturity level, on the stricter “strongly agree” reading, the gap is stark: 17 percent at the least mature (“aspiring”) level, against 92 percent among the most mature (“transformative”) programs. Two related findings sharpen the picture: about 91 percent of respondents with no dedicated team had no knowledge base for storing test insights, and 57 percent of decentralized teams reported not using one either.
The agency side adds a reality check from a different angle. Convert’s research identified 237 CRO agencies worldwide and found that only 7 percent had more than 30 employees, and that 60 percent of agency practitioners run two or fewer tests per month. Agencies are not in-house teams, and one agency person spreads across several clients, so the headcount figure does not transfer. The throughput figure travels better: two tests a month is the working reality for most of the professional market, not an underachieving outlier.
VWO’s own report page frames the same constraint from the buyer side, stating that 56 percent of experimentation programs are trapped in an execution bottleneck and that over half of surveyed organizations are stuck at a low monthly test volume. The public page does not disclose the sample size, so it belongs in the “directional” column rather than the evidence column.
Why a headcount copied from another company is the wrong input
Two companies with the same revenue, the same industry and the same headcount can have completely different sensible team sizes, because the binding constraint on a CRO program is not budget. It is how many tests the site can actually conclude, and that number is set by traffic and by the effect size the team wants to detect.
A team of six on a site that can only conclude two tests a month is not a strong program, it is five people waiting. A single owner on a site with millions of monthly sessions is not a lean program, it is a bottleneck leaving measurable revenue unmeasured. Neither of those situations is visible in a headcount benchmark, which is exactly why copying one produces bad hiring plans in both directions.
Size the team from throughput instead
The honest method has three steps: compute how many tests your traffic can conclude per month, translate that into the work each test actually requires, and only then decide how many people that workload needs.
Step 1: what your traffic can conclude
Every test consumes visitors, and how many depends on the baseline conversion rate and the smallest effect worth detecting. At 95 percent confidence and 80 percent power, two-sided, for a two-variation test on a page converting at 3 percent:
Two-proportion normal approximation, 2 variations (50/50). Tweak the inputs and watch it update live.
| Smallest effect you want to detect | Sample per variation | Visitors per test | Tests per month at 150,000 visitors |
|---|---|---|---|
| +30 percent relative | 6,455 | 12,910 | 11.6 |
| +20 percent relative | 13,914 | 27,828 | 5.4 |
| +15 percent relative | 24,193 | 48,386 | 3.1 |
| +10 percent relative | 53,211 | 106,422 | 1.4 |
The baseline rate moves the same arithmetic just as hard. Holding the target at a 20 percent relative improvement, a page converting at 5 percent needs 8,158 per variation, one at 3 percent needs 13,914, and one at 2 percent needs 21,109. On 150,000 monthly visitors that is 9.2, 5.4 and 3.6 tests a month respectively, for the identical ambition.
Scale that across traffic levels and the shape of the program falls out on its own:
| Monthly visitors on tested pages | Tests per month (3 percent baseline, 20 percent relative target) | What that workload realistically implies |
|---|---|---|
| 50,000 | 1.8 | One owner, borrowing design and engineering time |
| 150,000 | 5.4 | One dedicated owner plus recurring, scheduled design and build support |
| 500,000 | 18.0 | A small dedicated group, with build and QA capacity that no longer fits in borrowed time |
| 2,000,000 | 71.9 | Multiple parallel squads, plus platform work so tests do not collide with each other |
Use the duration calculator to convert your own traffic into a calendar, which is usually the moment a hiring plan gets realistic:
Two-proportion normal approximation, traffic split evenly across variations. The date uses your timezone and updates live.
Step 2: what one test actually costs in work
Five jobs have to happen for every experiment, no matter who does them:
| Job | What it produces | Where it usually lives first |
|---|---|---|
| Research and hypothesis | A written hypothesis with a primary metric and guardrails, decided before the test runs | The program owner |
| Variation design | The change itself, at production quality | Borrowed from the design team |
| Build and QA | The variation live, tested across devices, with tracking verified | Borrowed from engineering, and the most common bottleneck |
| Analysis | A verdict with the interval, read at the planned end date | The program owner, or an analyst once volume grows |
| Documentation | The result in a repository, including ties and losses | The job most often skipped, and the one that compounds |
The Speero finding about knowledge bases is worth pairing with that last row: programs without a dedicated team overwhelmingly lack a repository, and decentralized teams frequently lack one too. Documentation is not the step to cut when the team is small, it is the step that keeps a small team from re-running work it already did.
Step 3: turn workload into people, and check it against capacity
The check that matters is simple: if the traffic supports roughly 5 tests a month, and each test needs a hypothesis, a design, a build, an analysis and a written record, that is a workload a dedicated owner can carry with reliable, scheduled support from design and engineering. It is not a workload that needs three specialists. Conversely, at 18 or more tests a month, build and QA stops being borrowable time and becomes a queue, which is precisely the “execution bottleneck” VWO’s report describes.
Centralized, embedded, or a center of excellence
Structure matters as much as size, and each model fails differently.
| Model | Where experimentation sits | Typical failure mode |
|---|---|---|
| Centralized team | One team owns strategy, execution and analysis | Becomes a queue, and product teams stop proposing tests because the wait is long |
| Embedded in product squads | Each squad runs its own experiments | Method drifts, and the Speero finding applies: 57 percent of decentralized teams reported no shared knowledge base, so work gets repeated |
| Center of excellence | A small central group owns method, statistics and the repository; squads execute | Only works if the center has real authority over how results are read, otherwise it becomes advisory decoration |
The pattern that holds across all three: whatever the shape, someone has to own the method and the memory. A structure where nobody owns the statistical read is how a program ends up with a high win rate and no revenue behind it, the failure pattern covered in how many A/B tests you should run per month.
Common mistakes when sizing a CRO team
| Mistake | Why it costs |
|---|---|
| Copying a headcount from a company with different traffic | Team size is bounded by measurable tests, and traffic sets that ceiling, not revenue or industry |
| Hiring specialists before an owner exists | The Speero maturity gap is about dedicated ownership; a specialist reporting to nobody inherits the same fragmentation |
| Staffing for test volume the traffic cannot support | Produces pressure to run underpowered tests, which inflates the win rate and deflates the realized effect |
| Treating the build step as free borrowed time | It is the step most likely to become the execution bottleneck once volume passes a handful of tests a month |
| Cutting documentation to move faster | Programs without a repository repeat work, and the data shows this is the norm rather than the exception |
| Counting agency headcount as a benchmark | Agency staff spread across many clients; only their throughput data transfers |
Automate this with Donnu
Two of the five jobs in the table above are pure overhead that a tool should absorb: sizing the test correctly before it starts, and reading the result honestly at the end. Donnu A/B does both by default, calculating the sample your traffic actually supports before the test runs, reporting the interval alongside the effect instead of a lone confidence number, and keeping each experiment on record with its numbers frozen as they were read. That does not replace a person who owns the program, and it is not meant to: it removes the two steps where a small team most often loses either time or credibility.
If your program is one person deep and you want that person spending their week on hypotheses rather than on spreadsheets, start a free 14-day trial and size the next test against your real traffic first.
References
- Speero. The State of Experimentation Programs 2023. Survey of 119 respondents to Speero’s experimentation maturity audit, source of the dedicated-ownership and knowledge base figures. speero.com/post/the-state-of-experimentation-programs-2023.
- Convert. CRO Agency Stats and the CRO Agency and Vendor Ecosystem Report. 237 agencies identified, 40 interviews and more than 200 survey responses; source of the 7 percent above 30 employees and 60 percent running two or fewer tests a month. convert.com/blog/optimization/cro-agency-stats.
- VWO. Experimentation Maturity Benchmark Report 2025-2026. Source of the 56 percent execution bottleneck figure; sample size not disclosed on the public page. vwo.com/ebooks/experimentation-maturity-benchmark-report.
- Kohavi, R. and Thomke, S. The Surprising Power of Online Experiments. Harvard Business Review, 2017. hbr.org/2017/09/the-surprising-power-of-online-experiments.
- Thomke, S. Building a Culture of Experimentation. Harvard Business Review, March-April 2020. hbr.org/2020/03/building-a-culture-of-experimentation.
Read also: How to build an experimentation culture · How many A/B tests should you run per month · The experimentation roadmap template · Experiment documentation: building a repository nobody ignores · CRO for low-traffic sites
Frequently asked questions
- What is the average CRO team size?
- There is no credible published average by company size, and anyone quoting one should be asked for the source. What the public data does show is different: Speero found that only 59 percent of surveyed programs strongly or somewhat agreed they had a dedicated person responsible for experimentation, and that on the stricter "strongly agree" reading the share rises from 17 percent at the least mature level to 92 percent at the most mature. In other words, the honest benchmark is not a headcount, it is whether anyone owns the program at all.
- How many people do you need to run a CRO program?
- Start from throughput, not from headcount. The number of tests your site can finish per month is capped by traffic and by the effect size you want to detect: a page converting at 3 percent, tested for a 20 percent relative improvement at 95 percent confidence and 80 percent power, consumes about 27,828 visitors per two-variation test. At 150,000 monthly visitors on tested pages that is roughly 5 tests a month, and 5 tests a month is a workload one dedicated person plus part-time design and engineering support can genuinely sustain. Hiring beyond what traffic can measure buys idle capacity.
- What roles does a CRO team actually need?
- Across any size, five jobs have to get done: research and hypothesis, design of the variation, build and QA, statistical analysis, and documentation of the result. In a one-person program all five sit with the same person, who borrows design and engineering time from other teams. As throughput rises past roughly ten tests a month, the build and QA job is usually the first to justify dedicated capacity, because it is the step that blocks everything downstream when it is late.
- Should CRO be centralized or embedded in product teams?
- Both models work, and the failure mode is different in each. Speero data points at one concrete risk in the decentralized case: 57 percent of decentralized teams reported not using a knowledge base to document experiments and insights, which is how the same test gets run twice in two squads. A centralized team concentrates method and memory but can become a queue everyone waits on. The practical middle is central ownership of method, statistics and the repository, with execution distributed.
- How big are CRO agencies, and does that tell you anything about in-house teams?
- Convert research that identified 237 CRO agencies globally found only 7 percent had more than 30 employees, and reported that 60 percent of agency practitioners run two or fewer tests per month. That is a useful reality check on expectations, not a template for in-house staffing: an agency spreads a small team across many clients, while an in-house team concentrates on one site with one traffic ceiling.
- What is the first hire for an experimentation program?
- A single owner, before any specialist. The Speero data on maturity shows dedicated ownership separating mature programs from aspiring ones far more sharply than any other resourcing variable, and the most common failure in a young program is not a missing statistician, it is that experimentation is everyone secondary responsibility and therefore nobody first one. The second hire should be decided by the bottleneck the first six months actually exposed, which is usually build capacity or analysis, not both.