The Small Team Advantage

There’s a recurring pattern in technology that I think is underappreciated: the best products tend to come from the smallest teams.

Not always. There are categories where scale is the product — cloud infrastructure, search engines, large language models. But for the vast majority of software, the optimal team size is shockingly small, and getting smaller.

What small teams actually do differently

At Workstream, some of our best features were built by two or three people who understood the problem deeply. Not because we couldn’t hire more people, but because adding people would have made the work worse.

Small teams have a communication advantage that compounds. Two people don’t need a project manager, a standup, or a Jira board. They can hold the entire problem in their heads simultaneously. When you add a third person, you’ve tripled the number of communication paths. By the time you have eight people, there are 28 possible pairs who might need to sync, and inevitably you start building process to manage the complexity that the team size itself created.

I watched this happen at Google. Brilliant engineers spending 40% of their time in meetings about the work, and maybe 60% doing the work. The meetings were “necessary” — but only because the team was large enough to need them.

The AI inflection point

What makes this especially relevant now is that AI is dramatically expanding what a small team can do. A developer with good tools and AI assistance can build in a weekend what used to take a team of five a quarter.

This doesn’t mean we need fewer people. It means we need fewer people per initiative. A company of 50 can now pursue 25 ideas in parallel instead of 5. The constraint shifts from headcount to taste and judgment — knowing which of those 25 ideas is worth pursuing.

This is a profound shift. For the last two decades, the startup playbook has been: find product-market fit, then scale the team to capture the market. What if the new playbook is: find product-market fit, then scale the tooling so the same small team can capture the market?

What this means for founders

If you’re building something now, my honest advice: resist the urge to hire ahead of the work. Keep the team as small as possible for as long as possible. Invest heavily in tooling, AI, and automation. Let each person own a large surface area.

The advantage of being small isn’t just cost efficiency. It’s that small teams make better decisions. They can change direction in an afternoon. They don’t need consensus because everyone already has context. They can ship something on Tuesday that they thought of on Monday.

At YC, the advice was always “do things that don’t scale.” I’d add a corollary: stay small enough that you can do things fast. Speed is the real advantage of small teams. Not just speed of execution, but speed of learning. You ship, you observe, you adjust. The cycle time is days, not quarters.

The uncomfortable truth

There’s an uncomfortable implication here for the industry. If small teams with good tools can build what large teams used to build, a lot of organizational complexity in tech companies is not just unnecessary — it’s actively harmful. The meetings, the layers, the roadmap reviews, the alignment sessions — these exist because the teams are big, and the teams are big because… well, because that’s how it’s been done.

I’m not arguing that every company should be five people. But I think the default assumption should be smaller, and you should have to justify every additional person as a multiplier rather than an addition.

The companies that figure this out first will have a structural advantage that’s very hard to compete with. They’ll be faster, more coherent, and — counterintuitively — more ambitious, because small teams that move fast tend to attempt things that large teams would committee into oblivion.