When small beats big

I pulled a slide out of one of my startup talks when I wrote about “Autonomy vs Impact” a couple of weeks back. This is another installment — this time on the beauty of small teams.

In large companies, the importance of a project is often measured via the number of resources assigned. If its strategic, a high priority or business critical, the project has lots of developers. However, if you only have a few engineers at your disposal, then it can’t be very important. This often gives rise to the behavior of “resource pitching” — asking for too many resources, too early.

Sometimes this is necessary — especially when the vision is clear, the product market fit established and the main challenge is one of scaling. However, for early stage idea requiring innovation or stepwise change, large teams can be crippling.

Here’s a few thoughts on why that is.

Pivots make perfect

When you’re in an early stage project, pivoting is inevitable. Sometimes you have the right vision, but the wrong approach. Sometimes you have the right approach, but the wrong implementation. Sometimes you’ll even have the wrong vision. In any of these cases, a clean pivot is required — where you leave behind the direction of old and only carry forwards learnings, not baggage. It’s a hell of a lot easier to pivot cleanly when you only need to convince a handful of people to change direction. That’s not to say pivoting can’t be done with large teams — it can and has happened many times. It’s just more expensive in terms of time and energy. Both of these are precious resources in early stage projects, and you don’t want to spend them bringing people along.

The other benefit of getting several pivots out of the way early with fewer people involved is that once you’ve settled on the what you’re building (and the more importantly the why behind it), then it’s easier to hire people who can relate to that vision.

Maintaining communications

As the number of people on a project increases, the number of connections rises non linearly, or more specifically:

(n * (n-1)) / 2

This means we’ll see the following exponential increase in communication costs :

For a team of 5, the number of interpersonal connections is only 10. Double the team size to 10 and suddenly you’re at 45 connections. Double again to 20 people and now there are 190 connections to manage. At 40 people, the number of connections is 780

When communication increases exponentially, we tend to “solve” this problem via more management, more reviews and more status meetings — all of which take away from building. This is one of the reason for the “two pizza” rule that was popularized at Amazon, where two pizzas represent the # of people you can feed with two large pizzas (about 6 to 12 people). There’s a nice write up with more info on Amazon from a couple of years back here.

That covers two fairly obvious reasons. The other is more subtle and it relates to the psychology of abundance.

Don’t differentiate on table stakes

When resources are scarce, people will tend to naturally prioritize only the most critical things. This is out of necessity and creates the focus that is required for early stage products.

However, overconfidence and complacency can set in early when resources are freely available and can result in things that do not contribute to a product’s differentiation. So for example, imagine funding a new app idea with 20 people. At an early stage, there isn’t enough feature work to go around and so good PM’s / designers / developers will do what smart people do — they start building anyway. That excess energy often flows to all layers of the stack. Before you know it, someone is innovating on a data storage layer, someone else is forking UX frameworks and maybe a whole team of people are building some elaborate interop layer. Note, this isn’t a talent problem — ironically, I’ve found the intelligence of the individuals to actually compound, rather than solve this problem.

This has one obvious disadvantage of too few people working on actual differentiation. But it also means infrastructure investments can quickly escalate. Before you know it, that data storage layer needs an entire team and management chain to maintain it. The other downside is that the team isn’t taking advantage of cutting edge open source tech that might be available. resulting in not only more expensive software, but also lower quality and industry / ecosystem compatibility.

At the other end of the spectrum, now imagine starting with 2 people. What they’ll do is hopefully do the only thing that can — leverage the hell out of what already exists and build on top.

Of course, this is a caricature for illustrative purposes, but the general theme is one I’ve seen both close at hand and from afar time and again.


Some of these thoughts are equally applicable to mature / large scale projects, but I think especially important to be aware in the early stage of a product when success is already so fleeting. There’s nothing wrong with big teams — there are few things more exciting in our industry than adding talented PM’s, designers and developers on a product that is ready to scale. But ultimately, resources are a tool like any other, and we therefore must use them wisely.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.