In the autumn of 2019, an SRE practitioner joined a mid-size financial services firm as their first dedicated reliability engineer. Within six weeks, they had drafted a comprehensive SRE adoption roadmap: error budget policies, SLO frameworks, on-call rotation design, postmortem processes, toil reduction programmes. The documents were detailed, well-researched, and entirely aligned with Google SRE practice. They were presented to the VP of Engineering in a forty-minute session.
The VP thanked them for the work. The roadmap was filed. Nothing changed.
Eighteen months later, after a significant production incident that the SRE's observability stack had predicted three hours before it occurred — and whose postmortem the SRE wrote, facilitated, and tracked to completion — the same VP approached the SRE with a question: "Can you help us do this for all of our services?"
The difference between the forty-minute presentation and the VP's question was not the quality of the SRE practices being proposed. It was the sequence in which the SRE's authority to propose them had been established. The roadmap arrived before the credibility. The question arrived after eighteen months of demonstrated value. Same practices. Radically different reception.
This is the fundamental insight behind the phased influence playbook: in resistant organisations, the sequence of value demonstration matters as much as the quality of what is being demonstrated. This post documents that sequence.
Why Organisations Resist
Before designing an influence strategy, the nature of the resistance must be understood. Most SRE practitioners in resistant organisations misdiagnose resistance as irrationality — as leadership failure, as bureaucratic inertia, as cultural backwardness. This diagnosis produces the wrong response: more comprehensive proposals, more persuasive presentations, more detailed roadmaps.
The resistance in most regulated enterprises is rational. Leadership has seen many technology transformation initiatives that promised operational improvement and delivered disruption, cost overruns, and staff attrition. Change management processes were built to slow down exactly the kind of rapid, practitioner-driven change that SRE adoption requires. Risk aversion is not a cultural defect — it is a rational response to regulatory environments where the cost of change-caused incidents includes regulatory fines, audit findings, and reputational damage that dwarf any efficiency gain.
The implication is that SRE adoption in resistant organisations cannot be sold. It must be demonstrated. And the demonstration must be structured to make its value legible to the specific stakeholders who control the resources and authority that SRE adoption requires.
────────────────────────────────────────────────────────────────────────────
STAKEHOLDER INFLUENCE MAP
STAKEHOLDER WHAT THEY CARE ABOUT SRE VALUE TO DEMONSTRATE
────────────────────────────────────────────────────────────────────────────
Engineering VPs Delivery velocity Deployment frequency
Team capacity Toil reduction (hours saved)
Incident reduction MTTR improvement
Operations Leaders Stability Incident rate reduction
On-call sustainability Alert quality (volume down)
Team attrition risk On-call burden reduced
Compliance/Risk Audit findings Automated evidence generation
Regulatory exposure Error budget = risk appetite
Change control GitOps = change audit trail
Finance/CFO Cost of incidents Downtime cost quantified
Infrastructure cost SOT-based right-sizing savings
Headcount efficiency Toil hours → engineering hours
Product Feature velocity Error budget → deploy faster
SLA commitments SLO → customer commitment
Market competitiveness DORA metrics vs. industry
────────────────────────────────────────────────────────────────────────────
CRITICAL INSIGHT: Present the same SRE practice differently to each.
Error budget to compliance = risk appetite framework
Error budget to product = release velocity governor
Error budget to finance = quantified incident cost ceiling
The practice is identical; the vocabulary is tailored.
────────────────────────────────────────────────────────────────────────────
The Five-Phase Playbook
Phase 0 — Establish a Measurement Baseline (Weeks 1–8)
Phase 0 is the most counterintuitive phase because it involves doing nothing that looks like SRE adoption. Its entire purpose is to establish the measurement infrastructure that will make every subsequent phase's value visible.
────────────────────────────────────────────────────────────────────────────
PHASE 0 ACTIVITIES AND RATIONALE
ACTIVITY 1: DORA Metric Baselining
Action: Instrument deployment frequency, lead time, CFR, and MTTR
from existing CI/CD and incident management data.
Do not propose changes; only measure current state.
Rationale: The baseline is the before-picture that makes future
improvement legible. SRE improvements without a baseline
cannot be attributed to SRE.
Artefact: DORA baseline report (internal only; do not present yet)
ACTIVITY 2: Toil Inventory
Action: Run the recurring-incident Splunk query. Classify every
on-call event from the last 90 days as toil or engineering.
Quantify toil in hours per sprint.
Rationale: Toil hours are the currency of the capacity conversation.
"We spend 44% of SRE time on toil" is actionable.
"We have a lot of manual work" is not.
Artefact: Toil inventory spreadsheet (internal only)
ACTIVITY 3: Deployment Correlation Setup
Action: Configure the Argo CD sync event log and incident data to
produce a deployment correlation view: deployments plotted
against incident rate over the last 90 days.
Rationale: This artefact will be the Phase 1 leadership conversation
entry point. It must be ready before that conversation
is attempted.
Artefact: Deployment correlation dashboard (ready but not presented)
PHASE 0 EXIT CRITERIA:
✓ DORA baseline documented for at least one service
✓ Toil inventory complete and categorised
✓ Deployment correlation dashboard operational
✓ No SRE adoption proposals made to leadership yet
PHASE 0 COMMON FAILURE MODE:
Skipping Phase 0 to move directly to Phase 1.
Result: Phase 1 conversations happen without data.
The stakeholder asks "what's the evidence?" and the practitioner
has no answer. The conversation closes. Credibility is harder
to recover than it would have been to establish.
────────────────────────────────────────────────────────────────────────────
Phase 1 — Solve Visible Pain (Weeks 8–20)
Phase 1 is the earning phase. The practitioner identifies the pain that already exists, articulates it in data, and solves it — without proposing SRE adoption, without requesting additional authority, and without naming what they are doing as anything other than solving the problem.
────────────────────────────────────────────────────────────────────────────
PHASE 1 ACTIVITIES
THE DEPLOYMENT CORRELATION PRESENTATION:
Target audience: Engineering VP or equivalent
Duration: 20 minutes (no more)
Content: Show the deployment correlation dashboard.
Ask: "Does this pattern match your experience?"
Listen. Do not present a solution yet.
Purpose: Establish that you have data. Establish that you are
solving the right problem. Let the stakeholder name
the consequence before you propose the intervention.
THE FIRST AUTOMATION INVESTMENT:
Select the highest-ROI toil item from the Phase 0 inventory.
Build the automation. Ship it.
Quantify the hours saved per sprint.
Report it informally — not as an SRE initiative, but as
"I automated the X process; we got back N hours per sprint."
THE FIRST SLO (SINGLE SERVICE):
Define one SLI and one SLO for the service with the most
visible reliability pain. Do not enforce an error budget yet.
Simply make the SLO visible: "Here is the target. Here is where
we currently are. Here is the trend."
Purpose: Creates the vocabulary before the governance conversation.
PHASE 1 EXIT CRITERIA:
✓ At least one automation shipped with quantified hours saved
✓ Deployment correlation dashboard presented and acknowledged
✓ One SLO visible to engineering team
✓ At least one stakeholder has asked "can we do this more broadly?"
(This question is the Phase 1 success signal)
PHASE 1 TIMELINE REALITY:
Phase 1 takes 3–6 months in most regulated enterprises.
The temptation to rush it — to present the full roadmap while
the stakeholder is receptive — is the most common adoption failure.
The question "can we do this more broadly?" is an invitation
to demonstrate, not to propose. The demonstration comes in Phase 2.
────────────────────────────────────────────────────────────────────────────
Phase 2 — Create Visible Artefacts (Weeks 20–32)
Phase 2 scales the evidence base. The artefacts produced in Phase 1 (one automation, one SLO) are replicated across more services and made visible to a wider audience. The goal is to create the organisational conversation about reliability before proposing its governance.
────────────────────────────────────────────────────────────────────────────
PHASE 2 ARTEFACTS
ARTEFACT 1: DORA QUARTERLY REPORT
Content: DORA Four metrics for all tracked services, trend lines,
comparison to industry benchmarks.
Audience: Engineering VPs, optionally CTO.
Format: One-page executive summary + detail appendix.
Purpose: Establishes DORA as the measurement vocabulary before
proposing DORA-based governance.
Cadence: Quarterly. Consistency matters more than single-point data.
ARTEFACT 2: TOIL REDUCTION REPORT
Content: Hours saved this quarter through automation; categories
eliminated; Toil Ratio trend.
Audience: Engineering VP + Operations leadership.
Format: Half-page summary with hours and business impact.
Purpose: Quantifies the ROI of the reliability engineering investment
already made — making the case for more investment implicitly.
ARTEFACT 3: INCIDENT TREND REPORT
Content: Incident rate trend over the past 6 months; correlation with
deployment events; top-3 recurrence categories.
Audience: Operations leadership + (optionally) Risk/Compliance.
Format: One-page with trend chart.
Purpose: Surfaces the recurrence pattern that the error budget policy
will address — without naming the error budget policy yet.
ARTEFACT 4: SLO COVERAGE MAP
Content: Which services have SLOs defined; what the current vs. target
reliability is for each; which services have no SLO.
Audience: Engineering leadership.
Purpose: Makes the measurement gap visible; creates demand for coverage.
PHASE 2 SUCCESS SIGNALS:
→ DORA report is circulated beyond engineering team
→ Operations leadership asks for the incident trend data regularly
→ Someone outside the SRE function references the SLO data in a meeting
→ Leadership mentions SRE in a context the practitioner did not initiate
PHASE 2 EXIT CRITERIA:
✓ DORA report presented twice (two quarters of data)
✓ Toil reduction quantified and reported
✓ At least 5 services have SLOs visible
✓ At least one non-engineering stakeholder is engaged with the data
────────────────────────────────────────────────────────────────────────────
Phase 3 — Earn the Governance Conversation (Weeks 32–44)
Phase 3 is where the error budget policy, the deployment gate, and the formal SRE governance framework are proposed — for the first time, having never been mentioned before. The timing is critical: this conversation happens only after Phase 2 has created the data and the stakeholder relationships that make the governance proposal land as a logical next step rather than an unsolicited transformation initiative.
────────────────────────────────────────────────────────────────────────────
PHASE 3: THE GOVERNANCE CONVERSATION
PREREQUISITES (all must be true):
✓ Phase 2 artefacts have been presented at least twice
✓ At least one non-engineering stakeholder is engaged
✓ The deployment correlation pattern is accepted as real
✓ The DORA baseline is documented and communicated
THE CONVERSATION STRUCTURE:
1. Reference the data: "Over the last six months, we've been tracking..."
2. Name the pattern: "Deployments are the leading correlation with
incident rate. This is what the error budget addresses."
3. Propose the pilot: "I'd like to implement error budget policy for
one service, with the full team aware of the gate. Not for all
services — just one, for one quarter."
4. Define success: "At the end of the quarter, we'll have data on
whether the gate changed our deployment outcomes."
5. Name the authority needed: "This requires the CAB to accept
the error budget state as a factor in change risk assessment."
WHAT TO PROPOSE (specific, limited, reversible):
✓ Error budget policy for ONE service (the one with the most data)
✓ 90-day pilot with defined success criteria
✓ Opt-in participation from the development team that owns the service
✓ Override authority clearly documented
WHAT NOT TO PROPOSE:
✗ Organisation-wide SRE transformation
✗ Restructuring of operations teams
✗ Mandatory on-call rotation changes
✗ Any change that requires executive approval above VP level
PHASE 3 FAILURE MODES:
Proposing too broadly: "We need to implement error budgets for all
production services" → rejected as too disruptive
Proposing without prerequisites: Phase 3 without Phase 2 data
→ no evidence base → stakeholder cannot evaluate the proposal
Proposing the process before the outcome: describing the error
budget mechanism before establishing why the mechanism is needed
→ answer to a question that has not been asked
────────────────────────────────────────────────────────────────────────────
Phase 4 — Pilot (Weeks 44–56+)
The pilot is the evidence factory. Its purpose is not to prove that SRE works in general — the Google SRE Book does that. Its purpose is to prove that SRE works in this organisation, with these teams, in this regulatory environment, on this infrastructure.
────────────────────────────────────────────────────────────────────────────
PHASE 4: PILOT DESIGN AND EXECUTION
PILOT SERVICE SELECTION CRITERIA:
✓ Team that opted in (not assigned)
✓ Sufficient historical incident data for comparison
✓ Not in a regulated namespace (reduces compliance complexity)
✓ Development team has deployment authority (change gate is meaningful)
✗ Not the most critical production service
✗ Not a service with no previous incidents (nothing to improve)
PILOT SUCCESS METRICS:
Primary: Did deployment-caused incidents decrease during the pilot?
Secondary: Did MTTR improve?
Secondary: Did error budget policy changes modify developer behaviour?
Counter-metric: Did delivery velocity decrease? (Should not)
Qualitative: Did the development team find the policy useful or disruptive?
PILOT DOCUMENTATION:
Week 2: Initial SLO calibration meeting notes
Week 6: Mid-pilot data review (internal)
Week 12: Pilot results report
→ DORA delta vs. pre-pilot baseline
→ Error budget consumption trend
→ Developer team feedback (survey)
→ Recommendation: expand, modify, or discontinue
WHAT MAKES PILOTS FAIL:
→ Service selected has no deployment authority (gate is decorative)
→ Team was assigned, not opted in (compliance without engagement)
→ Success metrics not defined before pilot starts
(results can be interpreted in any direction without pre-committed criteria)
→ Pilot runs during an unrelated major incident that distorts the data
────────────────────────────────────────────────────────────────────────────
Phase 5 — Scale from Evidence (Weeks 56+)
Phase 5 begins only after the pilot has produced data. The expansion proposal is not "let's do SRE everywhere" — it is "the pilot showed X% reduction in deployment-caused incidents; here is the proposal to replicate that result for the next three services."
Each Phase 5 expansion is a smaller version of the full five-phase sequence: new evidence gathered, new artefacts created, new governance conversations earned, new pilots designed. The pace is determined by evidence, not by enthusiasm.
Organisational Archetypes and Adaptation
The five-phase sequence is the general framework. Each organisation has specific characteristics that require adaptation.
────────────────────────────────────────────────────────────────────────────
ORGANISATIONAL ARCHETYPES
ARCHETYPE 1: THE CHANGE-BOARD-HEAVY ENTERPRISE
Characteristic: Every production change requires CAB approval.
Deployment frequency is monthly at best.
Adaptation: Phase 1 entry point is the deployment correlation
dashboard presented to the CAB chair, not Engineering VP.
Frame: "We can help the CAB make better risk decisions."
Phase 3 governance conversation targets CAB process
reform before error budget enforcement.
ARCHETYPE 2: THE SILOED-OPERATIONS ORGANISATION
Characteristic: Development and operations teams have no shared
metrics, no shared on-call, no shared accountability.
Adaptation: Phase 1 focuses on a single service where the
development team has expressed readiness for joint
accountability. Do not attempt cross-silo conversation
before cross-silo relationships exist.
Phase 3 proposes joint SLO ownership, not on-call merge.
ARCHETYPE 3: THE COMPLIANCE-FIRST CULTURE
Characteristic: Every initiative is evaluated through the compliance
function's lens first. Risk aversion is structural.
Adaptation: Phase 2 artefacts include compliance vocabulary.
Error budget = risk appetite framework.
GitOps audit trail = automated compliance evidence.
Phase 3 governance conversation happens with compliance
present, not around them.
ARCHETYPE 4: THE INCIDENT-DRIVEN OPPORTUNITY
Characteristic: A major incident has created executive visibility
for the reliability problem.
Adaptation: Phase 0 and 1 can be compressed if the incident
postmortem provides the data that Phase 0 would have
produced. The post-incident window is the highest-
receptivity moment for Phase 3 conversations.
Warning: this window closes within 6–8 weeks.
Have Phase 3 ready before using the incident as leverage.
────────────────────────────────────────────────────────────────────────────
Common Antipatterns
The Roadmap Presentation antipattern → Presenting a comprehensive SRE transformation roadmap before establishing credibility through demonstrated value. The roadmap document is evidence of investment in thinking. It is not evidence of value delivered. Stakeholders in resistant organisations cannot evaluate a roadmap they have no basis to trust. The roadmap arrives in Phase 5 as documentation of what already worked, not in Phase 0 as a proposal for what might.
The Authority Before Credibility antipattern → Requesting authority (over deployments, over on-call structure, over change management) before demonstrating the value that would justify the authority. Authority granted without demonstrated value is resented and will be revoked after the first controversy. Authority granted after demonstrated value is protected by the stakeholders who experienced that value.
The Single-Service Bypass antipattern → Implementing a successful pilot on one service and then proposing organisation-wide adoption without a second pilot. One data point is evidence of possibility. Two data points from different teams are evidence of repeatability. Repeatability is what converts a pilot result into an organisational programme.
The Compliance-Hostile Framing antipattern → Presenting error budget policies, deployment gates, and change management reforms as replacements for existing compliance processes rather than improvements to them. In regulated enterprises, compliance functions have veto authority over operational changes. Proposals that are perceived as threatening compliance governance will be vetoed. Frame SRE practices as tools that make compliance more effective, not as alternatives to it.
The Wrong Room antipattern → Presenting the deployment correlation dashboard to the engineering team (who already believe deployments cause incidents) rather than to the Engineering VP (who controls the resources to address the pattern). The artefacts are not for the team that already understands the problem. They are for the stakeholder who controls the investment that would address it.
Maturity Progression
────────────────────────────────────────────────────────────────────────────
STAGE INFLUENCE MATURITY NORTH STAR SIGNAL
────────────────────────────────────────────────────────────────────────────
Reactive SRE proposals rejected. "We tried to implement
No data. No artefacts. SRE but leadership
Influence approach: didn't support it."
persuasion by conviction.
Defined Phase 0 and 1 complete. Leadership references
DORA baseline exists. deployment correlation
First automation shipped. data without prompting.
Deployment correlation Toil reduction hours
presented. tracked quarterly.
Measured Phase 2 artefacts produced Non-engineering
consistently. DORA quarterly stakeholder engaged.
report circulated. Phase 3 conversation
Compliance vocabulary had and pilot proposed.
established.
Optimised Pilot complete with positive Second service
results. Phase 5 expansion expansion underway.
underway. CAB process CAB uses error budget
reformed. Error budget state in risk assessment.
policy active for pilot
service.
Generative SRE governance embedded in Engineering leaders
organisational processes. trained in SRE.
Compliance function is Platform team abstracts
an SRE ally. Multiple reliability. External
teams own their SLOs. recognition of programme.
────────────────────────────────────────────────────────────────────────────
Five Action Items for This Week
Identify which phase you are currently in. Not which phase you want to be in — which phase the evidence supports. If you have not yet presented the deployment correlation dashboard to the Engineering VP, you are in Phase 0 or Phase 1 regardless of what you have built. Accurate phase assessment is the prerequisite for the right next action.
Run the Phase 0 toil inventory using the Splunk recurring-incident query. Classify each output item as toil or engineering work. Calculate your current Toil Ratio. This number is your Phase 2 artefact starting point and your Phase 1 automation investment ROI metric.
Build the deployment correlation dashboard if you have not already. Argo CD sync events plotted against incident rate over 90 days. This is the single highest-conversion artefact in the playbook — the one that most reliably opens the governance conversation. It should be ready before any Phase 1 conversation with leadership.
Identify the single service that would make the best Phase 4 pilot. Apply the selection criteria: opted-in development team, deployment authority, not a regulated namespace, historical incident data available. Name it. Having the pilot service identified means the Phase 3 governance conversation has a concrete proposal, not a conceptual one.
Audit your last three SRE adoption conversations for timing errors. Did you propose a governance change before demonstrating the value it was designed to protect? Did you present a roadmap before establishing credibility? Did you request authority before earning it? The timing errors in past conversations are the map for correcting the sequence in the next ones.
"SRE adoption in resistant organisations fails when practitioners treat resistance as an obstacle to overcome rather than as information about the sequence in which trust must be established. The five-phase playbook is not a political strategy for working around resistant leadership. It is an engineering approach to the influence problem: instrument first, demonstrate value second, propose governance third. The sequence is not optional. It is why some SRE programmes grow and others stall."
Top comments (0)