In 2018, the same year that Forsgren, Humble, and Kim published Accelerate — the empirical validation of DevOps practices — approximately 47% of the organisations in the DORA research study were classified as Low performers on the Four Key Metrics. By 2023, that number had not materially decreased. The percentage of Elite and High performers had grown, but the Low performer cohort had not emptied. Instead, the distribution had spread: the gap between the organisations that had successfully adopted modern delivery practices and those that had not was wider in 2023 than in 2018.
This persistence of the Low performer cohort in the face of years of DevOps advocacy, tooling investment, and cultural attention is not evidence that DevOps does not work. It is evidence that the organisational transformation required to become an elite performer is not primarily a tooling problem or a process problem. It is an engineering discipline problem — and the discipline that addresses it, in the specific dimensions where DevOps-focused transformations plateau, is Site Reliability Engineering.
This post maps the journey from DevOps foundations to SRE practice at the enterprise scale. It is not a theoretical model. It is a phased roadmap with specific exit gates for each phase, derived from the observable signals that distinguish genuine phase completion from the stalled adoptions that organisations mistake for progress.
What DevOps Leaves Unresolved
DevOps, as a movement and a set of practices, addresses the delivery pipeline: how code moves from developer to production faster, more safely, and more reliably. The Three Ways (flow, feedback, learning) and the DORA Four Key Metrics are all delivery pipeline metrics. They measure how quickly and safely the organisation can make changes.
What DevOps does not address — cannot address by design — is the production system itself after the change has been delivered. DevOps tells you whether you can ship. SRE tells you whether what you shipped is serving users the way it should, and what to do when it isn't.
────────────────────────────────────────────────────────────────────────────
WHAT DEVOPS ADDRESSES vs WHAT SRE ADDRESSES
DEVOPS ADDRESSES:
→ How code moves from commit to production (delivery pipeline)
→ How quickly defects are detected and corrected in the pipeline
→ How development and operations teams collaborate on the pipeline
→ Deployment frequency, lead time, change failure rate, MTTR
(MTTR here = time to restore a failed deployment, not service reliability)
DEVOPS DOES NOT ADDRESS:
→ What "reliable" means for a specific service from a user perspective
→ How much unreliability is acceptable (and who decides)
→ What the investment ceiling for reliability should be
→ How to detect degradation before it becomes a user-facing failure
→ How to balance release velocity against production stability
(other than the cultural norm of "more deployment frequency = good")
SRE ADDRESSES THE GAPS:
→ SLIs/SLOs: define what reliable means and measure it continuously
→ Error budgets: define how much unreliability is acceptable and who decides
→ Observability engineering: detect degradation before user-facing failure
→ Toil elimination: make the operational investment sustainable
→ Error budget as change gate: formalise the velocity/stability trade-off
────────────────────────────────────────────────────────────────────────────
The DevOps-to-SRE journey is not a replacement of DevOps. It is a completion of it. The delivery pipeline that DevOps builds is the mechanism through which SRE reliability improvements are deployed. The cultural practices DevOps establishes (blameless culture, shared accountability, continuous improvement) are the prerequisites for SRE governance. DevOps must come first. SRE builds on it.
The Four-Phase Roadmap
Phase 0 — Trust and Visibility (Months 1–8)
Phase 0 establishes the measurement infrastructure and the organisational credibility that make all subsequent phases possible. No SRE governance should be attempted before Phase 0 is complete. No SLO should be enforced before the measurement is trusted. No error budget policy should be proposed before stakeholders understand what an error budget is.
────────────────────────────────────────────────────────────────────────────
PHASE 0 OBJECTIVES AND EXIT GATES
OBJECTIVE 1: Instrument the Four Golden Signals for critical services
Exit gate: Latency, Traffic, Errors, Saturation metrics exist in
Prometheus for at least 3 production services.
Sourced from Istio Envoy proxy (not application metrics).
OBJECTIVE 2: Baseline DORA Four Key Metrics
Exit gate: 6 months of DORA data available.
Deployment frequency, lead time, CFR, MTTR all defined
and measured from actual pipeline and incident data.
Not estimated or self-reported.
OBJECTIVE 3: Define SLIs for at least one critical service
Exit gate: SLI defined, instrumented, and visible on a dashboard.
Target SLO agreed with the owning development team.
Error budget calculated but NOT yet enforced.
OBJECTIVE 4: Establish blameless postmortem practice
Exit gate: Three postmortems completed with the full template.
Action items assigned, tracked, and followed up.
At least one action item automated (not just documented).
OBJECTIVE 5: Earn the trust of at least one non-SRE stakeholder
Exit gate: VP of Engineering, operations leader, or compliance lead
is citing SRE data in meetings they initiate.
This gate is qualitative but non-negotiable.
PHASE 0 TIMELINE REALITY:
6–8 months is typical for regulated enterprises.
Organisations that rush Phase 0 produce Phase 1 structures with
no measurement foundation — and then cannot demonstrate the value
that would earn Phase 2 authority.
────────────────────────────────────────────────────────────────────────────
Phase 1 — Measurement and Accountability (Months 8–18)
Phase 1 activates the measurement infrastructure built in Phase 0. Error budget policies go from documented to enforced. The deployment gate fires for the first time. The DORA quarterly report goes to leadership. The first external sign of SRE maturity becomes visible.
────────────────────────────────────────────────────────────────────────────
PHASE 1 OBJECTIVES AND EXIT GATES
OBJECTIVE 1: Enforce error budget policy for pilot services
Exit gate: Error budget gate has fired and blocked at least one
deployment in the pilot service cohort.
The deployment freeze was upheld (not overridden).
Development team accepted the gate without escalation.
Why this gate matters: An error budget policy that has never fired
is a policy that has never been tested. The first firing is the
moment that determines whether the governance is real or decorative.
OBJECTIVE 2: Activate multi-window burn rate alerting
Exit gate: 14×/6×/3×/1× burn rate alerts deployed for all
services with defined SLOs.
Threshold-based alerts eliminated or reclassified.
False positive rate below 10% for Tier 1 alerts.
OBJECTIVE 3: Instrument Toil Ratio and publish quarterly
Exit gate: Toil Ratio measured and below 45% for SRE team.
Top-3 toil categories identified and automation
investment allocated.
Toil Ratio trend visible in DORA quarterly report.
OBJECTIVE 4: First DORA quarterly report to leadership
Exit gate: DORA report presented to VP Engineering or CTO.
Report includes industry benchmark comparison.
At least one DORA metric has improved since baseline.
OBJECTIVE 5: SLO coverage for top-10 services by revenue/risk
Exit gate: SLIs and SLOs defined for top-10 services.
Error budget remaining visible on shared dashboard.
At least 5 services in Tier 1 (budget healthy) policy state.
PHASE 1 COMMON FAILURE MODE:
The first error budget gate fires and is overridden by the VP
of Engineering under business pressure. This is the critical
juncture. If the override happens without documented justification,
the policy becomes decorative. The correct response is not to
accept the override silently — it is to document the override
with the business justification, share that documentation with
the stakeholder who approved it, and begin tracking override rate
as a governance metric. Override rate above 20% is a signal that
either the SLO targets are poorly calibrated or the policy lacks
organisational buy-in.
────────────────────────────────────────────────────────────────────────────
Phase 2 — Platform and Automation (Months 18–30)
Phase 2 is the scalability phase. The practices established in Phase 1 for a small cohort of services are productised into platform primitives that development teams can adopt self-service. The SRE team transitions from implementing reliability practices directly to building the platform that enables development teams to implement them.
────────────────────────────────────────────────────────────────────────────
PHASE 2 OBJECTIVES AND EXIT GATES
OBJECTIVE 1: Self-Service SLO Platform
Exit gate: A development team can define an SLI, set an SLO,
and see their error budget dashboard without SRE
team involvement.
SLO definition template and onboarding documentation
exist and have been used by at least two teams.
OBJECTIVE 2: Automated Toil Elimination (Class 4 Automation)
Exit gate: Postmortem generation is automated.
DORA metric calculation is automated.
Compliance evidence package is automated.
Total toil from these three categories: zero manual hours.
OBJECTIVE 3: Deployment Gate Platform (not per-service scripts)
Exit gate: The error budget PreSync gate is a reusable platform
component deployed via Argo CD with service-specific
configuration only (not code changes).
Any new service can adopt the gate with a ConfigMap change.
OBJECTIVE 4: Toil Ratio below 35%
Exit gate: SRE team Toil Ratio below 35% for two consecutive quarters.
The time freed from toil is demonstrably invested in
engineering work (tracked in sprint metrics).
OBJECTIVE 5: SLO ownership by development teams
Exit gate: At least 3 development teams own their SLOs without
SRE team involvement in day-to-day management.
Development team lead can explain their error budget
state and trend without referring to the SRE team.
PHASE 2 CULTURAL SIGNAL:
The leading indicator of genuine Phase 2 progress is when
development teams request SLO coverage for new services before
the SRE team asks them to. When a product team says "we're
launching a new feature and we need an SLO for it," the SRE
practices have become part of the engineering culture, not an
external programme.
────────────────────────────────────────────────────────────────────────────
Phase 3 — Culture and Scale (Month 30+)
Phase 3 is the generative phase — where SRE practices are embedded in the engineering culture deeply enough to self-propagate. New engineers adopt them because that is how their team works. New services get SLOs because that is part of the launch process. Reliability investment is governed by error budgets because that is how the organisation makes decisions about deployment velocity.
────────────────────────────────────────────────────────────────────────────
PHASE 3 CHARACTERISTICS (not exit gates — emergent properties)
→ The DORA quarterly report is requested by leadership, not delivered
by the SRE team on their own initiative.
→ Error budget overrides are rare (< 5%) and always documented.
The override audit is a routine quarterly review, not a crisis response.
→ New engineers joining the organisation learn SLO practice as
part of their onboarding, from their team leads, without SRE
team involvement.
→ The SRE team's primary activity is reliability architecture
and platform engineering — not incident response, not postmortem
facilitation, not SLO coaching.
→ Reliability investment is a budget line item discussed in
product roadmap planning, not a conversation that the SRE team
has to initiate.
→ DORA metrics are referenced in performance conversations about
engineering teams — not as SRE programme metrics but as
organisational delivery health indicators.
PHASE 3 TIMELINE REALITY:
Phase 3 is not a destination — it is an ongoing state that requires
active maintenance. Organisations that stop investing in the practices
that produced Phase 3 will regress, typically first in Toil Ratio
(compliance obligations grow, automation debt accumulates) and then
in DORA metrics (velocity decreases as reliability investment crowds
out delivery work).
────────────────────────────────────────────────────────────────────────────
The SRE Operating Model: Who Does What
The DevOps-to-SRE transition requires clarity about the operating model — who is responsible for reliability, who owns the SLO, and what the SRE team's role is relative to development teams at each phase.
────────────────────────────────────────────────────────────────────────────
SRE OPERATING MODEL EVOLUTION BY PHASE
PHASE 0 — Centralised Expert Model:
SRE team: Defines, instruments, and monitors all SLOs.
Responds to all SLO-related incidents.
Owns all reliability tooling.
Development teams: Consumers of SLO dashboards.
Participants in postmortems.
Risk: SRE team becomes a bottleneck; all reliability work flows
through a small team with insufficient scale.
PHASE 1 — Hybrid Model (Centralised + Embedded):
SRE team: Maintains platform, governs SLO framework.
Embeds SRE engineers in development teams on rotation.
Development teams: Own their SLOs with SRE support.
Carry on-call alongside SRE.
Progress signal: Development teams raising reliability issues
without waiting for SRE to identify them.
PHASE 2 — Platform Model:
SRE team: Builds and maintains the reliability platform.
Consults on complex reliability problems.
Sets organisational standards; does not enforce them directly.
Development teams: Fully own their SLOs and error budgets.
Self-serve from the reliability platform.
Carry their own on-call; SRE carries escalation only.
Progress signal: SRE team headcount can decrease (or hold steady
as services scale) without reliability degrading.
PHASE 3 — Embedded Model:
SRE function: Distributed across platform engineering and
development teams. "SRE" is a practice, not a team.
Central SRE team focuses on cross-cutting reliability
architecture and organisational standards.
Progress signal: The organisation doesn't need an SRE team to
tell it to invest in reliability.
────────────────────────────────────────────────────────────────────────────
Common Antipatterns
The DevOps Rename antipattern → Renaming the operations team "SRE" without changing the practice. SRE titles without SRE practices are not a transformation; they are a rebranding exercise. The test is not what the team is called. It is whether SLOs are defined, error budgets are enforced, toil is tracked, and postmortems produce automated improvements.
The Tooling-First antipattern → Deploying Kubernetes, Argo CD, Prometheus, and Grafana and concluding that SRE infrastructure is in place. The tooling is necessary but not sufficient. An organisation with the full SRE toolstack and no SLOs, no error budget policy, and no postmortem culture has purchased SRE infrastructure without adopting SRE practice.
The Phase Skip antipattern → Attempting Phase 2 (self-service platform) before Phase 1 (measurement and accountability) is complete. A self-service SLO platform with no development team adoption (because error budgets are not yet enforced) builds infrastructure that nobody uses. Each phase's exit gates exist precisely to prevent this.
The Eternal Phase 0 antipattern → Remaining in Phase 0 indefinitely because the measurement baseline is never "good enough" to justify enforcement. Phase 0 exit gates are pass/fail, not optimisation targets. A team that has three services instrumented, six months of DORA data, and at least one non-SRE stakeholder engaged with the data has met the Phase 0 exit gates — regardless of whether the data looks as clean as the team would like.
The SRE Team as Elite Ops antipattern → Building an SRE team that responds to all production incidents, writes all postmortems, and owns all reliability decisions. This model does not scale and does not produce the Phase 2 and Phase 3 outcomes where development teams own their own reliability. The SRE team's goal is to work itself out of the reactive operations business, not to optimise its ability to perform it.
Maturity Progression
────────────────────────────────────────────────────────────────────────────
PHASE NORTH STAR SIGNAL MOST COMMON STALL POINT
────────────────────────────────────────────────────────────────────────────
Phase 0 Non-engineering stakeholder Skipping toil inventory;
cites SRE data without SLO defined but not
prompting. validated with team.
Phase 1 First error budget gate fires Gate overridden without
and is upheld. documentation; override
rate > 20%.
Phase 2 Development team requests Platform exists but
SLO for new service without development teams don't
SRE involvement. know how to use it.
Phase 3 DORA report requested by Toil Ratio begins rising
leadership without SRE as compliance obligations
initiating it. grow; automation debt
accumulates.
────────────────────────────────────────────────────────────────────────────
Five Action Items for This Week
Assess which phase your organisation is genuinely in using the exit gate criteria. Not the phase you aspire to — the phase the evidence supports. Review each Phase 0 exit gate. If any gate is not satisfied, Phase 0 is not complete, and Phase 1 activities will not produce their intended outcomes.
Identify the operating model your current SRE team uses and whether it matches the appropriate model for your current phase. If you are in Phase 0 but using a Platform Model (where development teams are expected to self-serve), the model is ahead of the practice maturity. Align the operating model to the phase.
Document the DORA baseline if you do not have it. Six months of deployment frequency, lead time, CFR, and MTTR data from actual pipeline and incident records. This is the Phase 0 exit gate that most organisations are missing — not because the data doesn't exist, but because it has not been extracted and presented.
Define the Phase 1 success metrics for your current pilot service before you activate the error budget gate. What does success look like at the end of three months? Pre-committed success criteria prevent the outcome from being interpreted in whatever direction is politically convenient after the fact.
Identify the first development team for Phase 2 self-service SLO adoption. Which team has the highest SRE maturity, the most engaged team lead, and the least regulatory complexity? That team is your Phase 2 pilot. Designing the self-service platform for that team's specific workflow is the starting point for a platform that will eventually serve all teams.
"The journey from DevOps to SRE is not a journey from bad practices to good ones. DevOps practices are genuinely good — they are the prerequisite for what comes after. The journey is from practices that improve delivery to practices that also govern the production system those deliveries create. The organisations that have made it to Phase 3 did not skip the earlier phases. They completed them — slowly, imperfectly, with setbacks — and built on them. There is no shortcut. There is only the sequence."
