ronutz

The Roles · Who runs it

Change manager

Written from published sources

The person who decides what may be done to production, and when. The framework states the purpose exactly: maximise the number of successful changes by assessing risk properly, authorising changes to proceed, and managing the schedule. The word in that sentence carrying the most weight is maximise — the practice exists to let changes happen, with the assessment as the means rather than the object.

What the day looks like

  • Assessing what is proposed: blast radius, dependencies, the plan to return, and whether the plan has been tried.
  • Authorising, at whatever level the risk justifies, which for routine work should be automatic.
  • Holding the schedule, so that two safe changes stop being one unsafe evening.
  • Reviewing what happened afterwards, especially the changes that succeeded in ways nobody expected.
  • Adjusting the standard changes list, which is where most of the value is realised.

What it answers for

  • Risk assessed at a depth proportionate to the change.
  • The schedule reflecting what is genuinely happening.
  • Failed changes being reviewed for their cause rather than for their author.

What it is measured on

  • Change success rate, and the impact of the ones that failed.
  • Lead time from request to implementation.
  • The proportion of changes flowing as standard rather than requiring a meeting.

Who it receives from

Engineering and operations
The proposal, and the honesty of its risk assessment.
The business
When the service can be disturbed, and when it certainly cannot.
Incident and problem work
The consequences of previous changes, which is the calibration.

Who it serves

Engineers
A path to production that is predictable and quick for ordinary work.
The business
Change happening at the pace it needs, with the stability it assumes.
Operations
A schedule that keeps unrelated changes out of one another's evening.

Who else has a stake

  • Every user of every service inside the change window.
  • Auditors, for whom authorisation records are evidence.
  • The on-call engineer who will meet whatever goes wrong.

What it takes

  • Technical breadth sufficient to assess risk in systems somebody else built.
  • The judgement to route routine work through automatically, which requires trusting a category rather than a request.
  • Nerve to refuse, and the willingness to explain the refusal in terms of the risk rather than of the process.
  • A blameless instinct in review, since the alternative is accurate proposals becoming optimistic ones.

What the job turns on

Two numbers pull opposite ways: change success rate and lead time. A practice tuned only for success reviews everything, and the queue becomes the reason teams stop proposing improvements; one tuned only for speed accumulates the incidents that produce the next review board. The resolution is categorical rather than case by case — deciding which classes of change are standard and letting those flow — and the framework is unusually candid that in product-focused organisations this may be daily practice and automation rather than a job at all.

The published sources

Where it leads

Roles that lead here

The work itself

The Practice covers how this work is done — triage, escalation, evidence, handover — across the whole corpus.

Read The Practice