Growing a team without breaking it
Doubling a team is the fastest way to halve its output for two quarters. What I have learned about pacing growth, protecting the people already there, and the number I watch instead of headcount.
I was once told, in a single planning meeting, that my team of eight would be sixteen by the end of the year. It was meant as good news. It was, in the way that a large delivery of wet cement is good news for a builder.
The team hit sixteen. Output for the following two quarters was lower than it had been at eight. Not per person. In total. The senior engineers were interviewing, onboarding, and reviewing all day, and nobody was left to do the work the new people had been hired to accelerate.
Growth has a cost, and the cost lands first
Every person added to a team costs capacity before they add any. Someone has to interview them. Someone has to onboard them. Their first months of pull requests take longer to review than they would have taken to write. Their questions land on the people who know the most, who are also the people whose time is worth the most.
The rule I use now is that a team can absorb roughly one new person per four existing engineers per quarter without losing ground. Faster than that, and the existing team spends more time on growth than on work. The number is rough and it has been right more often than any plan that ignored it.
Grow in a shape, not a number
Headcount is the wrong unit. The question is not how many people but what the team is missing. Before I open a role, I write down the gap: the thing the team cannot do, or cannot do fast enough, that this person would fix. If I cannot name the gap, the role is a wish, and wishes turn into people who arrive and wonder why they were hired.
The shape matters too. Adding four junior engineers to a team of four seniors doubles headcount and roughly triples the review and mentoring load. Adding two seniors and two juniors adds the same headcount with a fraction of the drag. I pay attention to the ratio, and I hire for it deliberately.
Protect the people already there
The people most at risk during rapid growth are the ones who made the team worth growing. They get pulled into interviews, their focus time disappears, and their relationship with the manager thins as the manager's attention spreads across twice as many people.
I do three things about that. I cap interview load per person per week, and I rotate it. I protect at least two full days a week of no interviews, no onboarding, no meetings for the senior engineers. And I keep their 1:1s at the same length as before, because the moment those get cut is the moment they start noticing the team they joined is gone.
Split before it gets loud
A team above about eight people starts to lose the thing that made it a team. Standups get long, decisions need more people, and the newest members cannot tell who to ask. The signal is usually social before it is structural: side conversations, two groups forming, a sense that the meeting is for someone else.
I split a team at nine or ten, on purpose, with a clear line between the two halves and a lead for each. The split is uncomfortable for about a month. The alternative is a team of fourteen that is really two teams pretending, with all of the coordination cost and none of the clarity.
The number I watch
I stopped tracking headcount as the measure of growth. The number I watch is time to first meaningful contribution for new hires, and throughput per person on the existing team. If the first goes up or the second goes down while the team grows, we are growing faster than we can absorb, and the fix is to slow down, not to hire more.
What changed with AI
The year we moved to an AI first way of working, the growth math changed in one specific way: new engineers became productive much sooner. The parts of onboarding that used to take a month of reading and asking, where is this pattern, how does this service work, what does this config do, became an afternoon of questions to the tool. New hires were shipping production code in week two.
That did not remove the cost of growth. Review load went up, not down, because generated code needed careful reading. But it shifted the bottleneck from the new person's ramp to the team's capacity to review, and that is a bottleneck you can plan for.