Guide

Someone has to answer the page, and the question of who that is shapes everything else. There are three common models. Developer-owned on-call means the team that builds a service also runs it. Dedicated SRE or platform on-call means specialists run the systems. A hybrid splits the work, so platform specialists own shared infrastructure and product teams own their service pages.

The big idea

Think of a restaurant. In one kitchen, each cook is responsible for their own station, and a bad dish comes back to the cook who made it. In another, a separate team cleans up after everyone. The first gets fast feedback. The second gets deep specialist skill. The worst setup is when the cleaning team also has to fix the cooks' recipes.

Walking through it

ModelStrengthWeakness
Developer-ownedFast feedback, real ownership, fewer throw-it-over-the-wall bugsBurns out product engineers unless the platform and rotations are humane
Dedicated SRE or platformDeep operational skill and a consistent processTurns into a ticket sink when product teams do not share the work
HybridSRE owns shared platforms, and product teams own their service pagesNeeds clear boundaries and a shared SLO language

Trade-off

Prefer developer-owned on-call for the services a team ships, once paging is sane and a platform team provides paved roads for deploys, metrics, secrets and dashboards. Prefer dedicated SRE when the blast radius is company-wide infrastructure, or when regulation needs a specialized practice.

The failed middle deserves a name. It is when SRE takes every page for product bugs that the product team could fix. That trains nobody, and it overloads the specialists. The people who change the code should feel its pages. That keeps reliability work competing fairly with features, rather than being someone else's night problem.

Platform engineering exists partly to make developer on-call survivable, because golden paths beat tribal knowledge.

Common anti-patterns

  • Hero rotation. The same two seniors take every hard week. The knowledge never spreads, and those two eventually quit.
  • Silent secondary. The backup is never paged or practiced, and then fails when the primary is unreachable.
  • Page-as-ticket. Overnight noise for work that should wait until morning. People learn to ignore the pager, including on the night something is actually on fire.
  • No error-budget link. Product ships risk, while on-call absorbs the pages with no authority to slow releases. Tie paging pain to SLO policy, so the organization chooses on purpose.
  • Runbook theater. Beautiful docs that nobody opens, because the alerts do not link to the right section.

Check yourself

  1. A product team's bugs keep paging the SRE team. Which model has failed, and what is the fix? The failed middle. Move those pages to the product team that owns the code, with the platform's support.
  2. Why do the people who change the code need to feel the pages? It makes reliability work compete fairly with features, and it gives the owners the best feedback.

Key takeaways

  • Developer-owned, dedicated SRE and hybrid each fit different systems.
  • Prefer developer-owned for services once paved roads and humane rotations exist.
  • Avoid the failed middle, where specialists take product bugs they cannot fix.

Further learning

The career side of owning production is in production ownership. The platform side is in platform engineering.

Google's SRE Workbook and the Spotify talk both cover team models in practice.

Being On-Call (Google SRE book)Proven strategies for on-call engineers to ensure reliable services and maintain sustainable workloads in IT operations.sre.google