SRE Team Models

How SRE organizes itself. Embedded vs centralized vs platform team models, and when each fits.

Overview

Structure shapes outcomes

SRE team structure matters more than people realize. The wrong structure produces dysfunctional outcomes regardless of individual talent.

> [!IMPORTANT] Whatever the model, the culture is the same: SLO-driven, blameless postmortems, a 50/50 split of engineering and on-call, and influence over product decisions.

The four common models

1. Embedded — SREs assigned to a product team page on its services and join its meetings, influencing design — Deep product knowledge; tight integration — Practices vary across teams; lessons are hard to share
2. Centralized — One SRE team owns reliability for many services, with its own roadmap — Consistent practices, shared lessons, specialization — Less product context; risk of becoming "ops 2.0"
3. Platform — SRE owns the platform layer: Kubernetes, observability, CI/CD, IaC; product teams own their own on-call — Clear separation; platform gains benefit everyone — Platform team can drift from product reality
4. Hybrid — A mix, often platform SRE for foundations plus embedded SRE for critical services — Fits large, diverse orgs — More coordination

Embedded vs centralized

Strength — Knows the product's SLOs, dependencies and traffic intimately; shapes architecture early; mitigates faster — Consistent practices, cross-team learning, specialization in database, networking or observability SRE
Risk — Drifts into "infrastructure engineer for the product team" — Becomes alert responders without product context; hand-back conversations get harder: "our team has a contract"

The pragmatic mix at scale

Foundations: Kubernetes, observability, CI/CD, IaC, internal services — Platform SRE
High-stakes products: revenue-critical, customer-facing — Embedded SRE inside the product team
Standard products: internal tools, utilities — Product team, with central SRE consulting
Shared services: DB, message broker, cache — Centralized SRE owns the platform; product teams use it

"You build it, you run it"

Werner Vogels originated this at Amazon: every team owns on-call for its own services, and there is no separate SRE team.

Strong incentive to write reliable code — Each team reinvents reliability practices
No ops and dev silo — No specialists for capacity, observability, CI/CD
Engineers feel the pain of bad reliability and fix it — Reliability time comes out of feature time
Burnout risk for engineers not hired for on-call

It works at hundreds of engineers; at thousands, some platform SRE function emerges.

Picking a model by size

Under 50 — Probably no dedicated SRE team; distribute ops; consult externally
50-200 — 1-3 SREs, centralized, partnering with product teams
200-1000 — Multiple SRE teams; hybrid of platform SRE plus product-aligned SRE for the most critical products
1000+ — Full hybrid: embedded in critical products, platform for foundations, central for cross-cutting concerns

Culture regardless of model

Targets — SLO-driven, not uptime-driven
Learning — Blameless postmortems
Time split — 50% engineering, 50% on-call
Practice — Engineering practices, not ops practices
Role — Influence over product decisions, not just reaction

Key concepts

Embedded SRE: SRE assigned to product team. Deep product knowledge; risk of drifting away from SRE practice.
Centralized SRE: One team owns reliability for many products. Consistent practices; risk of "ops 2.0."
Platform SRE: Owns foundational layers (K8s, observability, CI/CD). Product teams own their services. Clear separation.
Hybrid: Most large companies. Platform SRE + embedded for critical + centralized for cross-cutting. Best of all.
"You build it, you run it": Amazon model: every team owns their on-call. Strong dev/reliability link; doesn't scale past ~1000 engineers.
Engineering vs ops culture: SRE writes code, designs systems, automates. NOT ticket-handlers. The cultural distinction.

When to use it

Org design — when should you start an SRE function?
Hiring conversations — what model are we?
Cross-team friction — is the model creating problems?
Scaling — when to evolve from one model to another?

Interview questions

When should I start an SRE team?
Embedded vs centralized SRE — how do you choose?
How is SRE different from DevOps and SysAdmin?