What does a typical engineering org chart look like for a SaaS company all the way from CTO down to engineers?
I ran a successful Saas company. There are four engineering disciplines you need to accommodate: 1. Architecture – The software underpinnings – the top engineers in the company that produce the core of the app 2. Ops – Server and network management. Even if you are using Amazon or another cloud, this still matters. Their goals should be availability and cost per unit of processing. This guy embodies your COGS on the P&L, so they need to be good. 3. Product Engineering – The site and the non-architecture developers. These folks are faster, not architects, and not expected to create long-term scalable code. 4. Engineering Management – Once you have more than 8-10 engineers producing code, the ability to set deadlines and manage releases becomes imperative. I list them as disciplines because you need each to be handled competently, but they are not four “heads”. In our case we had a very strong architectural CTO with a good sense for release management. He had a head of Ops and the produc
This would seem to be a ‘spans and levels’ type question, and will depend on whether you include / exclude product management and architecture from your model and whether you believe in the ratios and management science type approach or a much more self organising, dynamic organisation. Assuming a more traditional approach – I would expect that folks with management responsibility would typically have between 5 and 8 reports as an organisation matures, higher either if you have great process, or are early on in the lifecycle and growing fast or have a much more self-organising organisational culture. A typical model might be 1 (S)VP Engineering reporting to your CEO for this kind of scale, there is a lot of evolution that would normally happen between 30 and 80 engineers. To provide great and timely product input for that number of engineers you would would expect 6-12 product managers (depending on the cycle time and technology you are using and enterprise/consumer bias – typically fe
