A developer prepares a small production change.
The new version:
- fixes a validation defect
- passes automated tests
- uses the existing deployment pattern
- changes no infrastructure
- requires no database migration
- can be rolled back automatically
The organisation responds by arranging a weekly change meeting.
The developer explains the change to several people who do not own the service.
A spreadsheet records:
Change risk:
low
Implementation:
automated deployment
Rollback:
deploy previous artefact
Approval:
pending Thursday meeting
The change waits four days.
On Thursday, somebody reads its title aloud.
Nobody identifies a new risk.
The change is approved.
The automation then performs the real work.
This process has created a record.
It has not obviously made the change safer.
At the opposite extreme, a team may deploy every change immediately because:
we practise continuous delivery
The release includes a destructive schema migration, a new public endpoint and an untested identity-policy change.
The deployment is fast.
The recovery meeting is not.
The useful design sits between these two failures.
Change management should make routine changes boring, repeatable and automated while creating deliberate controls around changes whose consequences require judgement.
I use “change management” as the familiar label.
The capability I want is closer to change enablement: helping useful changes succeed through proportionate controls.
The aim is not to slow change.
It is to increase the proportion of changes that produce their intended result without causing avoidable harm.
Change enablement is evidence-based risk control
A change is any addition, modification or removal that may affect a service.
That includes:
- application releases
- infrastructure changes
- policy updates
- database migrations
- certificate rotation
- configuration changes
- platform upgrades
- emergency repairs
The change process should answer:
What is changing?
Which service may be affected?
What could fail?
How far could the impact spread?
Which evidence supports proceeding?
How will the result be observed?
How can useful service be restored?
These are engineering questions.
They do not inherently require a meeting.
A pull request or release workflow may already contain:
- the proposed change
- test results
- infrastructure plan
- policy decisions
- affected services
- rollout strategy
- recovery assumptions
The delivery system can use that evidence to determine which control path applies.
CHANGE FACTS
│
▼
CLASSIFICATION
│
├── standard ──► pre-authorised path
└── assessed ──► contextual decision
The requester supplies the facts.
The control system decides whether those facts satisfy the standard-change contract.
A field such as:
riskProfile: standard
should not allow the requester to select the easiest path.
A stronger request declares intent:
migration: none
exposureChange: none
authorityChange: none
strategy: canary
The platform can then report:
Classification:
standard
Reason:
approved application-release path
no data migration
no authority expansion
bounded canary rollout
The process becomes proportionate to risk rather than identical for every change.
Change class and operating mode are different
Two separate questions matter.
CHANGE CLASS
Does this change satisfy
a known, bounded and
pre-authorised path?
OPERATING MODE
Is the change proceeding
normally or during an urgent incident?
The change class may be:
STANDARD
known path
settled controls
machine-verifiable eligibility
ASSESSED
new, exceptional,
irreversible or context-dependent
The operating mode may be:
PLANNED
ordinary delivery conditions
EMERGENCY
urgent containment
or restoration
An emergency rollback may be a familiar standard change executed under incident authority.
An emergency data repair may be assessed because it is unusual, destructive or difficult to reverse.
Urgency changes authority, timing and evidence collection.
It does not make the underlying risk disappear.
CHANGE INTENT
│
▼
CHANGE CLASS
┌───────────┴───────────┐
│ │
▼ ▼
STANDARD ASSESSED
│ │
└───────────┬───────────┘
▼
OPERATING MODE
┌───────────┴───────────┐
│ │
▼ ▼
PLANNED EMERGENCY
│ │
└───────────┬───────────┘
▼
CONTROLLED DELIVERY
Standard paths are versioned products
A standard change is repeatable, understood and pre-authorised.
Examples may include:
- deploying a service through an approved pipeline
- rotating a certificate through tested automation
- scaling within agreed limits
- applying a routine operating-system patch
- provisioning a development database through the platform
The important property is not that the change is small.
It is that the organisation understands its risk and has a reliable way to perform it.
A standard deployment path might include:
reviewed source
│
▼
automated tests
│
▼
policy validation
│
▼
immutable artefact
│
▼
progressive rollout
│
▼
health verification
│
▼
automatic evidence
The path has already been reviewed as a system.
Individual changes using it do not need to reopen every design decision.
Pre-authorisation does not mean no control.
It means the controls have been embedded in the path.
Guardrails enforce settled conditions
Routine changes can move quickly when guardrails enforce rules such as:
- production artefacts come from an approved registry
- workloads do not use prohibited privileges
- protected storage remains encrypted
- infrastructure stays inside approved regions
- deployments declare resource limits
- destructive resources use deletion protection
The guardrail should explain:
- which condition failed
- why it exists
- how to correct the change
- whether an exception path exists
Standard status must be renewable
A standard path should not remain pre-authorised forever merely because it once worked.
Each standard-change definition should have:
- a named owner
- eligibility criteria
- a versioned procedure
- required evidence
- known failure boundaries
- a review date
- conditions that suspend pre-authorisation
The path may be suspended when:
- its change-failure rate rises
- the underlying platform changes materially
- rollback or recovery evidence becomes stale
- a new dependency is introduced
- an incident reveals an unmodelled failure mode
Pre-authorisation should be renewable evidence, not a permanent badge.
Assessed changes need deliberate decisions
Some changes require more than static validation.
Examples include:
- first public exposure
- destructive database migration
- production identity-policy redesign
- deletion of recovery material
- provider or regional migration
- rollout while the service is already unhealthy
These changes cross meaningful boundaries.
A gate can require evidence and context before progress continues.
CHANGE READY
│
▼
RISK GATE
│
├── proceed
├── revise
└── postpone
The gate may be automated.
A canary controller can pause until error rate and latency remain healthy.
An error-budget policy can postpone a non-essential release.
A recovery check can block a destructive migration when restore evidence is stale.
Human judgement is useful when the decision depends on context the system cannot evaluate reliably.
The distinction is not automation versus people.
It is routine enforcement versus contextual decision.
Evidence and authority belong in the workflow
Modern delivery systems can produce stronger records than manual forms.
A change record might contain:
service: catalog-service
environment: production
revision: 9c84f2a
artefact: sha256:example
initiated_by: mariam@example.net
source_approved_by:
- reviewer@example.net
authorised_by: standard-release-policy-v3
executed_by: deployment-workflow
tests: passed
policy: passed
strategy: canary
started_at: 2025-12-28T10:14:00Z
deployment_completed_at: 2025-12-28T10:22:00Z
verification_completed_at: 2025-12-28T10:52:00Z
result: successful
This separates:
INITIATOR
who requested the change
REVIEWERS
who approved the source
AUTHORITY
which policy or person
allowed production delivery
EXECUTOR
which system performed it
Automation removes transcription work.
It should not remove accountability.
The evidence should be:
- searchable
- attributable
- linked to immutable artefacts
- retained according to policy
- resistant to casual alteration
- connected to the resulting production state
Authority should sit near relevant knowledge
The people closest to a service often understand:
- implementation
- failure modes
- recovery path
- current health
- customer consequence
Authority should therefore sit near the relevant knowledge and accountability.
Sensitive changes may still require an independent risk owner or second operator.
Examples include:
- expanding administrator access
- deleting protected backups
- changing audit controls
- altering financial limits
- performing irreversible migrations
The goal is not self-approval without challenge.
It is to place decisions where expertise and responsibility meet.
A person should not approve a change merely because their calendar invitation grants ceremonial jurisdiction over it.
Control the change until the outcome is known
Approval is not the end of change control.
Production evidence should determine whether delivery continues and whether the change is actually complete.
Progressive delivery turns change into observation
A rollout may expose a new version gradually:
NEW VERSION
│
▼
5% OF TRAFFIC
│
▼
HEALTH GATE
│
▼
25%
│
▼
HEALTH GATE
│
▼
100%
The system can evaluate:
- error rate
- latency
- saturation
- SLO burn rate
- business outcomes
- dependency health
The evidence must match the expected failure model.
A security-policy change may need access tests.
A data migration may need integrity checks.
An asynchronous consumer may need backlog and duplicate-event evidence.
The change remains controlled after the approval point.
That is stronger than approving the full rollout and assuming the future will behave politely.
Concurrent changes can invalidate evidence
Two changes may be safe separately and risky together.
service A changes an event schema
while
service B deploys an older consumer
or:
network policy changes
while
database endpoints are replaced
Concurrent changes can:
- invalidate canary comparisons
- obscure causation
- combine incompatible contracts
- compete for capacity
- weaken recovery confidence
The control system should know when to:
- serialise changes
- enforce dependency ordering
- prevent overlapping high-risk work
- record active concurrent changes
- include those changes in the evidence
A useful question is:
Which other changes could alter
the evidence or recovery path
for this one?
Completion means a verified service outcome
A workflow finishing does not necessarily mean the change succeeded.
deployment completed:
10:22
verification window ended:
10:52
business outcome:
healthy
change result:
successful
Completion criteria should reflect the promised service outcome.
This matters for:
- low-traffic routes
- latent data corruption
- delayed side effects
- asynchronous consumers
- cost regressions
- security-policy changes
The delivery workflow produces the change record.
The verification window determines the result.
Rollback is not always recovery
A rollback button does not guarantee that useful service can return safely.
Rollback may be difficult when the change includes:
- irreversible data migration
- deleted state
- changed event schemas
- external side effects
- incompatible configuration
- security-key rotation
For a schema change, a safer sequence may be:
- add backward-compatible schema
- deploy application support
- migrate data gradually
- verify usage
- remove old schema later
This turns one risky change into several bounded changes.
APPLICATION CHANGE
previous artefact may restore service
DATA CHANGE
may require backup, repair
or forward migration
A field labelled rollback plan should not be satisfied by typing:
revert if necessary
The recovery plan should match the actual failure mode.
Emergency operation is a designed mode
During an incident, the ordinary path may be too slow or unavailable.
A team may need to:
- roll back immediately
- disable a feature
- rotate a compromised credential
- block traffic
- change capacity
- restore data
- apply a security fix
Emergency mode should prioritise containment and restoration.
It should still preserve:
- explicit incident authority
- protected access
- immediate evidence
- verification of restoration
- mandatory follow-up
A lightweight record may capture:
Incident:
INC-2025-042
Change:
disable recommendation feature
Class:
standard rollback
Mode:
emergency
Authority:
incident commander
Result:
checkout recovered
Emergency change is not ordinary change performed with fewer witnesses.
It is a defined operating mode with different authority and timing.
Reconcile the result with desired state
Emergency intervention can create drift.
After the incident, the organisation should confirm:
- what changed
- whether it should remain
- whether Git or infrastructure code reflects reality
- whether temporary access was revoked
- whether the emergency path should become automation
EMERGENCY REPAIR
│
▼
RESTORE SERVICE
│
▼
RECONCILE DESIRED STATE
Recovery is incomplete while production depends on undocumented emergency state.
The process should learn
Repeated approval is a signal.
Suppose a review board repeatedly approves:
internal service
standard runtime
private exposure
approved database profile
standard telemetry
The organisation has discovered a pattern.
That pattern should become:
- a platform template
- a standard change
- an automated policy
- a documented golden path
REPEATED HUMAN DECISION
│
▼
SETTLED PATTERN
│
▼
AUTOMATED CHANGE PATH
The reverse is also true.
A standard path that repeatedly causes incidents should lose pre-authorisation until its assumptions are repaired.
Human review is valuable when a decision is new.
It becomes wasteful when the answer is known and the evidence is machine-verifiable.
The change process should learn from both its queue and its failures.
Otherwise yesterday’s judgement becomes tomorrow’s permanent administrative sediment.
Measure outcomes by path
Useful measures include:
- deployment frequency
- lead time
- queue time
- active review time
- change-related incidents
- recovery time
- rollback or repair rate
- standard-path suspension
- emergency-change frequency
The measures should be segmented by:
- standard or assessed class
- planned or emergency mode
- application, infrastructure or policy change
- service criticality
A high success rate for standard application releases can hide poor outcomes for assessed infrastructure changes.
Four days waiting for Thursday is different from twenty minutes of useful review.
The aim is not to maximise change.
It is to improve the flow of valuable, successful change.
A bfstore change path
Suppose a team releases a new version of review-service.
The request declares facts:
apiVersion: platform.bfstore.dev/v1alpha1
kind: Release
metadata:
name: review-service-2025-12-28
spec:
service: review-service
environment: production
artefact: sha256:example
migration: none
exposureChange: none
authorityChange: none
strategy: canary
The platform derives:
Class:
standard
Mode:
planned
Reason:
approved application-release-v3 path
no data migration
no public exposure change
no authority expansion
It verifies:
- immutable artefact
- source review
- automated tests
- policy compliance
- service ownership
- telemetry availability
- recovery artefact
- no conflicting high-risk change
The rollout reports:
State:
progressing
Traffic:
25%
Error rate:
healthy
Business outcome:
healthy
Concurrent changes:
none
Next gate:
automatic evaluation in 5 minutes
After full rollout, the platform continues observation.
Deployment:
completed
Verification window:
completed
Result:
successful
Record:
generated automatically
If the same release included a destructive migration, the platform would classify it as assessed and require recovery evidence and named authority.
If the release occurred during an incident, its operating mode would become emergency without changing the underlying class.
CHANGE FACTS
│
▼
DERIVED CLASS
│
▼
PLANNED OR EMERGENCY MODE
│
▼
AUTHORITY AND CONTROLS
│
▼
PROGRESSIVE DELIVERY
│
▼
VERIFIED OUTCOME
│
▼
EVIDENCE AND LEARNING
The developer does not file a separate change record.
The delivery workflow produces it.
Questions I now ask
Outcome
What outcome should
the change produce?
Impact
What can fail,
and how far can it spread?
Standard
Does it satisfy a versioned
standard path?
Authority
Which evidence and authority
are required?
Concurrency
Which other changes could
affect this one?
Observation
How will production evidence
control the rollout?
Recovery
Which recovery path matches
the actual failure mode?
Learning
What result should change
the process next time?
These questions are more useful than asking whether every box on a generic change form contains text.
The mental model I am keeping
My earlier model was:
CHANGE MANAGEMENT
submit request
wait for approval
implement change
close record
The stronger model is:
CHANGE FACTS
│
▼
DERIVED CLASS
┌──────────┴──────────┐
│ │
▼ ▼
STANDARD ASSESSED
│ │
└──────────┬──────────┘
▼
OPERATING MODE
┌──────────┴──────────┐
│ │
▼ ▼
PLANNED EMERGENCY
│ │
└──────────┬──────────┘
▼
AUTHORITY AND GUARDRAILS
│
▼
CONTROLLED DELIVERY
│
▼
OBSERVATION AND VERIFICATION
│
┌─────────────┴─────────────┐
│ │
▼ ▼
SUCCESS RECOVERY
│ │
└─────────────┬─────────────┘
▼
LEARN AND IMPROVE
Change management does not need to be dramatic.
In a mature delivery system, most changes should be pleasantly uneventful.
They should pass through known paths, produce useful evidence, reveal their status and stop automatically when reality disagrees with the plan.
Human attention should be reserved for:
- uncertainty
- unusual consequence
- conflicting evidence
- irreversible action
- emergency restoration
The best change process does not make every change look important. It makes important changes receive attention and ordinary changes become boring.
Boring change is not careless change.
It is change whose controls are reliable enough that the organisation no longer needs to reconstruct them manually each time.
The meeting disappears.
The evidence remains.
The service gets better.
And the spreadsheet, after years of brave service, is finally permitted to rest.