How many developers do you actually need? A CTO's decision framework

A UK scaleup CTO we spoke with recently ran into something we hear in nearly every conversation we have with engineering leaders. A deadline was approaching, the backlog wasn't shrinking, and the board wanted to know why. The assumption is always the same - hiring two more Engineers will sort the problem out. The bottleneck actually was that every pull request sat in review for two days because only one Senior Engineer was trusted to approve them. Two more hires would have meant two more people queuing for the same bottleneck.

Most of the sizing decisions fall into the same question: "How many developers do we need?” Usually asked in this way, it feels like a headcount question, so it gets answered with a headcount number. But the question underneath it is really about capacity versus capability, and until you've separated the two, any number you land on is a guess with a budget attached.

This is the framework we walk CTOs through before a single job spec goes out: the maths that predicts team size, the audit that shows where your real constraint sits, and the point at which more developers is genuinely the right call.

Why "How Many Developers" is the wrong first question

Headcount is easy to ask for and easy to approve. It shows up as a clean number in a budget meeting, and "we need three more Engineers" is much easier to say than "our review process is the bottleneck and our CI pipeline needs work."

But headcount only solves the problem if the problem is genuinely a lack of hands. Most of the time it isn't. It's unclear ownership, a fragile deployment process, or a team that has to route every non-trivial decision through one or two people. Adding more Engineers on top of that is not equal to getting more output. You get more people waiting on the same bottleneck, plus the onboarding and coordination cost of getting them there.

We covered this properly in our capacity vs capability framework: capacity is how many hands you have, capability is what those hands can actually build together. Understanding the difference between the two terms is crucial. Plus, sizing a team means answering both questions, not just the first one.

Start with the outcome, not the headcount

Before trying to answer the question “how many”, first define what actually needs to be true. What has to ship, by when, and what does "done" look like? It is important to note here that a sizing decision made against a delivery target produces a team built to hit that target, and a sizing decision made against a headcount target produces exactly what it's aimed at: more headcount.

This sounds obvious until you sit in the budget meeting where the question being asked is "how many people should we add this quarter" rather than "what do we need to ship this quarter, and what does that actually require." The second question is harder to answer, which is exactly why it gets skipped.

The three numbers that actually predict team size

Once the outcome is defined, three variables do most of the work in deciding how many Engineers that outcome actually requires.

1. Scope parallelism

Can the work be split cleanly across multiple people, or does it depend on one core system being built first? Genuinely independent features (a new dashboard, a separate API integration, a self-contained UI flow) parallelise well. Features that depend on one shared engine or data model don't. Adding developers to sequential work doesn't speed it up. It just adds people waiting for the same dependency to unblock.

1. The communication tax

This is Brooks's Law, quantified. Every person added to a team increases the number of communication links between team members, and it grows faster than headcount does. The formula is N(N-1)/2, where N is the number of people on the team.

• A team of 4 has 6 communication links.
• A team of 6 has 15.
• A team of 8 has 28.

When you are doubling the team from 4 to 8, you don't double the communication overhead; you increase it by more than four times. This is why a team that "should" move twice as fast with twice the people often doesn't move much faster at all, and why the strongest engineering organisations tend to keep individual teams small and split scope across squads rather than growing one team indefinitely.

3. The overhead ratio

Only a portion of an engineer's working hours is dedicated to shipping new features. QA, code review, incident response, dependency upgrades and general maintenance all draw from the same capacity pool. In practice, once this overhead is fully accounted for, pure feature development typically consumes no more than 60% of an engineering team's total output capacity. A team of five isn't five people's worth of feature output. It's closer to three.

If you bypass this step, headcount projections rely solely on the raw count of Engineers instead of the actual hours available for delivering features. As a result, even a team that appears "fully staffed" can end up failing to hit its roadmap targets.

Stage-based team sizing: what actually works at each phase

There isn't a single right team size, but there is a reasonably consistent pattern by product stage, echoed across most engineering leadership guidance:

These stage bands line up closely with the guidance in Amazing CTO's breakdown of developer headcount by product lifecycle, and with the ratio guardrails we cover in our capacity vs capability article mentioned above: engineering leader Will Larson's widely referenced guidance on sizing engineering teams suggests 6 to 8 Engineers per manager, with a minimum viable team of around 4. Amazon's two-pizza team principle works for the reason. Teams should be small enough to stay coordinated, without much time spent on talking. They should also be big enough to take ownership of meaningful work.

Treat these as guardrails, not targets. They tell you when a team is likely to be too small to function or too large to coordinate. They don't tell you whether the team you have can actually deliver, which is the next question.

The four-question capability audit

Before adding anyone, it's worth scoring the team you already have against four questions. We go into this in more depth in our capacity vs capability framework, but the short version is this:

1. Skill depth. Can your Engineers solve unfamiliar problems independently, or does most non-routine work funnel through one or two people?
2. System maturity. Is your CI/CD pipeline, test coverage and deployment process solid enough that shipping becomes routine?. Does every release still need manual babysitting?
3. Autonomy. How much work moves forward without waiting on approval or a manager to unblock a decision?
4. Judgement. When Engineers hit an ambiguous situation, do they make a reasonable call and move, or does the whole team stall?

If your team scores poorly on two or three of these, adding headcount will not fix the problem; it will simply make the problem larger. The bottleneck is not the number of people. The bottleneck is everything around them.

Sizing engineering teams in the UK's hiring market

The maths above matters even more if you're hiring in the UK specifically. A Senior Software Engineer in London, Bristol or Manchester typically takes three to six months to hire once interview loops, competing offers and notice periods are factored in, and UK senior engineering salaries have kept climbing even as budgets have tightened. That's an expensive, slow way to find out whether "more developers" was ever the right answer.

It's part of why we moved our own Commercial HQ to Bath earlier this year. In almost every discovery call, UK CTOs raise this precise question. The candid answer is far more often "fewer, highly senior Engineers" instead of embarking on yet another prolonged local search. Instead of automatically opening a new request for a junior role due to a growing backlog, a capability-first approach to UK engineering recruitment begins with an audit of your current team. From there, you address specific skill gaps by bringing in senior talent - whether through a direct local hire or an integrated technical team.

A practical decision framework: 5 steps to size your team

Bringing the above together, here's the order of operations that actually holds up under budget pressure.

1. Step 1: Define the outcome and the deadline. What needs to ship, and by when. Focus on the outcome. 
2. Step 2: Run the capability audit. Score your current team against skill depth, system maturity, autonomy and judgement. In this way, you will understand whether the constraint is the people or the process. 
3. Step 3: Calculate the real numbers. Assess the degree of work parallelisation, account for the 60% overhead factor to establish your true feature-delivery capacity, and pinpoint any remaining gaps.
4. Step 4: Check the shortfall against the ratio guardrails. Use 6 to 8 Engineers per manager and a two-pizza-sized squad (roughly 4 to 9) as sense checks, not formulas.
5. Step 5: Decide between volume and capability. If the gap is genuinely more hands-on, genuinely parallel work, hire for volume. If the gap is skill, ownership or system maturity, hire fewer, more senior Engineers instead, or invest in the systems that are actually slowing the team down.

Does AI change how many developers you need?

AI is changing the maths, but not the process. The AI coding tools genuinely increase what one strong Engineer can produce in a day, which is part of why we've been talking to more CTOs about smaller, more senior teams than about bigger ones. A task that needed three or four people two years ago can now often be handled by one senior developer with the right judgement and the right tooling.

The catch is that this only holds for Engineers with strong judgement. Someone who uses AI to produce more code faster, without reviewing it critically, just produces more problems faster for someone else to untangle later. AI increases capacity, but it doesn't automatically increase capability. Thus, the gap between an average Engineer and an elite one gets wider, not narrower, once AI is in the mix.

Practically, this means the capability audit above matters more in 2026 than it did five years ago, not less. It's now easier than ever to mistake a higher volume of output for a more capable team.

When more developers actually is the right call

None of this is an argument for never hiring. Sometimes the honest answer really is more people, and it's worth being specific about when.

• The work is genuinely parallel, and you have more independent, well-scoped streams than people to run them.
• The capability audit comes back clean, and the team is still short of the outcome on realistic, overhead-adjusted capacity.
• You have a true skills gap your existing Engineers can't close through training or time. Security, ML infrastructure and niche platform work are common examples.
• You need coverage, not output. On-call schedules, vacation coverage and the risk of bus-factor are reasons to add more people even when a smaller team could actually deliver the same features.
• Firm, external deadlines (such as contractual obligations or regulatory milestones) leave no time for workflow optimisations to bridge the schedule gap.

The point isn't to default to "fewer people, always." It's to make sure headcount is the answer to a question you've actually tested, rather than the first idea that came up in the budget meeting.

Size for what you need to build, not what feels safe

A bigger team is an easy thing to justify upward and a hard thing to walk back once it's approved. The framework above exists because "how many developers do we need" is rarely the real question. The real question is what has to ship, what's actually stopping it, and whether more people solve that or just make the coordination problem bigger.

Run the outcome definition, the capability audit and the maths before the job spec goes out, and you'll generally end up with a smaller, more senior answer than the one you started with. If your next hiring decision is really a capability question wearing a headcount request, that's exactly the audit we help CTOs run before they write a single job spec. Talk to TechPods about finding the two or three Elite Engineers who would actually move your roadmap, instead of the ten who would just sit on it.