SRE Team Topologies

"We're adding SRE" is not a staffing plan — it's a placeholder for four genuinely different organizational decisions that get made under the same three letters. You can bolt SREs onto one product team's roster, stand up a shared team that carries the pager for dozens of services, build a platform that no one has to page at all, or send a small crew of consultants around to teach other teams to do it themselves. Each choice has a different cost curve, a different failure mode, and a different ceiling on how far it scales — and most organizations that think they "tried SRE and it didn't work" actually just hit one model's ceiling and never realized a different structure was the fix. This page takes the four real topologies apart, maps them onto the broader team-design literature they descend from, and does the staffing-ratio arithmetic that tells you which one your organization can actually afford.

Why the org chart is a reliability decision

☺ Like you're 10: The team that owns a system's pager shapes how that system gets built, whether anyone planned it that way or not.

In 1968 a programmer named Melvin Conway published a short paper, "How Do Committees Invent?", that noticed something organizations kept re-discovering the hard way: any organization that designs a system will produce a design whose structure mirrors the organization's own communication structure. Split your payments code across three teams that barely talk, and you'll get three loosely-coupled payment services whether or not that was the architecture anyone intended. What's less often said out loud is that Conway's Law applies just as forcefully to reliability as it does to system architecture — where you put the SRE function, and how it's allowed to interact with everyone else, determines what kind of reliability engineering an organization is even capable of, independent of how skilled any individual engineer is.

Matthew Skelton and Manuel Pais formalized this in their 2019 book Team Topologies, which names four fundamental team shapes — stream-aligned (built around one flow of work to one part of the business), platform (builds internal self-service capability for stream-aligned teams to consume), enabling (temporarily raises another team's capability, then withdraws), and complicated-subsystem (owns a piece of genuine deep specialist complexity) — plus three ways teams are allowed to interact: collaboration (working jointly, high-bandwidth, temporary), X-as-a-Service (one team consumes another's output with minimal communication), and facilitating (one team helps another get unstuck, without doing the work for them). The four SRE topologies on this page are not a separate invention — they are what happens when you point that general framework at one specific function: keeping production up.

Embedded SRE: one team, one service

☺ Like you're 10: The SRE moves in with one team, shares their standup and their pager, and knows that one service better than anyone — but that only covers one service.

In the embedded model, one or more SREs sit inside a single product team: same backlog, same sprint planning, same pager rotation, often the same manager or at least the same roadmap conversations. There is no ambiguity about ownership — if the checkout service pages, it pages people who eat lunch with the checkout team and understand its schema changes as they land. This is the model Google has historically reserved for its highest-stakes, most architecturally singular services — the ones where reliability expertise is inseparable from deep, service-specific system knowledge, and where the cost of a dedicated team is justified by the blast radius of that one service failing.

The tradeoff is arithmetic, not cultural: embedded SRE scales roughly linearly with the number of services that need this level of attention. If you need a dedicated pod for every one of two hundred services, you need something close to two hundred pods, which very few organizations can staff. It is also the model most vulnerable to a specific kind of drift: an embedded SRE reports, in practice, into the same roadmap pressure as the product engineers next to them, and without an external check the toil ceiling from What is SRE? — spend at most half your time on operational load — erodes quietly, because there's no one outside the team whose job is to notice it happening. Toil & automation covers the mechanics of that erosion and how to measure it before it becomes the norm.

Centralized SRE: one team, many services

☺ Like you're 10: One shared crew carries the pager for a lot of services at once — but only the services that pass an inspection first, and the crew can only hold so many in their heads on any given night.

The centralized model puts SRE in its own org, distinct from any single product team, and has that org carry — or co-carry, on a shared rotation — the operational load for a portfolio of services. What makes this model coherent rather than just an understaffed help desk is a formal gate: a Production Readiness Review (PRR), the mechanism Google's SRE book popularized, that a service must pass before the centralized team will take its pager. The PRR checks the things that make a service actually operable — monitoring coverage, capacity headroom, a real rollback path, documented runbooks, dependency failure modes — and a service that fails it stays with its own developers until it's fixed. Production Readiness Reviews covers exactly how that gate is structured and scored.

The PRR gate is what gives centralized SRE its main advantage: every service it supports meets the same bar, uses roughly the same alerting philosophy, and gets postmortemed the same way, because one team enforces consistency across all of it. That consistency is also its ceiling. A centralized team's onboarding throughput is capped by how fast it can run reviews, and its on-call capacity is capped by how many services one engineer can hold usable context on during a single shift — a commonly cited (and, like any rule of thumb, worth verifying against your own incident data rather than taking as physics) rough ceiling is somewhere around ten to fifteen services per rotation before context starts thinning and mean-time-to-diagnose creeps up on unfamiliar pages. Past that ceiling, the fix isn't "hire faster" — it's a different topology layered on top, which is exactly where the next two models come in. Incident management & on-call covers what that cognitive load looks like from inside a single shift.

Platform SRE: paved-road reliability primitives

☺ Like you're 10: This team never carries anyone's pager — it builds the sprinklers and fire doors that every building gets for free, so fewer fires ever need a truck.

A platform SRE team owns no product team's pager and no centralized on-call rotation. Its job is to build shared, self-service reliability infrastructure that every other team consumes without filing a ticket: burn-rate alerting pipelines generated from a declarative SLO spec (the exact pattern in multi-window, multi-burn-rate alerting, and a job tools like Sloth automate past a handful of services), standardized dashboards on Prometheus and Grafana, on-call routing wired into PagerDuty, and chaos-engineering harnesses like Gremlin or a Chaos Monkey-style fault injector that any team can point at their own service — the mechanics of running that experiment safely are in chaos engineering.

This is the literal platform team from the Team Topologies framework, interacting with everyone else through X-as-a-Service: consuming teams get the capability with minimal ongoing communication, the way you'd consume a cloud API. The leverage is the best of any of the four models — one platform engineer's SLO-alerting pipeline can serve three hundred services at effectively zero incremental headcount, because the marginal cost of one more consumer is close to nothing once the pipeline exists. That leverage is also fragile in a specific way: a platform team's output is only as good as its adoption, and adoption doesn't happen automatically just because the tooling is good. Without real product-management discipline on the platform side — a roadmap, adoption metrics, a deprecation policy for the tools it replaces — a platform team can spend a year building excellent, unused infrastructure while every consuming team keeps doing the old manual thing in parallel, which is worse than not having built it at all: the org now pays for both the old toil and the new team. Reliability economics works through that leverage-versus-cost tradeoff in more depth, and SRE Tools & Automation covers the toolchain a platform team typically assembles.

Consulting and enablement SRE: teaching without owning the pager

☺ Like you're 10: A small crew of experts visits one team for a few weeks, teaches them to build their own alarms and their own safety checklist, and then leaves for the next team.

The fourth model is the one most often skipped entirely, and it's usually the missing piece that lets an org scale SRE practice past the headcount of the SRE org itself. A consulting or enablement team runs bounded-duration engagements — typically a few weeks to a quarter — embedding temporarily with a product team to help them define their own SLOs, design their own alerting, pass their own PRR, and write their own runbooks. Then the consultants leave, and the pager stays with the team that now knows how to run it. Google's SRE book publicly describes a team that operated in roughly this shape for major product launches, coordinating and consulting on production readiness without permanently owning the launched service's long-term on-call — worth reading directly if you want the specifics, since the exact team name and structure have shifted over the years.

This is the Team Topologies enabling team almost exactly: its explicit goal is to increase another team's capability and then get out of the way, interacting through facilitating rather than doing the work itself. It scales further per engineer than any other model, because "reach" here isn't steady-state headcount coverage — it's a count of engagements completed, and one senior engineer can run several a year. The risk it introduces is durability, not throughput: the org's reliability posture after an engagement is only as good as what survives once the consultants are gone. Without some lightweight follow-up — a periodic re-review, or a handoff into the centralized model's ongoing PRR cadence — the SLOs and runbooks installed during a good engagement quietly decay over the following year or two, and the next real incident finds the exact gaps the engagement was supposed to have closed.

Staffing ratios: the arithmetic that decides which model works

☺ Like you're 10: Don't eyeball which model to use — do the division. How many services does one engineer, one team, or one visit actually cover?

Every one of the four models answers the same underlying question differently: how much reliability coverage does one unit of SRE headcount buy? The unit of "coverage" isn't the same across models, which is exactly why comparing them by headcount alone is misleading — you have to compare what each headcount unit is actually buying.

steady-state coverage capacity (embedded or centralized):
    org_coverage = SRE_headcount × services_per_engineer

reach for a bounded-engagement model (consulting / enablement), per period:
    teams_reached(period) = SRE_headcount × engagements_per_engineer_per_period

reach for a self-service model (platform), once built:
    reach ≈ adopting_teams   (bounded by adoption, not by SRE_headcount)

Worked example — an org with 120 services, embedded vs. centralized:
    embedded:    120 services ÷ 2 services/engineer   ≈ 60 SREs needed
    centralized: 120 services ÷ 10 services/engineer  ≈ 12 SREs needed
                 same coverage, ~5× fewer SREs — this gap is the entire
                 reason the centralized model exists at all

Choosing and evolving your model: the maturity curve

☺ Like you're 10: Most orgs don't pick one model forever — they grow through all four, roughly in this order, and end up running several at once.

Very few organizations deliberately choose one topology and stay there. Most grow through a recognizable sequence, and the mature end state is usually running two or three of the four models simultaneously for different slices of the service portfolio, not converging on a single "correct" one. Amazon's engineering culture is widely associated with the phrase "you build it, you run it" — attributed to Werner Vogels in a 2006 ACM Queue interview — which describes the earliest stage most orgs pass through whether or not they use the term: every team is a de facto embedded model, without a dedicated SRE title, because there's no other team to hand the pager to yet.

As the number of services and the pager load grows past what any one team can absorb alone, a centralized team typically forms around the highest-risk shared services and starts running PRRs — Google's public documentation of its own history is the most detailed account of this stage. As that centralized team's own toil grows — it's now the org's single largest source of on-call load — it usually starts building the automation it kept reinventing per service, and the platform model emerges out of the centralized team's own tooling rather than as a separate top-down decision. Once that platform exists, a small consulting or enablement pod often spins off specifically to bring the remaining unsupported teams up to the platform's self-service bar, without adding to the centralized rotation's own pager load — this is the concrete mechanism by which an org scales SRE practice past the headcount of its SRE org.

Netflix's own engineering blog has described leaning toward "full-cycle" ownership — each product team runs its own service end to end — backed by strong centralized platform and chaos-engineering tooling rather than a large centralized on-call org; the origin of that chaos tooling, including the original Chaos Monkey, is covered in Netflix & the Simian Army. Treat all of these as publicly reported patterns worth learning from, not literal current org charts to copy — org structures change faster than case studies get written, so verify specifics against each company's own current engineering blog before citing them precisely. The practical takeaway is the sequence, not the destination: pick embedded for your genuinely singular, highest-blast-radius systems; centralize for the broad middle tier of services that need a consistent bar but don't each justify a dedicated pod; build platform once you're large enough that self-service primitives amortize across dozens of consumers; and add consulting/enablement specifically to reach the tail of teams neither the centralized rotation nor the platform's self-service adoption has gotten to yet.

Anti-patterns: when the topology itself becomes the reliability problem

☺ Like you're 10: Each of the four models has its own specific way of quietly turning into "just ops with a new badge" if nobody's watching for it.

Every model above has a matching failure mode, and all five are common enough to name specifically:

• The gateless centralized team. A centralized org that absorbs every team's pager requests without ever actually enforcing its PRR becomes a ticket-processing ops shop wearing an SRE title — precisely the failure mode What is SRE? warns about at the whole-discipline level, just recreated one gate-skipping exception at a time.
• The re-absorbed embedded SRE. An embedded SRE who reports, in practice, to a roadmap optimizing purely for feature velocity slides back into being an extra feature engineer, and the 50% operational-work ceiling erodes with no one outside the team positioned to notice — see toil & automation for how to measure the drift before it's normalized.
• The platform team with no product management. Tooling nobody adopts is worse than no tooling: the org now pays for both the unused platform investment and the old manual toil it was supposed to replace, running side by side indefinitely.
• The parachute-and-leave consultant. An enablement engagement that "checks the box" for a launch review and then disappears with no re-review cadence lets the installed practices decay within a couple of quarters, so the next real incident finds the same gaps the engagement was hired to close.
• Topology mismatched to the actual system boundary. Conway's Law cuts both ways — a single centralized rotation straddling two architecturally independent systems with unrelated failure modes and traffic patterns means one on-call engineer can't hold sufficient context on either, which is exactly the services-per-rotation ceiling from the previous section showing up as missed pages rather than a clean number on a spreadsheet.

None of the four models is a permanent verdict on your organization — they're tools sized to a specific constraint, and the constraint changes as you grow. Organizational Impact of SRE covers the broader cultural and incentive shifts a topology change triggers beyond staffing math, Reliability economics covers the leverage-versus-cost argument for funding a platform team in the first place, and Chaos Engineering at Scale picks up exactly where the platform model's shared fault-injection tooling leaves off.