Every struggling project in history has had some executive look at the timeline, panic, and say the same thing: “Let’s throw more people at it.” It’s such a comforting idea. More hands, faster work. More brains, better solutions. It makes intuitive sense, which is exactly why it’s wrong.
Fred Brooks figured this out in 1975 when he wrote The Mythical Man-Month. His observation was brutally simple: adding people to a late software project makes it later. Not a little later. Meaningfully, measurably later. And yet here we are, 50 years on, and companies are still making the same mistake. They see a deadline slipping and reach for the hiring button like it’s a panic switch.
Here’s the thing about teams. When you add a person, you don’t just add their output. You add every communication channel between them and everyone else. The formula is n(n-1)/2, where n is your team size. A team of 5 has 10 communication channels. Bump that to 10 people and you’ve got 45 channels. Go to 50 people and you’re drowning in 1,225 channels of potential miscommunication, meetings, and alignment sessions. That’s not productivity. That’s bureaucracy wearing a lanyard.
The military worked this out centuries ago. When you need something done with precision, speed, and zero margin for error, you don’t send an army. You send a small team of highly trained people who can make decisions without filing a change request.
David Stirling understood this when he formed the SAS in 1941. His reasoning was straightforward: small teams of well-trained soldiers could achieve more than larger conventional forces. The top brass hated it. They called it ungentlemanly and piratical, not how British officers should behave. Stirling’s response was to go out and prove them catastrophically wrong.
In just over a year, the SAS destroyed more than 400 Axis aircraft. That’s more than any Allied fighter squadron. A handful of soldiers in cheap vehicles, maintained by a few mechanics, caused more damage than entire air wings. Rommel himself said the SAS caused him more harm than any other Allied unit of similar size. These weren’t suicide missions either. The small team approach meant they could strike anywhere, hundreds of miles behind enemy lines, then vanish before anyone knew what happened.
By 1944, an estimated 300 SBS soldiers were holding down the equivalent of several German divisions. Not because they were superhuman, but because small, autonomous teams with clear objectives can move faster than any command structure can respond to them.
The same principle plays out in business, just with less explosives and more Slack messages.
When Facebook bought WhatsApp for $19 billion (a number that still makes me do a double-take), the company had 32 engineers serving 450 million users. That’s roughly 14 million users per engineer. Instagram had 13 employees when it sold for $1 billion. YouTube had 65 when Google acquired it. These weren’t companies that couldn’t afford to hire. They were companies that understood something most don’t: adding people would have slowed them down.
Jeff Bezos codified this with Amazon’s two-pizza rule. If you can’t feed the team with two pizzas, it’s too big. That works out to about six or seven people, which lines up remarkably well with what productivity research keeps telling us. Studies show teams above 9 people are measurably less productive than smaller ones. Harvard psychologist J. Richard Hackman puts the magic number at 5 and actively warns against going above 10.
Why? Because small teams have something large teams can never have: shared context. When everyone knows everything, you don’t need alignment meetings. You don’t need documentation for documentation’s sake. You don’t need a project manager whose entire job is translating between people who should just be talking to each other.
There’s also something called the Ringelmann Effect. As teams grow, individual effort decreases. People assume someone else will pick up the slack. In a team of 5, there’s nowhere to hide. Everyone knows who’s pulling their weight and who isn’t. That visibility drives accountability in a way that no amount of performance reviews or OKRs ever will.
Brooks had a perfect analogy for why you can’t just add people to speed things up. It takes one woman nine months to make a baby. Nine women can’t make a baby in one month. Some work simply isn’t parallelisable. Most knowledge work falls into this category. You can’t have three people simultaneously think through the same architectural problem and expect to get an answer three times faster. You’ll get three different answers, a meeting to debate them, and a compromise that satisfies no one.
The ramp-up problem compounds this. Every new person needs to learn the codebase, understand the context, and figure out how decisions get made. That learning requires time from people already on the project. So you’re not just adding capacity, you’re temporarily reducing it. The new person isn’t productive yet, and the existing team is less productive because they’re doing onboarding instead of building.
I’ve watched this play out more times than I can count. A project falls behind. Management adds five people. Three months later, the project is further behind than before, and now there are five more people in every meeting who need everything explained to them. The original team is exhausted from context-switching between their actual work and bringing newcomers up to speed.
The solution isn’t always fewer people. It’s right-sized teams with clear ownership and the autonomy to make decisions. Amazon’s two-pizza teams work because each one owns a specific thing end-to-end. They don’t need to coordinate with twelve other teams to ship a feature. They don’t need permission from a committee. They decide, they build, they ship.
This is why startups consistently outmanoeuvre larger competitors. It’s not that big companies are full of incompetent people (though sometimes, sure). It’s that coordination costs scale exponentially while output scales linearly at best. A 10-person startup can ship in a week what takes a 200-person team a quarter, because the startup doesn’t need to schedule a meeting to schedule a meeting.
If you’re leading a team that isn’t shipping, ask yourself: is the problem that we need more people, or is it that we have too many? Could two people with full context and clear ownership do this faster than eight people with partial context and shared responsibility?
The answer is almost always yes. Small teams get shit done. Large teams get meetings done.