Embedded vs consulting SRE engagement models

WHAT THIS TESTS: The interviewer wants to know if you understand that SRE is a scarce resource and that how you deploy that resource determines both reliability outcomes and team scalability. This is an organizational-design question disguised as a definitions question.

A GOOD ANSWER COVERS: The embedded model places one or more SREs directly inside a product team. They share standups, own on-call alongside developers, and build deep system knowledge, producing strong reliability gains for that one service. The cost is narrow coverage and the constant risk that the SRE gets pulled into feature delivery, eroding their reliability mandate. The consulting model has SREs act as advisors across many teams through production readiness reviews, design consultations, and best-practice guidance. It scales reach across the org but sacrifices depth, hands-on fixes, and direct authority. A strong answer ties the choice to context: company size, number of critical services, SRE headcount, and the maturity of the product teams.

COMMON WRONG ANSWERS: Declaring embedded strictly superior because it is hands-on, or consulting superior because it scales, without acknowledging the trade-offs. Confusing these with platform or infrastructure teams.

LIKELY FOLLOW-UPS: How do you prevent embedded SREs from becoming just extra developers? How do you transition a team from consulting to embedded as it grows? When would you withdraw SRE support entirely and hand reliability back to the product team?

ONE CONCRETE EXAMPLE: A payments service handling money gets embedded SREs because the reliability stakes justify dedicated depth. Meanwhile, twenty internal tooling teams share two consulting SREs who run readiness reviews and publish runbooks, accepting shallower coverage because the blast radius of each service is small.