This model introduces SRE earlier in the lifecycle. It requires identifying services of sufficiently high business value, scale or complexity to benefit from early SRE expertise.

Candidates generally:

  • implement significant new functionality;
  • are a significant rewrite of an existing system, targeting the same use cases; or
  • are developed by a team actively seeking SRE advise or approaching SRE for a takeover upon launch.

By immersing SREs in the development process it fosters active collaboration between the development and SRE teams during the design and subsequent phases.



  • During design, SREs can prevent classes of problems occurring later in production, reducing the amount of rework (and thus cost).
  • Instrumentation, operational and emergency controls can be worked in during build and implementation, easing operations. Efficiency improvements can be made, and cost may be further reduced through recommendation of existing libraries.
  • At launch SREs can implement launch patterns to reduce launch-time service disruption.
  • Post-launch, having a stable system reduces conflicting development priorities and allows a product innovation focus. In later phases, it's possible that lessons learned will help with refactoring or redesign. Regardless, early engagement allows the SRE team to onboard and take over the service sooner than is otherwise possible, and a longer engagement will foster cross-team solidarity.
  • Disengagement might be pursued if the service is low maintenance or traffic enough to no longer warrant SRE attention. This decision might be taken if a service fails to receive the level of expected adoption.