The founder was proud. "We've doubled the engineering team," he told me. "We're now twelve developers strong."
I asked how that had affected their output. "Well..." he hesitated. "It's a bit complicated."
What followed was a familiar story. Two new developers had joined. But features weren't shipping faster. If anything, things felt slower. More meetings. More coordination. More confusion about priorities.
The team had doubled. The output had not.
This is one of the most common mistakes I see startups make. They conflate resources with progress. They think more people means more done. And they learn the hard way that it's not that simple.
The Myth of Linear Scaling
There's an assumption that underlies most hiring decisions: two engineers should produce twice as much as one engineer.
This assumption is wrong.
Not just a little wrong. Fundamentally wrong.
Because engineering work isn't linear. It's quadratic. Not in a good way.
The number of communication paths between team members grows with the square of the team size. With one person, there's one communication path. With two, there are three. With four, there are six. With twelve... you do the math.
Every new person doesn't just add their individual output. They add new communication overhead. New context that needs to be shared. New coordination that needs to happen. New social dynamics that need to be managed.
The Hidden Costs of Growth
When you add a new engineer, you're not just adding their coding capacity. You're adding:
Onboarding time. The hours your existing team spends explaining how things work. The questions the new person asks. The mistakes they make while learning.
Coordination overhead. More people means more meetings. More decisions that need buy-in. More alignment that needs to happen.
Context switching. Each person can focus on fewer things, but there are more things to coordinate. The cognitive load of managing the team grows faster than the team's capacity.
Reduced autonomy. With more people, decisions need to be made collectively. Small decisions that one person could make now require discussion. The flexibility that made you fast is gone.
A study at Microsoft found that adding people to a late project made it later. The overhead of coordination exceeded the benefit of additional hands.
What High Velocity Looks Like
High-velocity teams aren't necessarily large teams. They're teams that have mastered a specific set of skills:
Clear ownership. Each component of the system has a clear owner. Decisions happen quickly because there's no ambiguity about who makes them.
Small batches. Features are built and shipped in small increments. This reduces risk, increases feedback, and keeps the system stable.
Low friction. The path from idea to production is short. Testing is easy. Deployment is automated. Nothing stands between a developer and shipping.
Trust and autonomy. Team members make decisions within their domain without needing approval. They're trusted to make good choices.
A team of three with these qualities will often outperform a team of twelve without them.
The Velocity Multipliers
Here are the factors that actually increase velocity:
| Multiplier | Effect |
|---|---|
| Clear priorities | Focus on one thing at a time |
| Good tooling | Less time fighting infrastructure |
| Automated testing | Confidence to change things |
| Small codebases | Easier to understand and modify |
| Autonomous teams | Faster decision making |
The Right Size Question
So what's the right team size?
The answer is: as small as possible while still getting the work done.
Not as large as your funding allows. Not as large as your competitors. As small as possible.
A two-person team that ships consistently will beat a ten-person team that struggles to coordinate. Every time.
I've watched startups raise money and immediately double their team. I've watched them struggle for months afterward, trying to integrate new people, dealing with coordination overhead, losing the velocity they had when they were small.
The smart ones learn to be cautious about growth. They hire slowly. They hire for culture fit as much as skill. They understand that adding people is a last resort, not a first response.
When Growth Does Make Sense
There are times when adding people makes sense:
When you have more work than your current team can handle, even at maximum efficiency. When the work is parallelizable, meaning multiple people can work on different things simultaneously. When you have the leadership capacity to onboard and integrate new people.
But even in these cases, grow slowly. Add one person at a time. Make sure each new person actually increases output before adding another.
The Bottom Line
The goal isn't to have a large team. The goal is to make progress.
A large team that moves slowly is just an expensive way to stand still. A small team that moves quickly is a competitive advantage.
Focus on velocity. Not headcount. Not impressive org charts. Not the number of engineers you can brag about at parties.
Velocity is what matters.
Need Help Increasing Your Velocity?
At Startupbricks, we help startups build teams that ship. If you're trying to figure out why your team isn't as productive as it should be, let's talk.