Practice area · built

Change is the cause most often found and least often modelled.

“What changed recently?” is the first useful question in any incident, and a deployment is the root cause in a large share of them. Yet change is usually the practice with the weakest data — risk levels picked from a dropdown, rollback plans that say “redeploy the previous version,” and a weekly board reviewing printer driver updates. These seven skills route by risk instead: automated gates and peer review carry the volume, and humans review what actually needs a human.

See it run

One change, intake to review.

A database migration — the same one that causes the Sev1 on the incident page. Watch it move through assessment, authorization, scheduling and implementation, then come back through post-implementation review once it fails.

change · CHG-2291 db-migration

"Run all" streams the whole change lifecycle. "Step through" reveals one skill's output at a time.

The skills

Seven skills, request to review.

Each one's actual source is viewable below — not a description of what it does, the real instructions.

01
Intake & classification

Standard, normal or emergency — and the discipline that an emergency is one where waiting causes harm, not one that's merely late.

Why this skill exists

The classification decision determines everything downstream: who authorizes, how long it takes, what evidence is required, and whether it can proceed today or waits a week. Get it wrong in the permissive direction and unassessed risk reaches production. Get it wrong in the restrictive direction and teams route around the process entirely, which is worse — an organization with a slow change process doesn't get fewer changes, it gets undocumented ones.
The other half of the job is extracting what's actually changing. "Deploying the new release" is not a change description. Assessment is impossible without specifics, and a change record that can't be assessed will either be rubber-stamped or bounced, both of which waste everyone's time.

● Full skill source is encrypted. Unlock at the foot of this page to read it.
02
Risk & impact assessment

Impact and likelihood derived from facts rather than picked from a dropdown, with reversibility weighed as its own axis and the point of no return named.

Why this skill exists

Most change risk assessment is theatre: a requester picks "Low" from a dropdown because Low moves faster, and nobody challenges it. The result is a process that consumes real time and produces no actual risk signal. A useful assessment has to be derivable from facts about the change rather than asserted by the person who wants it approved, and it has to distinguish the two things that get conflated constantly — how likely this is to go wrong, and how bad it is if it does.

● Full skill source is encrypted. Unlock at the foot of this page to read it.
03
Authorization

Routes to the lightest authority that gives real assurance — pipeline gates and peer review for most changes, human review only on a defined trigger like a freeze or an untested rollback.

Why this skill exists

The most common failure in change management is routing every change through a weekly board meeting regardless of risk. That practice is an ITIL v3 misapplication, not what the framework asks for — a CAB advises on risk and scheduling for major changes; it was never the approval authority. **Automated testing, policy checks and CI/CD pipeline gates are themselves valid Change Authorities** for low-risk changes, and treating them as such is what lets a change process scale.
The evidence on this is unusually clear. Research across the State of DevOps reports found that approval by a body external to the implementing team was negatively correlated with lead time, deployment frequency and restore time — and had *no correlation at all* with change failure rate. Organizations with formal external approval were substantially more likely to be low performers. The board does not catch the bad changes; it slows down the good ones, which pushes teams toward larger, less frequent batches that are themselves riskier.

● Full skill source is encrypted. Unlock at the foot of this page to read it.
04
Schedule & conflict

Freeze windows, collisions on shared dependencies, cumulative risk in a window, and whether anyone competent is on call when it lands.

Why this skill exists

Most change failures that look like technical failures are actually scheduling failures. Two changes touched the same dependency in the same window and nobody noticed. A migration ran during month-end close. A deployment went out on a Friday afternoon into a weekend with one person on call. The change itself was fine; the timing made recovery hard.
Scheduling is also where change enablement pays back the rest of the organization. A maintained forward schedule of change is what lets the service desk anticipate call volume, and what lets an incident responder answer "what changed recently?" in seconds rather than by asking around.

● Full skill source is encrypted. Unlock at the foot of this page to read it.
05
Implementation & rollback

Ordered steps with per-step verification, abort criteria pre-committed before the pressure starts, and a rollback plan that says whether it's ever been tested.

Why this skill exists

"Rollback: redeploy the previous version" is the most common rollback plan in existence and one of the least useful. It ignores database migrations that don't reverse, caches holding the new shape of data, downstream consumers that already received new fields, and the fact that nobody has ever tested whether the previous version still starts against the current state of the world.
A real rollback plan answers a harder question: *given that we are partway through and something is wrong, what do we do?* That's a different question from "how do we undo this once it's finished," and it's the one that matters at 3am.

● Full skill source is encrypted. Unlock at the foot of this page to read it.
06
Emergency change

The expedited path during an incident — compressed assessment, named authorization, announced on the bridge, documented after.

Why this skill exists

During a Sev1, the normal change process is an obstacle and everyone knows it. The risk is that "emergency" becomes the path of least resistance — a category that absorbs anything inconvenient to schedule, until the organization is running most of its changes with no assessment and no record of who approved what.
The purpose of this skill is to make the emergency path *fast enough to use properly*. If the legitimate emergency route is genuinely quick, people stop routing around it. If it's slow, they push changes with no record at all, which is the outcome the process exists to prevent.

● Full skill source is encrypted. Unlock at the foot of this page to read it.
07
Post-implementation review

Was it successful, did it cause anything, and was the risk assessment actually right — the calibration loop that makes the rest of it worth doing.

Why this skill exists

Without a review step, change management is an approval process with no feedback loop — risk assessments are never checked against outcomes, so they never get better, and the same categories of change fail repeatedly for the same reasons. The PIR is where change enablement earns the time it costs everyone, because it's the only step that improves the process rather than just running it.
It's also where the most useful metric in the whole practice comes from: whether changes assessed as low risk actually behave like low-risk changes.

● Full skill source is encrypted. Unlock at the foot of this page to read it.

The core decision

Who — or what — authorizes this change.

The most common failure in change management is routing every change through a weekly board regardless of risk. That's an ITIL v3 misapplication, not what the framework asks for: a CAB advises on risk and scheduling for major changes; it was never the approval authority. Automated testing, policy checks and CI/CD gates are themselves valid Change Authorities.

What the research found

Across the State of DevOps reports, approval by a body external to the implementing team was negatively correlated with lead time, deployment frequency and restore time — and had no correlation at all with change failure rate. Organizations with formal external approval were substantially more likely to be low performers. The board doesn't catch the bad changes; it slows down the good ones, pushing teams toward larger, less frequent batches that carry more risk.

Elite performers run change failure rates around 5% while deploying far more frequently than low performers, who fail closer to 40%. Speed and stability come from the same underlying practices — they don't trade off.

Lighter routing is not a lower bar

It would be easy to read the research above as “most changes should sail through.” That's the wrong conclusion. The organizations that moved furthest from weekly boards have stricter change control than typical enterprises — it's enforced by policy and progressive exposure rather than by a meeting.

Progressive exposure is mandatory

Large cloud platforms roll changes through a canary carrying no production traffic, then pilot regions, then progressively broader ones — with mandatory bake times between stages, commonly around 24 hours, deliberately sized to expose the change to a full spectrum of load including a peak period. Rollouts respect availability zones and region pairing, so a change reaches one zone before its neighbours.

Health signals are centrally defined

Not chosen by the implementing team. Deployment halts automatically on negative signal, and circuit breakers cut traffic to a degrading service without waiting for a human to notice. That is a harder gate to pass than a committee that meets on Tuesdays.

Significant changes still face a board

Production Readiness Reviews and Operational Readiness Reviews are exactly that — a cross-functional panel examining monitoring, scaling, dependencies, failure modes and rollback. At one major provider, passing one is a prerequisite for the reliability team accepting operational responsibility at all. The difference is the trigger: significance, not the calendar.

Emergencies accelerate gates, don't remove them

Published emergency protocols allow reducing bake time and accelerating promotion stages — but require defining in advance who can authorize that acceleration and what criteria must be met. The gates still run, out of band, as fast as possible.

So the distinction isn't controlled versus uncontrolled. It's control that is automated, mandatory and applied to every change, versus control that is manual, scheduled and applied by people with no context on most of what they're reviewing. The first is more rigorous. An organization that removes the board without building the gates hasn't modernized its change process — it has abandoned it.

The test before delegating any change class to the automated path: would the gates actually catch this failure mode? If the likely failure is slow-building resource exhaustion under production load, a green test suite and a fifteen-minute canary will not see it — and the honest answer is that the automated path doesn't yet provide assurance for that change.

Standard Automated — pipeline gates & policy checks No human approval. The procedure was approved.

Low Peer review + automated gates Async, in the development platform. No meeting.

Medium Named change authority — service owner or delegate Async approval against the record. No meeting.

High Board, advising the change manager Genuinely major changes only.

Emergency ECAB or standing on-call authority Immediate, verbal, recorded after.

Human review fires on a trigger, not by default

Escalation should be caused by a specific condition, not by seniority anxiety. Asking five senior engineers to review a driver update every Tuesday is how you train capable people to rubber-stamp things — which destroys the board's value for the changes that genuinely need it.

Freeze period — financial close, peak trading, major customer event, stabilization freeze
Insufficient testing time — the automated gates that normally provide assurance haven't meaningfully run
Untested rollback on an irreversible change — automation can't assess a rollback nobody has tried
Security-impacting scope — firewall rules, IAM permissions, network segmentation, encryption, security tooling. Needs a security reviewer specifically, not a general board.
High blast radius on a shared or revenue-carrying service in business hours
Novel — first time for this change, or for this team
Cross-team collision risk — the genuine residual value of a board: risk the implementing team can't see from inside its own context
Regulatory requirement for explicit human authorization on this class of change

The compliance objection, answered

“We need a CAB for the auditors” is the usual reason boards survive. It doesn't hold. Compliance requires evidence that changes were authorized, tested and reversible — not that a committee met. For SOC 2 CC8.1 and equivalents, each sampled change needs an approval record, a test result, and a rollback plan; a ticket carrying a mandatory peer review and a rollback note satisfies that. Peer review also satisfies segregation of duties, and satisfies it better, because the reviewer actually understands the change.

The real audit risk is elsewhere: scope. A policy covering code deployments while silently excluding infrastructure, configuration and emergency fixes is the most common finding. Naming the automated gate as the authorizer is legitimate — leaving whole change classes out of the policy is not.

Cross-practice

How change touches everything else.

Change enablement isn't a silo — it's the practice with the most connections to the others. Step through to see each hand-off, in both directions.

Idle

Change → Incident the failed change

A change goes wrong and causes an incident. Change-caused incident rate is the single most important measure of whether change enablement is working — and it only exists if the incident is linked back to the change record, which is easy to miss when an incident is investigated without anyone checking the schedule.

INC-4471.caused_by = CHG-2291
{ change_window, implementer, rollback_available: true,
  detection_lag: "16h after implementation" }

Incident → Change the emergency fix

The diagnosis engine identifies a path to restoration — usually a rollback. That's a change, and it needs authorization even at speed. The emergency change skill exists to make the legitimate fast path genuinely fast, because if it isn't, people push fixes with no record at all.

{ from_incident: "INC-4471", sev: 1,
  action: "rollback CHG-2291", reversible: true,
  authorized_by: "IC + service owner", announced_on_bridge: true }

Change → Diagnosis the schedule as evidence

“What changed recently?” is the highest-value question during live troubleshooting, and the forward schedule of change is what answers it in seconds instead of by asking around. A maintained change schedule is an incident response asset, not just a governance artifact.

query: changes WHERE service IN (checkout, db)
      AND window BETWEEN now-48h AND now
→ CHG-2291 (22:00, prior night) — ranked hypothesis #1

Problem → Change CAPA becomes real work

Corrective and preventative actions from an RCA are not done when they're written — they're done when they ship. Each one becomes a change request, and the linkage is what lets you answer whether problem management actually produces fixes or just documentation.

CAPA[2] "require pool-impact review for migrations"
→ CHG-2310 (process change, low risk)
CAPA[1] "pool-utilization alerting" → CHG-2308

Change → Service desk pre-notification

The desk needs the forward schedule so a spike in contacts can be attributed immediately rather than investigated from scratch — and so agents aren't learning about a planned outage from the users affected by it. This is the cheapest cross-practice win available.

{ window, services_affected, user_visible_effect,
  expected_contact_themes: ["login redirect", "slow reports"],
  kb_article_drafted: true }

Service desk → Change the unreported symptom

Contacts spiking after a change that caused no formal incident still degraded the experience — and the desk saw it when monitoring didn't. That signal belongs in the post-implementation review, where it's usually missing.

{ post_change_contact_spike: "+340% category=login",
  window: "CHG-2291 +2h", incidents_raised: 0 }
→ PIR outcome: "successful with issues", not "successful"

Change → Problem the failure worth investigating

A change that failed for a reason likely to recur becomes a problem record — not to assign blame for the change, but because the reason it wasn't caught is a systemic gap. Testing that didn't cover the case, a dependency nobody could see, a rollback nobody had tried.

{ from_change: "CHG-2291", outcome: "failed",
  systemic_gap: "no pre-deploy pool-impact review existed",
  → problem-record-priority }

Tooling

Where change actually runs.

Change is the practice with the widest tool spread, because it straddles two worlds — the ITSM system of record that auditors sample, and the engineering pipeline where the control actually happens. Step through to see which systems go hot at each stage. Conceptual architecture — not a live integration on this page.

Idle

System of record

ServiceNow Change Jira Service Management BMC Helix · Freshservice

Source & peer review

GitHub · GitLab · Bitbucket CODEOWNERS · branch protection

Pipeline & delivery

Actions · GitLab CI · Jenkins Argo CD · Spinnaker · Harness Terraform · Pulumi · Ansible

Automated gates

OPA / Gatekeeper · Sentinel Snyk · Trivy · Checkov · SonarQube GitGuardian · secret scanning

Progressive delivery

LaunchDarkly · Unleash · Split Argo Rollouts · Flagger · canary analysis

Dependencies

ServiceNow CMDB · Device42 Backstage service catalog

Window & coverage

Change calendar · freeze calendar PagerDuty · Opsgenie

Validation & bake

Prometheus · Grafana · Datadog Synthetic checks · error budgets

Comms

Slack / Teams · Statuspage maintenance

Feeds

DORA analytics — LinearB · Sleuth Incident management Problem management

01

Intake & classification

Reads: the pull request or work item, service catalog entry

Writes: change record in ServiceNow or Jira Service Management

Captures: change type, standard/normal/emergency ratio
02

Risk & impact assessment

Reads: CMDB or Backstage for dependencies and blast radius, CI test evidence, prior change history on the component

Writes: risk level and reasoning onto the change record

Captures: risk distribution, assessed-vs-actual calibration
03

Authorization

Reads: gate results — tests, policy-as-code, dependency and IaC scanning, secrets detection

Writes: approval record — a required review in CODEOWNERS, a pipeline environment approval, or a board decision

Captures: authority-type mix, escalation triggers fired, time in approval
04

Schedule & conflict

Reads: change and freeze calendars, on-call rota for the window

Writes: forward schedule entry; pre-notification to the desk and Statuspage

Captures: schedule adherence, collisions, freeze exceptions
05

Implementation & rollback

Runs in: the pipeline — Actions or Jenkins building, Argo CD or Spinnaker deploying, Terraform applying infrastructure

Exposure controlled by: feature flags and progressive rollout with automated canary analysis and abort

Validated against: Prometheus, Grafana or Datadog through the bake period; error budget checks

Captures: rollback rate, rollback success, actual vs planned duration
06

Emergency change

Reads: the incident record and bridge context

Runs in: the same pipeline with gates accelerated, not skipped

Writes: announcement to the bridge, timestamp into the incident timeline, retrospective change record

Captures: emergency rate, retrospective documentation completion
07

Post-implementation review

Reads: incident records in the window, contact volume from the desk, delivery analytics

Writes: PIR outcome; problem record where the failure will recur; standard change catalog updates

Captures: change success rate, change-caused incident rate, DORA four keys

Notice the split: steps 01, 02, 04 and 07 live in the ITSM system of record, while 03 and 05 — where the actual assurance happens — live in the engineering pipeline. That gap is the integration problem in change management. When the record and the control are in different systems that don't talk, you get a change record that says “approved” with no link to the gates that actually ran.

Key process indicators

What gets measured, and the traps in it.

Change metrics are unusually easy to make look good by making the process worse. A slow, restrictive process shows an excellent success rate because so little gets through it — which is why these have to be read against each other and against delivery speed.

Outcome

Change success rate achieved objective, no rollback, no incident
Change-caused incident rate the headline measure connecting change to incident management
Failed change rate and near misses — the "successful with issues" category
Rollback rate and rollback success rate a rollback that itself failed is its own category
Mean time to detect a change-caused failure long lags mean validation is too shallow

Composition

Standard / normal / emergency ratio rising emergency share is the clearest early warning
Unauthorized change rate found in production with no record
Risk level distribution if most changes self-assess as Low, the assessment isn't discriminating
Standard change catalog growth is the process getting faster or just accumulating ceremony

Speed

Lead time for change request to production
Time in approval usually the larger share, fixed by different means than implementation time
Proportion requiring CAB rising means delegation isn't working
Schedule adherence implemented in the authorized window

Assurance quality

Assessed risk vs. actual outcome the calibration measure — if Low-risk changes fail as often as High, the method is noise
Tested rollback proportion untested rollback is a hypothesis, not a plan
Collisions found after the fact the ones the process missed
Conditions compliance were CAB conditions actually met before implementation
PIR completion rate mandatory for failed and emergency changes at minimum

Read them in pairs, never singly

Change is the practice where a single metric most easily produces the wrong behaviour, because the easiest way to raise the success rate is to let fewer changes through.

Success rate × lead time × change volume — a 99% success rate with a three-week lead time and falling volume is a process strangling delivery, not a safe one. The DORA framing is the useful corrective: speed and stability rise together in healthy organizations, they don't trade off.
Emergency rate × normal-path lead time — people use the emergency path when the normal path is too slow. A rising emergency rate is usually a symptom of approval latency, not of recklessness.
Risk distribution × change-caused incident rate by risk level — if incidents are evenly spread across assessed risk levels, the assessment carries no information and should be redesigned rather than enforced harder.
Rollback rate × change-caused incident rate — low rollback with high change-caused incidents means teams are pushing through failures they should have reversed. Rolling back more is the improvement.
Unauthorized change rate × process satisfaction — undocumented changes are the clearest evidence that the official path is unusable. The fix is upstream in the process, not downstream in enforcement.

Full skill sources

The complete instructions are encrypted.

The rationale for each skill is open above. The full operational detail — the matrices, thresholds, output formats and judgement rules — is AES-256 encrypted and decrypted in your browser only. The ciphertext is all that exists in the page source or the repository.

Recruiters and hiring teams: get in touch and I'll share access.

Hiring for TPM or incident management roles

I'd like to talk about how this kind of work applies to your team.

ahlevin@hotmail.com
linkedin.com/in/alanlevin

Want this running for your team

Interested in these skills — or something like them — supporting how your team actually operates. Let's talk about what that would take.

ahlevin@hotmail.com