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.
Quick Takeaways
Velocity Over Headcount
✓ Quadratic complexity: Communication paths grow with the square of team size—2 people = 3 paths, 12 people = 66 paths
✓ Hidden costs: Onboarding time, coordination overhead, context switching, reduced autonomy
✓ Microsoft study: Adding people to late projects makes them later—overhead exceeds benefits
✓ Velocity multipliers: Clear ownership, small batches, low friction, trust and autonomy
✓ Right size: As small as possible while still getting work done—quality beats quantity
✓ 3-person high-velocity team > 12-person struggling team
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.
FAQ
Q: What's the ideal team size for maximum velocity?
A: 3-5 people is often the sweet spot. Below 3, you lack redundancy and diverse perspectives. Above 5, coordination overhead grows significantly. Many high-performing companies (WhatsApp, Instagram pre-acquisition) stayed at 5-10 engineers while serving millions of users. Split into multiple small teams rather than growing one large team.
Q: How do I measure engineering velocity?
A: Measure outcomes, not outputs. Good metrics: (1) Deployment frequency (how often you ship), (2) Lead time for changes (time from commit to production), (3) Mean time to recovery (how fast you fix issues), (4) Change failure rate (how often deployments cause problems). Bad metrics: lines of code, hours worked, story points completed. Focus on flow, not volume.
Q: Should we use microservices to improve velocity?
A: Usually no, especially for small teams. Microservices add significant operational complexity that reduces velocity. Start with a well-architected monolith. Split services only when: (1) Different components need to scale independently, (2) Different teams need to own different services, (3) A specific component becomes a bottleneck. Most startups under 20 engineers shouldn't use microservices.
Q: How do we increase velocity without adding people?
A: (1) Clarify priorities—work on one thing at a time, (2) Reduce work in progress—finish things before starting new ones, (3) Improve tooling—invest in faster builds, better tests, easier deployment, (4) Eliminate meetings—protect maker time, (5) Reduce technical debt—refactor as you go, (6) Automate repetitive tasks. These often double velocity without adding headcount.
Q: When is it actually time to grow the team?
A: Only when: (1) Current team is at sustainable max capacity, (2) More important work exists than the team can handle, (3) Work is parallelizable, (4) You have leadership capacity to onboard properly, (5) You've maintained velocity with current size for 3+ months. Don't hire to fix velocity problems—hire when velocity is already good but capacity is maxed.
Q: Does remote work hurt velocity?
A: Not necessarily. Remote work can increase velocity by reducing interruptions and allowing focus time. However, it requires intentional communication practices: written documentation, async updates, clear decision-making processes. Remote works best for teams with strong documentation culture and autonomous individuals. Hybrid often has the worst of both worlds—coordination overhead without the benefits.
References
-
Brooks, F. (1995). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
-
Kim, G. et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
-
DeMarco, T. & Lister, T. (2013). Peopleware: Productive Projects and Teams (3rd ed.). Addison-Wesley.
-
Fournier, C. (2017). The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change. O'Reilly Media.
-
Lencioni, P. (2002). The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass.
-
Evans, J. (2020). The Outcome-Based Roadmap: A Practical Guide to Product Planning. Product Collective.
-
Belshee, J. (2012). Promiscuous Pairing and Beginner's Mind. Agile Conference.
Related Reading
- When 'Just Hire More Developers' Is Wrong Advice — Why adding people often backfires
- How to Fix a Slow Engineering Team — Practical speed improvements
- Why Avoid Over-Hiring — Staying lean intentionally
- Why Agile Fails for Many Startups — Process that actually works
- Tools Tech Teams Use to Ship Faster — Technology for velocity
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.