The KPI for scaling your engineering team
Imagine an application engineer with a standard background and minimal infrastructure experience wants to deploy and maintain an analytics stack on AWS. It could require weeks of effort to familiarize themselves with complex cloud concepts and the AWS CLI to successfully deploy and configure the system in production.
Software engineering in general is a broad field, so companies employ specialists to ensure that developers aren't wasting time battling problems outside their areas of expertise. One such specialized developer, a Site Reliability Engineer (SRE), is responsible for deploying and maintaining a company's software in production.
Hiring, training, and retaining developers requires significant time and money, so organizations need to balance the investment in SREs with other technical staff needs. So, companies of all sizes are increasingly turning to solutions that can abstract away production complexities and provide a seamless developer experience out of the box to every engineer on their team.
Abstract Complexity, Improve Developer Experience
While it's important for both developers and infrastructure teams to have some ownership of operations, developers don't want to be involved in the practical application of deploying, managing, and provisioning complex infrastructure. Time spent putting out fires in production is time developers otherwise could have spent on shipping features.
Thus, it's necessary to have a solution that abstracts away these hassles and empowers developers with a self-service ability infrastructure.
The SRE-to-Developer Ratio
In their well-known book, Site Reliability Engineering, a team of SREs and technical writers lay out Google's philosophies and practices regarding, you guessed it, site reliability engineering. One famous concept in the book is the "SRE-to-developer ratio." As SREs have specialized skills that add leverage to other developers' work but are a scarce resource, companies maintain a SRE-to-developer ratio of about 1:10 where one SRE team commonly works with multiple developer teams in their product area.
While the industry standard 1:10 ratio seems like a good starting place, it fails at both extremes of organization size. A seed-stage startup likely has fewer than ten engineers, so a dedicated SRE would exceed the ratio, straining limited resources. Instead, many small companies get by with tasking some or all of their application engineers with managing their own infrastructure, slowing product development. At the opposite end of the spectrum, a rapidly scaling company that needs to add 300 application engineers would require 30 additional infrastructure developers to account for the growth.
How to improve your SRE-to-Developer Ratio
Organizations of all sizes are rethinking their approach to scaling both teams and infrastructure. Investments in internal tooling, whether built or bought, automates repeated tasks and abstracts complexity, which allows each SRE to support more developers.
With a self-service DevOps solution, it's possible to approach upwards of a 1:50 SRE-to-developer ratio. Individual developers are empowered with the tools they need to manage their own infrastructure day-to-day with minimal effort, while SREs focus on the toughest and most pressing problems the infrastructure presents. By providing this additional leverage, self-service DevOps doesn't just scale infrastructure, it scales people.
Traditionally this has required building infrastructure in-house, or even creating a dedicated Platform or Internal Tools team. This is an incredibly expensive effort, and many are turning away from custom-built tools that require dedicated headcount to maintain and improve. Instead, cloud orchestration tools like Zeet are making it possible to achieve a 1:50 SRE-to-Developer Ratio without having to build the tools yourself.
What's your organization's SRE:Developer Ratio?