The most surprising thing about SRE organizational structures is that the "embedded" model, often lauded for its agility, can actually lead to less consistent reliability if not managed carefully, precisely because it disperses ownership.
Let’s watch an embedded SRE team in action. Imagine a company with a microservices architecture. We have ServiceA, ServiceB, and ServiceC.
ServiceA is critical for billing, ServiceB handles user profiles, and ServiceC is a new feature for recommendations.
The SRE team for ServiceA (let’s call them SRE-A) has three engineers. They report to the ServiceA engineering manager. Their on-call rotation is tight, and they spend 70% of their time on operational tasks for ServiceA – monitoring, incident response, and deployments. They have a direct line to the ServiceA developers and can push for reliability improvements.
SRE-B is similar for ServiceB, also reporting to their respective engineering manager.
SRE-C, for the new recommendation service, might be smaller, perhaps two engineers, and they report to the ServiceC product lead. Their focus is on getting the new service stable enough for a public launch, so they’re heavily involved in feature development alongside reliability work.
Now, consider a centralized SRE team. This team, let’s say 10 engineers, reports to a Head of SRE. They don’t "own" a single service. Instead, they are a shared resource, often acting as consultants or a separate team that services multiple product teams. When ServiceA needs reliability work, its developers might file a ticket or request assistance from the central SRE pool. They might get an SRE for a specific project, or the central team might develop tooling that ServiceA’s developers then adopt.
The problem SRE-C is trying to solve is the inherent tension between feature velocity and operational stability. If SREs are embedded, they are deeply familiar with their service’s code and operational characteristics. This allows them to quickly diagnose and fix issues specific to that service. They can tailor automation and monitoring precisely to ServiceA’s needs, leading to faster incident resolution for that service. They are also more likely to be proactive about reliability, as they are directly accountable to the service’s overall health and its product/engineering leadership. The tight feedback loop between SRE and developers means that reliability concerns are addressed earlier in the development lifecycle.
In a centralized model, the SRE team develops expertise across a broader range of services. This can lead to the creation of more generic, reusable tools and practices that benefit multiple teams. For example, a centralized SRE team might build a standardized CI/CD pipeline or a common alerting framework that all services can adopt. This reduces duplicated effort and promotes consistency. However, the SREs may not have the deep, intimate knowledge of a specific service’s codebase or operational nuances that an embedded SRE would. They might be seen as an external dependency by product teams, potentially slowing down the adoption of reliability best practices if communication channels aren’t strong.
The true power of the embedded model lies not just in proximity, but in the shared accountability it fosters. When an SRE is part of a service’s team, their success is directly tied to that service’s uptime and performance. They have a seat at the table when design decisions are made, ensuring that reliability is considered from the outset. This integration allows for a more proactive approach to reliability, as the SRE can influence architectural choices and coding standards to prevent future issues. The SREs become true partners with the developers, sharing the burden of operational excellence.
A common pitfall of the embedded model is the potential for "SRE silos" where each embedded team develops its own unique tools and processes, leading to fragmentation and difficulty in sharing knowledge or best practices across the organization. This can also lead to inconsistent levels of operational maturity between different services, depending on the maturity and resources of each embedded SRE team.
When SREs are embedded, their success is measured by the reliability metrics of the service they support, and they have direct influence over the code and infrastructure. This direct line of sight and shared ownership is what makes them so effective at improving specific service reliability.
The next challenge is ensuring that embedded SRE teams don’t become so specialized that they lose sight of broader organizational reliability goals.