One Team, One Mission
In the Embedded model, an SRE is placed directly inside a specific product team — for example, the "Checkout Service" team or the "Payments" team. They attend standups, share the same backlog, and are accountable to the same product roadmap.
How it works day-to-day:
The embedded SRE acts as a reliability co-pilot. They review code for operability concerns (missing metrics, poor error handling, no graceful shutdown), help define SLOs for the service, own the on-call rotation alongside the developers, and build automation specific to that service's failure modes. Over time, they transfer reliability knowledge to the developers so the whole team can reason about production.
When it works well:
- The service is complex, high-stakes, and has unique failure modes that require deep context (e.g., a real-time trading engine or a payment processor).
- The product team is large enough that one SRE isn't overwhelmed by operational requests.
- There is a clear charter: the SRE is there to improve reliability, not to be the team's personal sysadmin.
The Silo Risk — the critical failure mode:
If the embedded SRE is the only person on a team of 10 developers who understands production, they become a single point of failure and a bottleneck. Developers learn to route all operational questions through them rather than building their own operational competence. The SRE gets pulled into manual work, loses time for engineering, and the model collapses into a micro-scale Kitchen Sink. The fix is a formal charter that defines what the SRE will and won't do, and a rotation policy that prevents any one SRE from being embedded indefinitely.