In Praise of Overstaffing
Sometimes, you want a bigger team, even if it is messier and less focused.
”Smaller teams are faster” is now deeply conventional wisdom. We have heard that three brave souls with inspiration, passion, and talent can change the world. They will turn on a dime, and produce a product that blows away a big corporate team with a departmental org chart. Those big teams are slow. They spend weeks or months just talking to each other. Your software teams should start small, and grow only until they fit around one pizza box.
I don’t use this conventional wisdom when I commit to a new software project. I like to hire a lot of people — ten or more. I also like to engage an extended team of customers and partners. This actually leads to a faster start. We can see who works out. Then, we trim the team back to what we need and can afford.
The conventional wisdom is often correct. But, it won’t apply in all situations. The beginning of a software project is a unique situation with a unique opportunity to bring in new people.
Starting a software project
The most efficient way to start a software project is to write it yourself, or persuade the best programmer you know to write it. One great coder can be very efficient. As soon as you add a second person, the efficiency drops. You might assume that efficiency will keep dropping as you add 2, 5, 10 more. Let’s analyze why this might or might not happen.
There are two main theories about why software development gets slower as projects get bigger.
1) Communication complexity
When you have more people, they might spend more time talking to each other and less time producing code. This is the commonly accepted theory of software scaling problems that was proposed by the masterful Mythical Man Month in 1975. N people creates N² conversations. If each conversation takes time, then teams will get a LOT less productive as they get bigger.
This theory fit well with the productivity data in 1975. I don’t think it holds for modern projects. Open source projects can accept code from thousands of contributors without generating an excess number of conversations.
A modern version of this theory would make a different point — that productivity gets slower if you add people, because those people don’t know what to do. You have to spend a lot of time explaining it to them. This is a time suck for managers and programmers under pressure. They don’t want to deal with a lot of newbies.
Key insight: At the beginning of a project, nobody knows what they are doing. Everyone has to figure it out. So, there is no time lost explaining it to them.
2) Dependencies
My favorite explanation for the lower productivity of large projects is “dependencies” — things that you are waiting for. One person is never waiting for him/her self. If you have 100 people, it’s pretty easy to run into situations where 99 of them are waiting for one person to finish something important. That creates a 100X productivity reduction.
The dependency theory explains why open source projects scale so well. If you need an open source component, you have the option of making it yourself rather than waiting for it. A new project is like an open source project. An individual that needs something has to make it.
Key insight: At the beginning of a project, nobody is waiting for anything specific in the product. It takes time for the shared components to pile up, and for people to start to use them and depend on them.
We have assumed that as software projects get bigger, they get slower. That is no longer true! Now we know how to manage dependencies automatically. We found the silver bullet that makes it possible to run huge software projects run almost as efficiently as small microservice teams. Read the article to learn how this works.
When bigger is better
A bigger team is more expensive. But, it will give you some advantages:
- Lower risk. About 50% of new hires do not work out. When you have a very small team, these misses are very damaging. You will be constantly stressed about about whether you are making the right choice with each new hire. When you have a bigger team, the risk of each hire is much less.
- Faster staffing. If you are taking less risk with each new hire, you can make decisions faster.
- More diversity of thought, ideas, and solutions. If you have a small team, you will make a commitment to one person’s proposed architecture. That often creates problems later. You can improvements from considering a wider range of options.
- More room to grow talent. You have room to bring in some people that don’t have the exact right technical skills, and see how fast they learn and get traction. For me, this is the most important factor. If you can hire for talent and not for specific skills, you can get huge payoffs within months.
Launching a startup company
Startup companies are like software projects, but more complicated. In addition to product development (often software development), you need to improve your design and customer impression, and find customers and investors. This leads to the recommendation for a minimal team of “hacker, hipster, hustler” with one person to cover each of these three areas.
The argument for a small team is that it is cheaper, and it is faster.
A smaller startup team is definitely cheaper. That’s important, because most startups fail. You don’t want to spend big money on a big team until you know there is a demand for their product.
It’s not clear that a smaller team is faster. They can make decisions faster and respond more quickly to new information. However, carefully assembling a small team can take more time than rapidly onboarding and trying a bigger team. The smaller team will not collect as much new information as a bigger team would collect. A bigger team would include people who deal with more different constituencies — customers, marketing channels, sales channels, investors. We might find that a small team takes longer to figure out things serially — find the right mix of founders, build a product prototype, try it with customers, figure out a channel. It might be possible to do those things in parallel.
A slower process literally costs startup team members their lives. 80–90% of startup projects do not achieve their goals. A startup team can spend several years of their life on something and USUALLY it will not work out. This keeps them from moving to a potentially more lucrative project and reduces the probability that they will ever get a big payout. If a bigger team can shorten the time to a go/no-go result, that saves money for investors, and precious time for founding team members.
It doesn’t cost much from an investor point of view. Investors make all of their money from huge wins. It’s almost impossible to exaggerate the impact of big, unicorn exits on investor returns. One Zoom or Snowflake pays for 1,000 less successful seed stage startups. A small percentage increase in the probability of a big win easily justifies spending more at the seed stage. Having a bigger team earlier is an advantage in scaling.
Conclusion
Conventional wisdom is not always correct. I believe that we can start software projects with big teams, and not lose time. And, we will gain advantages such as lower risk, faster staffing, more diversity of solutions, and more room to grow talent.
This approach can also apply to startups.
