Sizing SRE to Your Org

Determining the appropriate number of Site Reliability Engineers (SREs) for your organization is a nuanced endeavor. It hinges on various factors such as the size and complexity of your organization, the frequency and severity of incidents, and your maturity in reliability practices. While there isn’t a one-size-fits-all formula, there are tested approaches that can guide your decision-making process.

The Google Rule of Thumb

Google offers a foundational guideline suggesting the employment of 1 SRE for every 10 software engineers. This rule serves as a starting point rather than a definitive answer. The actual number of SREs you require will be shaped by the complexity and distribution of your services, the frequency and severity of incidents, the level of automation maturity, the sustainability of on-call rotations, and the business criticality of your systems.

Factors That Increase SRE Needs

High Incident Volume

If your team finds itself constantly in firefighting mode, you will require more SREs to maintain sustainable on-call rotations. However, your focus should be on reducing toil rather than just increasing headcount.

Complex Distributed Systems

Managing microservices, multi-region deployments, and heterogeneous infrastructure demands highly specialized knowledge. These systems are inherently harder to troubleshoot and maintain, which might necessitate having embedded SREs for each major service.

Rapid Growth

When your organization is scaling quickly, capacity planning becomes crucial. Frequent changes in infrastructure demand that you stay ahead with automation to keep up with growth.

Regulatory Requirements

Compliance and auditing introduce additional documentation and process overhead. You will need more monitoring and controls, which might lead to separate SRE focus areas to address these requirements.

Factors That Decrease SRE Needs

High Automation Maturity

As your systems evolve to become self-healing, the operational burden decreases. With reduced need for manual intervention, fewer pages and incidents occur, allowing SREs to focus on more strategic work.

Simple Architecture

In environments with monolithic or well-understood systems, there are fewer failure modes. Troubleshooting is easier, and there is less coordination overhead.

Strong DevOps Culture

When developers take ownership of production, shared on-call responsibilities become the norm. Here, SREs act more as consultants, focusing on platform work, and a smaller centralized team suffices.

Managed Services

Extensive use of Platform as a Service (PaaS) or Software as a Service (SaaS) means less infrastructure to manage. The provider takes care of underlying reliability, allowing SREs to focus on the application layer.

Team Size by Organization Scale

Startup (<50 engineers)

For a startup, the typical SRE team consists of 0-2 people. Initially, you may not have dedicated SREs, with developers handling on-call and operations. The first SRE hire should concentrate on automation and standards to lay the groundwork for future scaling. Watch out for red flags indicating the need for SREs, such as frequent production incidents, developers spending over 50% of their time on operations, scary or slow deployments, and a general lack of understanding about how production works.

Small Company (50-200 engineers)

In a small company, you might find a centralized SRE team of 2-10 people. This team should focus on platforms and self-service, embed with critical services, and establish a Service Level Objective (SLO) framework. The team composition typically includes 1-2 Senior SREs for leadership, 2-5 SREs for execution, and 1-2 Platform Engineers for tooling.

Mid-Size Company (200-1000 engineers)

Mid-size companies generally have SRE teams ranging from 10-50 people. Here, a mix of embedded and centralized teams often works best, with SRE teams aligned to product areas and a central platform team for shared services. Formal production readiness reviews become part of the approach. The team structure usually consists of 2-4 SREs per major product area, 5-10 SREs on the platform team, and 1-2 SREs focusing on incident response and coordination.

Large Company (1000+ engineers)

In large companies, SRE teams can range from 50 to over 200 people. A fully federated SRE organization is common, with SRE leadership distinct from the engineering teams. Specialized roles such as chaos engineering and capacity planning emerge, and SREs act as a consulting service to product teams. The team structure typically includes multiple SRE teams per business unit, dedicated SRE leadership and program management, centers of excellence for specific domains, and organized SRE rotations and career development programs.

The On-Call Constraint

Ensuring a sustainable on-call rotation is crucial and requires a minimum team size.

Minimum Viable On-Call: 4 people

With a team of four, you can maintain weekly rotations where each person is on-call once per month. This allows for vacation and sick time, assuming you have a secondary on-call backup.

Comfortable On-Call: 6-8 people

A team of six to eight people allows for biweekly rotations, meaning each person is on-call every six to eight weeks. This setup provides a better work-life balance and is more resilient to turnover.

Multi-timezone Coverage: 12+ people

For 24/7 support across regions, a team of twelve or more enables regional on-call rotations, significantly reducing off-hours pages.

If your team cannot sustain the minimum on-call size, consider using external on-call services, sharing on-call duties with development teams, reducing service scope, or focusing on automation to decrease pages.

Efficiency Metrics

To guide your decisions regarding team sizing, you should measure SRE efficiency.

Toil Percentage

Your goal should be for less than 50% of SRE time to be spent on toil. If the team is spending more than half of their time on manual operations, you need to either hire more SREs or invest significantly in automation.

Services per SRE

A good benchmark is managing 5-10 services per SRE. In highly automated environments, this number can increase to 10-20 services per SRE, while in manual environments, it may decrease to 2-5 services.

Incident Load

Aim for less than two incidents per SRE per week. If incident rates are higher, this suggests a need for more SREs, improvements in reliability, or both.

When to Grow Your Team

Signals You Need More SREs

Burnout and turnover: The team is unsustainably stressed.
Incident backlog: You can’t keep up with response and follow-up.
Abandoned projects: There’s no time for automation or improvements.
Coverage gaps: You can’t support on-call or new services.
Toil creep: More time is being spent on manual work over time.

Signals You Can Wait

Low incident load: The team is handling the current volume easily.
Automation working: Toil is decreasing over time.
Healthy on-call: Rotations are sustainable and fair.
Project velocity: You are able to execute on strategic initiatives.
Team satisfaction: SREs feel engaged and valued.

Alternatives to Hiring

Before deciding to grow your team, consider these alternatives:

Automation First

Invest in eliminating toil, building self-service platforms, and implementing better observability.

Shared Responsibility

Train developers on production operations and implement a “you build it, you run it” culture, allowing SREs to shift toward consulting rather than execution.

Outsourcing

Consider managed services for infrastructure, specialized SRE consultants for projects, or an external Network Operations Center (NOC) for tier-1 support.

Process Improvements

Focus on better postmortem follow-through, improved runbooks and documentation, and streamlined incident response processes.

Common Sizing Mistakes

Beware of common pitfalls such as hiring too early before understanding actual needs, hiring too late after the team is already burned out, assuming SRE needs grow linearly with the number of engineers, ignoring automation by adding personnel to handle toil, having the wrong skill mix (all senior or all junior engineers), and lacking a clear scope, which leads to SREs being pulled into everything.

SRE From Scratch