Writing a Change Request That Gets Approved

A change request isn't a record of what you're going to do. It's an argument, made to someone with five minutes and no context, who is looking for a reason this can wait until next week.

Aldermoor Health pulled a quarter's worth of change requests and compared the ones approved first time against the ones that bounced.

The rejected ones weren't riskier. Several were near-identical to changes that had sailed through a month earlier — same service, same kind of alteration, same author in two cases.

What separated them was that the approved requests let the reviewer reconstruct the failure. The rejected ones asserted there wouldn't be one. Faced with an assertion they couldn't check, reviewers did the only safe thing available to them and asked a question, which cost a week.

The reviewer has five minutes and one real question

A reviewer opens the request, scans for a minute, reads two sections properly, and decides. They are not going to read your twelve-page document, and treating the request as documentation rather than argument is the root of most rejections.

Their actual question is not is this a good change. It's: if this goes wrong, will I understand why, and will we be able to get back?

Everything follows from that. Each section either helps them answer it or gets in the way:

Section	Removes a reason to defer by	Common failure
Summary	Letting them decide in 30 seconds whether this is their problem	Written in abstractions — "align with current practices"
Motivation	Naming the pressure, so "why now" doesn't need asking	"Improve performance" with no number
Scope	Closing off the adjacent question they were about to ask	No out-of-scope line at all
Risk	Giving them a specific failure to reason about	"Low risk", unearned
Rollback	Showing the way back exists and has been walked	"Revert the deploy"
Verification	Defining what "it worked" means before it matters	"We'll monitor"
Comms	Proving the affected people are known, by name	"We'll notify customers"
Timing	Justifying the window rather than stating it	A date with no reason

The test you can run: take your last rejected request and find the sentence the reviewer's question was about. It's almost always one where you asserted an outcome instead of describing a mechanism.

The section everyone fills in wrong is Risk

"Low risk" appears on nearly every change request ever written, including all of the ones that caused incidents. Reviewers know this. The phrase has been fully devalued — it now reads as the author did not think about this, which is the opposite of the intended effect.

The fix isn't a better rating. It's replacing the rating with the thing the rating was standing in for: a specific failure, and what it would look like from outside.

Three sentences do it:

1. What specifically breaks. Not "the auth service could be affected" — sessions issued before cutover stop validating, so everyone signed in gets logged out.

2. Who sees it, and how fast. All authenticated users, immediately. The mobile app fails silently and retries for up to fifteen minutes before showing an error.

3. How we'd find out. Login success rate on the auth dashboard; it drops within a minute. If it fails the silent way, first signal is support volume, ~20 minutes.

That third sentence is the one reviewers actually want and almost never get. A failure you'd detect in sixty seconds is a different proposition from an identical failure you'd hear about on Thursday, and the second deserves more caution than the first — which is the reverse of how risk usually gets rated, because loud failures feel scarier while writing.

Aldermoor's requests now carry no risk rating at all. They carry those three sentences, and first-pass approval went from just over half to about nine in ten.

The test: delete the words "low", "medium" and "high" from your risk section. If nothing of substance remains, the section was a rating standing in for an analysis.

Rollback is where confidence gets checked

The second section reviewers read properly, and the one where the tense gives everything away.

"We'll revert the deploy" is future-tense about something nobody has done. It's a hypothesis, and reviewers treat it as one. A rollback plan that has been executed — in staging, in a game day, in a previous incident — is a different claim entirely, and saying so is the single cheapest thing you can add to a request.

What makes it credible, in about four lines:

• The trigger. A metric and a threshold, decided now rather than argued about during the incident.

• Who calls it. A name or a role. If that's "whoever's around", there is no rollback plan.

• How long it takes, and how you know — from having done it.

• What doesn't come back. Rows written during the window, messages sent, anything that left the system. This is the line that distinguishes a real plan from a wish, and it's the one that should shape the change rather than merely describe it.

For anything touching data or an external integration, "just roll back" is usually false, and a reviewer who's been burned will hold the request until you've said so plainly. The mechanics — and why the untested plan fails at exactly the wrong moment — are their own subject.

The test: read your rollback section and mark every verb. If they're all future tense and none of them has ever happened, say that explicitly. Reviewers approve honest hypotheses; they stall on hypotheses dressed as plans.

Size the request to the class, not to the habit

Using one template depth for everything is how the artifact becomes resented. It over-burdens routine work and under-prepares the rare thing, and the over-burdening is what teaches people to fill it in without thinking — so the rare thing gets the same reflex.

The change class already decides this, which is most of the reason to have classes at all:

Class	The request is	Because
Standard	A log entry, written after	The analysis happened once, at promotion
Normal, reversible, one team	Summary + risk + rollback. Half a page	The reviewer is a colleague with context
Normal, cross-team or hard to reverse	The full eight sections, plus the dependents list	Someone outside your team holds the information
Emergency	Reconstructed after, honestly	The decision was made under pressure and the record's job is the review

The eight-section version is for the third row. Applying it to the second is where the reputation for bureaucracy comes from.

The test: for your last ten change requests, ask which class each was. If they all got the same template, the classification isn't doing any work and the process is one-size-fits-all in practice regardless of what the policy says.

What a request cannot fix

Some requests are rejected for the right reason, and rewriting them is the wrong response:

• The reviewer knows something you don't. Another team is mid-migration on the thing you're changing. No amount of structure fixes this, and it's precisely the case where review earns its cost.

• The change is genuinely not reversible and that hasn't been faced. The request is being used to get permission rather than to think, and the reviewer can tell.

• It's an architecture decision wearing a change record. Choosing a datastore isn't a change; it wants a decision record and a different conversation.

• Nobody can name who's affected. That's not a documentation gap, it's a finding — the dependency question hasn't been run. The same is true of a comms section that names teams instead of people, which is a RACI problem surfacing late, and of one with no pre-drafted failure message.

Writing it more persuasively in these cases is how you get approval for something that should have been stopped. The request's job is to make the reasoning visible, including when the reasoning doesn't hold.

The test: when a request is queried, ask whether the reviewer wanted information or wanted the change to be different. Only the first is a writing problem.

What to change this week

Take your next change request and delete the risk rating.

Replace it with the three sentences: what specifically breaks, who sees it and how fast, and how you'd find out. The third one usually takes the longest to write, which is the signal that it was worth writing — if you can't say how you'd detect the failure, neither can the reviewer, and neither of you should be comfortable.

Then check the tense in your rollback section. If nothing there has ever been done, say so in six words. It costs you nothing and it's the sentence that earns the benefit of the doubt.

Aldermoor's template is unchanged in structure. The only edit was removing the risk dropdown and replacing it with three free-text prompts. Approval time went from a median of four days to under one, and two changes were stopped last quarter — both by the detection sentence, when the author reached it and realised the honest answer was we wouldn't.