Software Staffing Ratios
An introduction and understanding of tech company ratios
Overview
The ratio of one discipline to another in product, engineering and operations teams is an important consideration as you grow. If you develop your team and get the ratios wrong, you encounter issues around “getting work done” or even more severe retention issues due to overwork and frustration due to uneven workloads.
There’s no “correct” number here in each of the ratios presented. The ratio you settle on may have to take into account variances in terms of the environment, product, architecture and quality of the platform you are working with.
Consider the following roles:
- Product Managers — the definition of which is someone who bridges discovery and development and assumes the product owner role in addition to the research part.
- Engineers — assume full-stack for this, rather than separating front and back-end. That in itself could be a ratio of its own.
- DevOps Engineers — again, assume this is a separate role to back-end engineering that involves run as well as design.
- Quality Assurance — again assume automation within the role, splitting this into automation and manual may give rise to another ratio
The Ratios
The proposed “starting point” for ratios is as follows:
1 x Product Manager <> 5 x Software Engineers
1 x Devops Engineer <> 5 Software Engineers
1 x Quality Assurance Engineer <> 3 Software Engineers
This means, in the top example, that you need to hire and have in place one product manager for every five engineers in your organisation. One product manager should be able to scope, specify, clarify and help five engineers in an engineering context. However, this ratio may vary.
n.b. For completeness, the user experience <>product manager ratio is deemed to be 1:1, but again this depends on your product and the nature of it.
Ratio Variance
Let’s look at a number of elements that affect the ratios above, and when it is appropriate to increase/decrease the numbers on each side.
Experience and capability
Firstly, the experience within your team can affect your ratios. If you have a team of very senior individuals who are very capable and produce work faster than you can produce it, then you’re going to have to compensate in the product and quality assurance space. There has to be an appropriate balance to ensure a manageable flow of work.
Product & Technical Architecture
Your product may influence the ratios and number of people you need in the quality assurance and devops space. If you’ve opted (or inherited) a more modular architecture (e.g. a microservices architecture) then you are going to need more automation testing and devops. In this case, the ratio will move from 1:5 to more like 1:3 due to the increased effort involved. That means more devops and more quality assurance people to cope with the increased number of services. B2B products typically tend to be more complex than B2C products and therefore require a higher number of product managers as a result of this.
Debugging your staffing ratios
How do you know if your ratios are problematic? In terms of product and engineering, you might have the following situations and issues.
- Product <> Software Engineers(Not enough product people) — Overwhelmed product managers are one result of this. You may also find that engineers compensate for this by making product decisions in a localised environment. That will mean (not always) that functionality is problematic for your users.
- Product <> Software Engineers (Not enough engineers) — You’ll see long backlogs occur, frustrated senior leaders, and subsequent gaps in your product in relation to other products. You may have a frustrated product team who are constantly competing to get functionality developed, being forced to evaluate, re-evaluate and make tough decisions.
- Low number or lack of UX/UI Designers — Your product functionality, user journeys and usability are problematic for your users, resulting in frustration, high training costs or lots of support tickets.
- Software Engineers <> Quality Assurance Engineers (Not enough QA engineers) — You may well see product fragility issues, frustrated users and lots of support tickets. This isn't always the case, especially if your software team is peer reviewing and assuming the quality assurance engineer role.
In the product manager <> software engineer <> quality assurance flow of software development, you can spot people/process issues by measuring lead time and cycle time and measuring the length of time tickets are in each stage. This is often built into issue management software and reporting within that will help to identify process bottlenecks. The following Atlassian article highlights a number of tools to help here:
This will help you with the product owner role in the product development lifecycle and understanding wait times. However, it is unlikely to help you in the product management <> software engineering process
Company Stage Caveat
In the early days, you’ll have people assuming roles and wearing multiple hats in order to get the company off the ground. This means general levels of franticness as your ratios will be all over the place between your engineering team and everyone else. You may well not have any product managers, and as a founder, you wear the product hat and liaise with the engineering team along with doing sales, finance etc..
In Conclusion
Ratios can make or break your product-development process within the company. You can design around these ratios by having people adopt multiple disciplines and perform specific roles when needed, but there are consequences. For example, if you’re building up too much development work that requires quality assurance due to a lack of testers, then you can temporarily have people adopt the QA role in order to work through the backlog of work. That coupled with limiting work in progress helps to provide more throughput and less blockage.
Ultimately, though, you should be measuring and adapting according to what you experience in the development process. That includes looking at the lead time and cycle time in your teams terms of experiments and measuring what you see in your teams. Involve them in the process and ensure they are empowered to raise potential blockers or activities that are taking too long.
I’m Jonathan Holloway, CTO at large near Bristol, somewhere in deepest darkest South Gloucestershire.
