Hiring guide
How to Scale an Engineering Team from 10 to 50
Ten engineers is a team you can hold in your head. Fifty is an organisation. The distance between the two is where a lot of otherwise strong companies come unstuck, because the thing that changes is not the hiring target, it is everything around it: structure, communication, and how much new capacity the team can actually absorb.
I spend most of my week with founders and engineering leaders going through exactly this. Here is what genuinely matters, and what tends to get skipped.
The maths nobody does
Most scaling plans start from a number (“we need 40 engineers by Q3”) and work backwards to a hiring rate. Almost nobody works backwards from the constraint that actually binds, which is onboarding capacity.
Published figures put typical time to productivity at two to four weeks where onboarding is structured, and three to six months where it is not. One dataset covering around 400 companies puts the average time to a new engineer’s tenth pull request at roughly 33 days. Whatever the number is in your team, it is not zero, and every new starter also consumes senior engineering time that is no longer going into shipping.
So there is a rate above which hiring makes you slower. If you add people faster than the team can absorb them, you get a larger organisation producing less, and the usual response, hiring more, makes it worse. Work out how many people your senior engineers can genuinely bring up to speed at once, and treat that as the ceiling. It is usually a smaller number than the board deck assumes.
Structure has to change, twice
At ten engineers, one layer works. Somewhere between twenty and fifty it stops working, and you need a second layer: directors or senior managers owning groups of teams. The CTO’s job changes at the same moment, from hands-on technical leadership to organisational design, hiring strategy and cross-team coordination. Leaving that shift too late is the more common error, and it looks like a leadership team permanently firefighting.
Span of control is the number to watch. The working average across 445 companies studied by Jellyfish is about one manager per five engineers, and spans wider than 1:8 correlate with higher turnover. Six to eight reports is a sensible ceiling when the work is similar. The practical test is simpler than the ratio: if a manager cannot tell you what each of their reports is working on and how they are doing, the span is already too wide.
The second structural change, usually around forty to fifty, is separating the tracks. Staff engineers own technical direction inside a domain; engineering managers own team health, delivery and people. Conflating the two costs you your best engineers, who get promoted into management they never wanted, and leaves teams with managers who are still trying to be the strongest coder in the room. Our guide on when to hire your first engineering manager covers the first half of that decision; by this stage you are making it repeatedly and deliberately.
Protect the bar, especially when it hurts
The compounding risk in a fast scale-up is a mediocre senior hire. That person goes on to screen candidates, set technical standards and manage people, so the ceiling they set becomes the ceiling for everyone downstream of them. One weak hire at ten engineers is a problem. The same hire at the start of a push to fifty is a multiplier.
The defence is boring and it works: one consistent, structured assessment for every candidate at every level, owned by someone who will not move it under pressure. Keep the loop short at the same time, because a slow process loses exactly the people you most want, which is the tension our guide on reducing time to hire is about.
Where we fit
Hiring at this pace is a different job from hiring one engineer at a time, which is why embedded recruitment exists: a recruiter working inside your team, running the volume without diluting the standard. For the leadership layer the same scale-up needs, that tends to be retained search, and the roles themselves are usually engineering managers and CTO or VP Engineering hires.
Budgeting the plan is worth doing properly too: our UK tech salary statistics show what each level actually costs in 2026, so a headcount plan survives contact with the market.
If you are heading from ten to fifty and want the hiring to keep pace without the bar slipping, talk to us. Every engineer we put forward is assessed by people who have done the job.
FAQ
Frequently asked questions
How many engineers should each manager have?
Research from Jellyfish across 445 companies puts the working average at roughly one manager per five engineers, and finds that spans above 1:8 correlate with higher turnover. Six to eight reports is a practical ceiling when the work is similar. Past that you lose signal: decisions queue behind one person, problems surface late, and good people quietly feel unsupported. Treat the ratio as a symptom check rather than a target, if a manager cannot describe what each report is working on, the span is already too wide.
When do you need a second layer of management?
Usually somewhere between 20 and 50 engineers, when a single manager layer can no longer hold the whole org. That is the point where directors or senior managers start owning groups of teams, and the CTO's job shifts from hands-on technical leadership to organisational architecture, hiring strategy and cross-team coordination. Adding that layer late is the more common mistake, and it shows up as a leadership team that is permanently firefighting.
How fast can you actually hire without breaking the team?
Faster than most people hire, but slower than most plans assume. The constraint is not the pipeline, it is onboarding capacity. Published figures put typical time-to-productivity at two to four weeks with structured onboarding and three to six months without it, and one dataset of around 400 companies puts the average time to a new engineer's tenth pull request at about 33 days. Every hire also consumes senior time, so a team that adds people faster than it can absorb them gets slower before it gets faster.
How do you keep the quality bar while hiring at volume?
Decide who owns the bar and do not let urgency move it. The compounding risk is that a weak senior hire influences later hiring and sets the ceiling for everyone they screen or manage. Keep a consistent, structured assessment for every candidate at every level, keep the loop short so strong people do not drop out, and accept that an unfilled role is cheaper than a wrong one at this stage.