SRE Engagement Models: From Gatekeeper to Platform Builder

WHY IT EXISTS SRE teams have limited capacity and cannot support every service in an organization. They need a structured process to decide which services to take on and how to apply their expertise for maximum impact. Without a formal model, SRE becomes a chaotic, reactive fire-fighting team, and development teams lack a clear path to get reliability support.

THE MENTAL MODEL Think of SRE engagement as an evolution in leverage. You can give a team a fish (run their service for them), teach them to fish (consult on best practices), or build a fish farm (provide a reliable platform they can build on). Each step provides more leverage and scales the SRE team's impact across the organization, moving from direct intervention to systemic improvement.

HOW IT WORKS Engagement models exist on a spectrum, typically evolving as an organization matures. Three common models are: First, PRR-Driven Onboarding: The classic model where a development team builds a service, then asks SRE to run it. The SRE team conducts a Production Readiness Review (PRR) to audit the service's reliability and operability. If it passes, SRE takes it on. This is often reactive. Second, Early Engagement: SREs are involved during the design and development phases. They act as consultants, helping the development team build a reliable service from the start. This is proactive and much cheaper than fixing problems after launch. Third, SRE Platform: The most scalable model. The SRE team builds and maintains a platform of validated, reliable infrastructure (e.g., compute, CI/CD, monitoring). Product teams build on top of this platform, inheriting reliability by default and focusing on business logic.

WHEN TO USE IT Use a formal engagement model when you need to prioritize SRE work, scale the team's impact, and create a clear, fair process for development teams. It's crucial for moving from a "dev vs. ops" mentality to a collaborative one. The platform model is especially powerful in large organizations with many services sharing common infrastructure needs.

WHEN NOT TO USE IT A highly formal, PRR-heavy process might be overkill for a very small startup where everyone is a generalist. However, the underlying principles of early consultation and building common platforms are almost universally applicable. The key is to match the formality of the model to the scale of the organization.

ONE CANONICAL EXAMPLE A team wants SRE to support their new billing service. In a PRR-driven model, SRE provides a long checklist of requirements (SLOs, monitoring, rollback plans) that must be met first. In an early engagement model, an SRE would have joined the team's design meetings months ago. In a platform model, the team would have built the service on the company's "Paved Road" platform, which already provides logging, monitoring, and deployment tooling, making the final SRE handover much simpler.