CTO · Project management

How to size an engineering team for a SaaS company?

Daniel Hauagge

June 25th, 2015

I'm working on financial projections for my company and I'm trying to figure out the size of my engineering team. For the near term the projection is pretty easy but for further along projections I need some rules of thumb that would help. So I'm looking for help from some experienced CTO that has done that. So far I decided to split the team into support/customer facing engineers (1/10M clients) and product engineers, these I'm going to allocate based on the features of the product. My company is providing an API and the business model is similar to companies like Face++ and imgIX, would greatly appreciate any help.

A great idea is 1% of the work. Execution is the other 99%. In this course, we’ll teach you how to conduct market analysis, create an MVP and pivot (if needed), launch your business, survey customers, iterate your product/service based on feedback, and gain traction quickly.

Dave Hurt Partner, Prototype1

June 25th, 2015

Hey Daniel, i assume you haven't fully launched yet. 

I think you are over planning a bit. There are so many unknowns about what the production environment and customer needs will be that I don't think there is a rule of thumb out there. I would worry about hiring quality developers and getting their input based on the case load & new features. Then going from there. It's a startup - you need to shoot from the hip sometimes ;)


June 25th, 2015

first an observation -- i don't know that customer facing engineers are really going to be engineers per se. they're usually skilled to the same level as sales engineers and would be better budgeted (imho) under marketing or ops.

secondly, the approach -- you could simply reverse engineer the headcount growth of an established company in the same space by scouring LinkedIn (or hiring an elancer to do it). Pick a company like MuleSoft and look at every hire they've made, what their role was, which dept they were likely in, check the date each person joined/left, and chart out the team growth/attrition by dept by quarter. it's really helpful to tally this timeline of hiring with the timeline of funding for the co (from crunchbase) to get a real sense of what happened when -- and to inform/validate your own plan. 

Sam McAfee Building Popup Incubators for Corporate Innovation Programs

June 25th, 2015

The rule that I usually use for clients in the Bay Area is $250k per head including salary, benefits, and overhead. The range is around $90k for fresh college grads (or code schools) to $180k for senior engineers. and it's another 50% over their salary for the other stuff.You can adjust that for your area, but you're in NY so it's probably not much different for you.

Then, how many of those do you need for how long? Well, it depends on what you're building, obviously. But these days, you can get pretty far pretty fast with a team of just 4-6 before you have to think about adding resources. I'd be happy with 4 mid-senior level folks for a year for just about any technology startup I can think of.

I wouldn't differentiate too much between "types" of engineers at first. You don't want to specialize too much for a while. Everyone should be a generalist, able to do front-end, systems/dev-ops or customer support. That will get you to your first 12 to 18 months just fine. Why you would need to project much beyond that anyway, I don't know. It's all speculation at that point.

Does that help?

EDIT: And having read Dave's answer, I agree. You're over-projecting already anyway. :) You need a million and a quarter to a million and a half. But no-one is going to give it to you without already showing substantial traction.

Amol R

June 25th, 2015

I think a lot depends on your product roadmap. if you think product is 80% (of your vision) ready then customer support outweighs product engineers. If its 40% of what you need it to be, I would split the 60% of feature in 12 equally size (requires rough estimate) buckets. This again assuming you have timeline of reaching your vision in 12 months. 
Once this is through you would now know the estimated hours per bucket (assuming a month ~ a bucket) and based on which you can figure out engineers you would need. Add a buffer or two if possible.

On the other side if you think you are very close to your product vision and coming year is more about acquisition and support then then offcourse you need more support engineers and different math. 

Karl Schulmeisters CTO ClearRoadmap

June 26th, 2015

>>So I'm looking for help from some experienced CTO that has done that<<

So my consulting rates are quite reasonable :-)

But all joking aside.  I agree that you might be overthinking it and that it depends on not only your roadmap but your app type and your target client base:

  • if you are doing B2B SaaS - you essentially are acting as an outsourced IT department.  Depending on the agreement you have you are
    • supporting only their IT department and have a SPOC per B2B company
    • supporting their users directly in which case you have your SPOC and still have to staff for user size (figure 100 users/tech support staff)
  • Or you are acting like a general SaaS service provider like Gmail in which case you can set what your support commitment is