How Many Developers do You Need?

Every company today, and every startup, needs software developers. Although some parts of product development can be done with no-code tools, the need for developers hasn’t gone away and will stay with us for the foreseeable future.

Many CTOs or founders in startups don’t know how many developers they need. When I look into companies, there is a huge difference in the number of developers. From the outside looking at the product I am often surprised of how many or how few developers there are. Even competitors with successful products have widely different numbers of developers. Do you need many developers to be successful? When Facebook bought Instagram, there were 13 employees.
In the lifecycle of a product there are five main phases.

1.
The first phase is ‘Find a product idea’. Finding the right product idea isn’t easy, but you don’t need a developer for this. A developer can be helpful to bounce ideas with, but this could be a friend.

2.
The second phase is ‘Build MVP’. The first code needs to be written to build an MVP to get some initial traction, learn from the market or pitch to VCs. For this phase one developer is enough. More developers are mostly a waste of money and communication. You can easily use a freelancer here. The MVP is quite small, and the speedup of several developers just isn’t there.

3.
The next phase is ‘Find product market fit’. This is the most crucial phase in the life of a startup and the phase many startups get wrong. They think they have achieved product market fit and move on or they just move on to scaling without having product market fit. In this phase you need a few developers mainly to iterate through versions of your idea and smooth edges, so it flies with the market. Finding product market fit is hard to parallelize, so the amount of developers that can drive the product forward is low. Indeed, because finding product market is hard to parallelize, adding too many developers just creates more wasteful activity that ties developers down.
The biggest mistakes are made in this phase. Because it’s hard to find product market fit, it takes time to find product market fit, the amount of things you can do is limited and both traction and revenue don’t go up until you have found product market fit, CEOs and founders get restless, nervous and grow impatient. The often hire more developers – too many – and invest in marketing to force growth against the market. They waste money with AdWords and Facebook ads. This never works and only buys traffic that is not convert or stick. Then they hire “growth hackers” to get traction and growth.

All of this creates needless pressure on technology and developers. Developers are sidetracked from finding product market fit and invest all their time into growth. When the money has dried up and the bough growth has evaporated, the company folds. Don’t scale before product market fit or too many developers do too many things but do not work on the one thing that matters: product market fit.

4.
After product market fit you need to scale your product. The ‘Scaling’ phase needs the most developers. The product has found product market fit which means you have traction and people want your product. Scaling means growing your market share and increasing revenues.

Scaling a product is easy to parallelize. Developer teams can work on many different, independent things on their own. So this phase needs us much developers as you can get.

There are many ways to scale a product:

  • More marketing: This means you need developers for integrations into different tools. Integration work is error prone due to bad communications and bad documentation. Therefor you need quite several developers here.
  • Integrate with partners: To grow your product needs to integrate with other platforms, other APIs or other tools. There might be a market leader in a different market with who you need to integrate. As written above, integrations are error prone and need a lot of developers to implement and maintain.
  • Business development: There are lateral partners you can integrate who want to integrate with you. This brings new customers but you need to develop an API so they can integrate with you. Writing and maintaining an API needs more developers.
  • Enterprise edge cases and features: If you sell to new customer segments, one of the segments will be enterprise customers. They have different feature needs than your current customers. They might need some compliance levels, identity solutions or integrations in their current tools and intranet. For this you need more developers.
  • Internationalization: Growing your customer base in new markets drives changes in your product. Texts need to be translated, different countries have different laws that you need your product to adapt to and different cultures use product differently. What has worked in your home market will not work in other markets. To adapt your product, you need developers.

Many of this scaling issues can also be easily outsourced, as they are not part of your core product. This can keep the number of internal developers down. You gain flexibility in cost and scaling. The base for this is an API as a foundation. Then marketing, integrations with partners and API layers and adaptions can be outsourced to external companies with the right strategy in place.

5.
The last phase in the life cycle of a product is ‘Optimize product’. Your product has a large percentage of the - reachable - market. There is not a lot of room to scale left. Here you need to squeeze the last bit of conversion out of the product, fix the leftover bugs, cut costs and keep the cash cow running. In this phase you have very few developers. Most of your developers are moved from the product into a new product that needs scaling. Sometime earlier, when this product was in its scaling phase, you should have started a new product in the ‘Find product idea’ phase and found product market fit. That new product now needs to scale and the most developers.
Having the right numbers of developers in makes for a smoother ride. Having too few developers slows things down, having to many wastes money and slows things down too.

Beside the five phases in the product life cycle there are other considerations on the number of developers you need:

  • Reduce single point of failures (SPOFs): There are developers in your company that are single point of failures. If they are ill, on holiday or leave your tech department no longer works. This could be the CTO, a developer with special knowledge or the only person who does 24/7 operations. When you grow in order to reduce risks you need to work on your SPOFs. This will increase the number of tech employees by 10%.
  • Build slack capacity: If all developers work on a 100% level, your throughput will get wobbly and tank. From queuing theory to Kanban it has been shown numerous times that developers working with a 80% workload level have more overall throughput. This will increase the number of tech employees by 20%.
  • Specialize: In the beginning with few developers you seek developers with a wide range of expertise. With more developers and deeper products these developers can specialize into smaller domains. This does increase throughput and quality but reduces flexibility.  This will increase the number of d developers by 20%.
  • Add department dependent teams: In the beginning developers will serve all departments, will work on product and help marketing implement landing pages and trackers. Later on this can rock your boat when you move people around and you want to get different timelines and rhythms from product, marketing and sales aligned. Then it gets a lot of struggle and stress out of your company when you create department dependent teams, e.g. one that only works for marketing. This adds 10% of developers.
  • Plan for middle management: Sooner or later you need middle management in your company to communicate, explain, align, support and develop employees. Often tech is the first department that needs middle management because it grows the fastest. Plan for it so it doesn’t surprise you. Otherwise you can’t develop people, neglected people will leave and you have a high turnover and high costs, the CTO will burn out and is your biggest SPOF. Adding middle management increases the number of developers by 20%.

A third way to find the amount of developers needed in your company is money based. The more money you spend for people, the more stuff is getting worked on in your company. And because a lot of this work involves development and IT, tech spending is a percentage of your general spending. Depending on the market you’re in, and if you’re a tech startup or not, the tech spend is higher or lower. Assume you spend 30% of your money on tech, it’s easy to calculate the number of developers. The same goes for VC money in the bank, which you divide by the runway (e.g. 2 years) to get to an amount you’re spending each year. Subtract the operation and hardware costs and you have the spend on people. Divide that by yearly average salary and get the number of people you need. Using future projections will give you the number of developers in the future. This rough number helps with future IT planning and plausibility check the numbers you come up with the different methods above.

Don’t use your gut feeling to determine the number of developers you need you pull a number out of a hat. Founders think they need more developers than they really need. Especially VC funded startups have to many developers too early which hinders them achieving product market fit. Without the right traction they overspend in marketing too early and as a result need too many developers which reduces their chance for product market fit. Lastly one of the biggest mistakes when building tech organizations is to forget middle management, SPOFs and slack. This way companies have too many and too few tech employees at the same time.

From the companies I have seen, many have too many developers too early. Later on they have too many on the wrong topics – cash cow features – and too few on new growth features or products. Don’t make the same mistakes.

Happy Coding!

About Stephan

Stephan is a CTO coach. He has been a coder since the early 80s, has founded several startups and worked in small and large companies as CTO. He can be found on LinkedIn or follow him in Twitter.

About Svese

After successfully selling their latest startup, Stefanie Jarantowski and Stephan Schmidt consult, train and coach CEOs, CTOs and sales executives to be happier and have more impact.