Developer to all-technical-staff ratio: 1:4 as a rule of thumb?
Here’s a quick question to all people used to either interact with or being part of software development teams.
Consider a software vendor, a good one, and its technical headcount. It is no secret that R&D teams aren’t made of software developers only. In order to be deployed successfully, architectures and code need to be tested by a QA department (QA = quality assurance) where professional testers run through thousands of automatized-or-not scenarii; documentation; technical support staff help the install base with potential regressions occuring during updates and coping with changing information system environments; localization project managers monitor translations of the software: and last but not least, application engineers actually parameterize the software at clients.
Now my question, how many technical staff should you account for every software development engineer? I figured out an average ratio of 1 to 4, that is to say, for every technical team of 100 there should be around 25 software developers actually hacking code.
I know there exists extremes but by and large, from what I’ve seen, I don’t think I’m too far from the reality with a 1:4 developer / all-categories-technical-staff ratio.
What do you think? Feel free to describe what the company does when sharing your experience, because, since there are very large discrepancies between, say, an SAP that manufactures ‘heavy’ enterprise software and any web application designer that may not necessarily run industrialized testing and that has no professional service department, we might not get nuances at first sight.
PS: the ratio will also depend on the maturity stage of the company: at Microsoft, [# of develops]/[develops + Microsoft Consulting Services staff + developer evangelists + localization engineers + testers (1 for each develop) + architects] approximately equals 1/4 (1 to probably 5 ot 6 adding documentation specialists; & 1 to much more if you consider the system integrator ecosystem that actually does the application engineering). But the company is rather mature and therefore can afford to focus on quality of execution rather than productivity in execution. Which probably wouldn’t be the case for an enterprise software startup for obvious resource reasons. Anything to share? Best and worse practices, per specific industry (Web 2 / UGC, Video Games, enterprise, affordable consumer traditional applications, etc.) most welcome. I need to test my own budgeting assumptions 
LikeRelated posts:
.NET (C#), Adobe, Agile, Amazon, Apple, Architecture, Art, Business Process Management, CIO, Consulting, ERP, Entrepreneurship, Facebook, Google, HP, IBM, India, Java, MNC, Microsoft, Organization, Outsourcing, Project Management, S+S, SME, Security, Silicon Valley, Software, Twitter, USA, open-source, operations, video games, web2.0
I would tend to think this is a quite realistic figure and as you said, it really depends on the side of the structure. For small start up/structure the ratio could go up to 50%.
Roughly speaking you should have 1 QA engineer for 3 developers, 1 operation engineer for 4 developers and apply the 2 pizza rule for manager (i.e 1 manager for 8 people max). And 1 architect if you have more then 2 dev teams.
My recommendation is to start small and to adjust gradually. This helps setting up a core team with a strong culture and clear principles and to focus on process and organisation baring in mind the capacity planning factor.
It is much better to accomodate new staff when process /organisation is clear then improvising and changing the latter on the fly as the team gets bigger.
Maybe this is true for large companies. But in a start-up, when you build the team from zero, IMHO it will be different for quite some time.
First, your project manager would act as QA because he’s the one who should know best what the features are supposed to be, even if the specs are not perfectly documented. And as a bonus, he’s the one the developers will obey, so he has a chance to set the required level of quality.
In my experience, although I consider this to be bad a thing, the project manager is generally the best tester. He knows he will be facing the client/boss/investor with a demo or a delivery and he will take the heat if something does go wrong. So he will really seek out the non-obvious but catastrophic bugs.
Additionally, the leader is the one who does all the work for which he does not have a skilled subordinate. Which means he does it all until he has a good QA, tester, etc.
So my advice is to have a very solid and motivated project manager. Giving him shares or stocks of the company is not a bad idea. Making him the same person as the lead developer is a bad idea because he cant’ judge right (as a QA should) if he’s part of the team that builds it. Incidentally, if your tech team is really small, the boss might be the best project manager around. It can become painful pretty fast, because the boss has so many other things he should be doing, but that’s how start-ups start very often.
Finally, I recommend not waiting before setting-up tools and methods even for a small team. Don’t let everyone improvise the way they document the specs, tests and plan the development roadmap, or you will have no idea of what will be done when, and bad surprises all the way. At zSlide we use a lot of XPlanner (http://www.xplanner.org/) for that. It’s a Java web app which is a litlle painful to install and does not have a great UI, but it has exactly the right structure and it’s based on eXtreme programming, so agile development works very well with it.
Louis.
Many thanks Louis, this is high quality commenting. I sent it to my team of engineers.
We are a small internet software/technology company. Around $100 million annually in revenues. Currently, globally, around 135 employees. I’m trying to find information on comparable sized internet software/technology companies in regards to their employee ratios in
1. Product management
2. Project management
3. Marketing
4. Database/datawarehouse
5. Business development
5. R&D (includes software engineers)
6. Finance & Accounting
7. QA.
Any insights as to employee ratios in those departments would be greatly appreciated. As well as if there are any informative web sites that may give insight into employees ratios for this type of company.
Thank you