MBA Mondays: Optimal headcount at various stages

(Fred Wilson is a VC at Union Square Ventures, based in NY. In this opinion piece, he writes about the value of being resource constrained in the early stages of building a company.)

This is the third post in the MBA Mondays series on People. The number of people you have in your company at any time is a very important part of getting the company building process right. Too many and you will slow things down, burn through too much cash, and increase management overhead for no real benefit. Too few and you will be resource constrained and unable to grow as fast as you'd like.

I will say upfront that different types of businesses will require different employee bases and that my experience is really limited to software based businesses and within that sector, mostly consumer internet projects. So if you are working outside of the software business, I am not sure how useful this post will be.

I have a strong bias on this topic and that is that less is more. Time and time again I have seen the entrepreneur who wants to hire quickly fail and I have seen the entrepreneur that is a bit slow to hire succeed. If you took the time to corrrelate success in all of the venture investments my various firms have made over the years with one variable, it might be most highly correlated with a slow hiring ramp, at least in the first few years of company building.

Being resource constrained can be a very good thing when you are just getting started. It forces you to focus on what's working and get to the rest of the vision later on.

I have tackled this topic of headcount before in the post on Burn Rate. This is what I said:

Building Product Stage - I would strongly recommend keeping the monthly burn below $50k per month at this stage. Most MVPs can be built by a team of three or four engineers, a product manager, and a designer. That's about $50k/month when you add in rent and other costs. I've seen teams take that number a bit higher, like to $75k/month. But once you get into that range, you are starting to burn cash faster than you should in this stage.

Building Usage Stage - I would recommend keeping the monthly burn below $100k per month at this stage. This is the stage after release, when you are focused in iterating the product, scaling the system for more users, and marketing the product to new users. This can be done by the same team that built the product with a few more engineers, a community manager, and maybe a few more dollars for this and that.

Building The Business Stage - This is when you've determined that your product market fit has been obtained and you now want to build a business around the product or service. You start to hire a management team, a revenue focused team, and some finance people. This is the time when you are investing in the team that will help you bring in revenues and eventually profits. I would recommend keeping the burn below $250k per month at this stage.

A good rule of thumb is multiply the number of people on the team by $10k to get the monthly burn. That is not the number you pay an employee. That is the "fully burdended" cost of a person including rent and other related costs. So if you use that mutiplier, my suggested team sizes are 5, 10, and 25 respectively for the three development stages listed above.

So 5 or less while you are building product, 10 or less when you are finding product/market fit, and 25 or less while you are working on generating revenues and locking down the business model. That's a rule of thumb for software based businesses that don't require a large direct sales force or some other significant labor cost.

Of course, there are all sorts of reasons why these numbers might not work for your business. This is just a "rule of thumb". You can use it as a baseline to think about whether or not you need those extra heads. But you might convince yourself that you do. And you may be right.

But above all else, restrain yourself from hiring early on. Just because you can does not mean you should. Team dynamics are easier in a small group. They get harder in a larger group. Things don't happen as quickly in larger groups. More management overhead is needed. All of these things work against you as a startup trying to get somewhere before someone else does. So hire slowly and wisely instead of quickly. You will be happy you did.

For more from Fred, visit his blog.