Headcount-based testing services are easy to understand commercially: you buy people for a period of time. They can also create an awkward incentive where efficiency reduces the supplier’s revenue and every new problem arrives with a surprisingly familiar solution: more people.
The answer is not to declare headcount evil. Sometimes you genuinely need ten capable testers. The answer is to make sure you are buying capacity because capacity is the constraint, not because bodies are the easiest thing to count. Headcount is a wonderfully simple product: easy to count, easy to invoice and remarkably difficult to connect to outcomes.
If your service keeps growing and nobody can explain why in terms of useful demand, we can review the workload and commercial model before you approve the next batch of names.
Baseline the work before the people
Identify the genuinely useful testing demand: releases, products, critical journeys, specialist work, regulatory obligations and predictable peaks. Then look at the effort required and where it is constrained. Otherwise the supplier can keep growing while meeting SLAs without delivering a useful service.
Do not use the existing team size as evidence of the required team size. That is how last year’s staffing decision quietly becomes this year’s capacity model.
Separate permanent demand from peaks
A large migration, platform change or regulatory release can justify temporary capacity. Routine product delivery may need a smaller stable team. Specialist testing may be better bought when required rather than embedded forever in a generic service.
Ask when additional headcount is expected to leave. If every temporary uplift becomes baseline, the service has discovered organisational gravity.
Make productivity improvements commercially possible
If automation, better environments or reduced regression remove work, the model should allow the team to shrink or redirect effort without creating a contract dispute. Otherwise both parties are trapped: the client wants efficiency and the supplier is punished for delivering it.
If every problem is solved by adding two more people, eventually the test team becomes the largest feature in the system.
That can mean capacity bands, clearer outcome-based work packages, separate specialist call-off, periodic resizing or simply an explicit expectation that headcount can move down as well as up.
Keep knowledge with the organisation
A headcount service can become hard to reduce when critical product knowledge exists only inside the supplier. Make sure test assets, automation, data knowledge, environment knowledge and domain understanding are documented and shared enough that resizing does not feel like pulling out a load-bearing wall.
You are buying a service, not adopting a dependency.
Ask what fewer people would force you to stop
Before approving growth, ask the supplier what it would stop, simplify or change if headcount stayed flat. A useful answer might reduce regression, improve automation, fix environment waste, narrow low-risk scope or change release sequencing.
If the only alternative is described as uncontrolled catastrophe, ask whether the solution space has been narrowed by the commercial model.
Buy the thing you actually need
Capacity is legitimate. Specialist expertise is legitimate. Independent judgement is legitimate. The mistake is buying all three through the same unit of “number of people” and then wondering why the answer to every problem has a payroll implication. Buy capability or outcomes when you can. Bodies are useful, but they are a terrible unit of confidence.
A healthy service should be able to explain why each capability exists, what demand it serves and what would cause it to grow or shrink.