Writing a Change Request That Gets Approved

Contributor
May 21
6 min read

The difference between a change request that sails through approval and one that bounces back three times is not the technical merit of the change. It's how the request is written. Reviewers are time-constrained, often less close to the work than the author, and looking for reasons to delay. A well-structured request removes those reasons. A badly structured one creates new ones.

This guide is a practical structure for change requests that get through review on the first pass, with the reasoning behind each section.

What the Reviewer Actually Reads

Before writing, understand the reader.

A typical reviewer spends 5-15 minutes on a change request. They open it, scan the structure, read the parts they care about most, and decide whether to approve, defer, or ask questions. They are not going to read a 12-page document end-to-end. They will read whatever you put in the first 30 seconds and use that to decide how much more attention this deserves.

Therefore: put the most important information first, in a form the reviewer can scan. The detail belongs in the second half, for the reviewer who wants to dig in.

The Required Sections

A working change request has eight sections, in this order. Each has a job.

1. Summary

One paragraph, three to five sentences. What is changing, why, when, and what the customer-visible effect is.

Bad: "This change involves updating various components of the authentication system to better align with current security practices and improve the overall reliability of user session management."

Good: "We're replacing the session token store with Redis. Today's database-backed sessions cause 200ms latency spikes during traffic peaks. Cutover is Tuesday 2pm. Users won't notice unless they're mid-session at cutover, in which case they'll sign in again."

The summary should let the reviewer decide whether the change is in their wheelhouse and roughly what the risk profile is. If they have to read further to understand what's happening, the summary failed.

2. Motivation

Why this change, why now. Reviewers approve changes faster when they understand the driving pressure.

Two or three sentences. Reference the specific problem: an incident, a customer complaint, a compliance deadline, a measured metric. Avoid abstract motivations like "improve performance" — name the specific performance number.

If the change is part of a larger initiative, link to the broader plan rather than re-explaining it.

3. Scope

What's in scope, and what's explicitly out of scope.

The "out of scope" line prevents reviewers from asking about adjacent work. "We're not also updating the auth UI in this change — that's tracked separately as ticket X." This single sentence saves a round of back-and-forth.

4. Risk Assessment

The most important section after the summary. Three subsections:

Blast radius. Who or what is affected if this goes wrong? "All authenticated users for the duration of the failed deploy." Be specific.
Likelihood. What could realistically fail? List two or three concrete scenarios.
Severity. If those scenarios happen, what's the impact? Customer-facing outage, data loss, internal-only inconvenience.

Don't write "low risk" without justification. Reviewers see "low risk" on every request and have stopped believing it. Earn the rating with specifics.

5. Rollback Plan

How do we get back to the previous state.

This is the section that most change requests skip or write as "revert the deploy." That's not enough. A real rollback plan answers:

What's the trigger for rolling back? (specific symptoms or metrics)
Who has authority to call it? (a name or role)
What are the steps, in order?
How long does rollback take?
What state is recoverable? What isn't?

Rollback for a stateless service is usually trivial. Rollback for anything involving data, migrations, or external integrations is usually not. If you write "we'll just roll back" for a database migration, your reviewer will (correctly) reject the request until you've thought it through.

6. Verification Plan

How will we know the change worked.

Specific, observable evidence. Metrics on a dashboard. Error rates that should remain flat. Customer-facing flows we'll exercise. Not "we'll monitor for issues" — name the specific things you'll watch and what good looks like.

The verification plan also defines the success window. "We'll watch for 30 minutes after deploy, and the change is considered stable if X, Y, and Z metrics are within baseline."

7. Communication Plan

Who needs to know, when, and via what channel. Three audiences:

Internal teams affected: typically Slack channels and direct messages
Operations or on-call: explicit, often a calendar entry or pager note
Customers (if affected): status page, in-app banner, email — depends on the audience

If customers are affected and you don't have a draft of the customer message in the change request, the reviewer will assume you haven't thought it through. Include the actual text, not just "we'll send a notification."

8. Timing

When the change happens, and why that window.

Some windows are obvious (an emergency change ships immediately, a holiday change ships outside the freeze). Some need justification. "Tuesday 2pm" sounds arbitrary; "Tuesday 2pm because that's lowest traffic for our customer base and the on-call team's healthy" is justified.

If timing matters for the change (e.g., must coordinate with a marketing launch), name the constraint explicitly.

What Reviewers Look For

Reviewers approve requests faster when they see:

Specificity. Names, numbers, concrete scenarios. Not abstractions.
Self-awareness. The author acknowledges what could go wrong rather than asserting it won't.
Reversibility. A rollback plan that actually works.
Skin in the game. The author will be on call during the change, not handing it off.

Reviewers slow down when they see:

Confidence without evidence. "This is safe" without explanation.
Implementation detail without context. Long technical descriptions without the "why."
New patterns without precedent. A first-of-its-kind change without acknowledging that's what it is.
Pre-approval bias. Wording that suggests the change is happening regardless of review.

Sizing the Request

Match the level of detail to the level of risk.

For a low-risk routine change: the full template is overkill. A two-paragraph version is fine.

For a high-risk or first-time change: the full template, plus appendices with details (test plans, rollback scripts, customer messages).

For an emergency change: a stripped-down version with the summary, what you did, why, and what verification looked like. Filed after the fact for the record.

The mistake is using the same template depth for everything. It either over-burdens routine work or under-prepares major work.

How to Pre-Empt Common Questions

A request that gets approved on the first pass usually answers questions the reviewer would have asked. Before submitting, walk through the request as the reviewer:

What would I want to know about this change that's not in here?
What would I worry about?
What objection might someone in another team raise?

For each one, decide whether to add a sentence to the request or have an answer ready. The few minutes you spend doing this pre-review save days of back-and-forth.

What Not to Include

A history of the system. Background is fine; full history is noise.
Justifications for choices that aren't being changed. "We chose Postgres for X reasons" — irrelevant if Postgres isn't being touched.
Disclaimers and hedges. "This might not work perfectly" — say what could go wrong specifically, not abstractly.
References to internal politics. Even if a decision is politically driven, the change request isn't the venue.

The Two-Minute Test

Before submitting, set a timer for two minutes and read your own request. Can you summarize what's happening, what could go wrong, and how you'd recover, using only what's in the request, in two minutes?

If not, the structure is broken. Rewrite the summary and risk sections until you can.

A Minimal Template

## Summary
[3-5 sentences: what, why, when, customer-visible effect]

## Motivation
[2-3 sentences: specific driving problem]

## Scope
In scope: [bullet list]
Out of scope: [bullet list]

## Risk Assessment
Blast radius: [who/what is affected if this fails]
Likelihood: [2-3 concrete failure scenarios]
Severity: [impact if those happen]

## Rollback Plan
Trigger: [specific symptoms]
Authority: [who calls it]
Steps: [ordered list]
Recovery time: [estimate]

## Verification Plan
Signals: [specific metrics/flows]
Window: [how long we watch]
Success criteria: [what good looks like]

## Communication Plan
Internal: [who, when, channel]
Operations: [who, when, channel]
Customer (if applicable): [audience, channel, draft text]

## Timing
When: [date/time]
Why this window: [justification]

Key Takeaway

A change request that gets approved is one that makes the reviewer's job easy. Lead with a summary that lets them scan and decide. Be specific about risk, rollback, and verification — don't assert safety, demonstrate it. Match the depth of the request to the risk of the change. Pre-empt the questions a reviewer would ask. The few extra minutes spent on structure save days of revision and approval cycles. Reviewers are not your adversary; they're your safety net. Help them help you.

ShiftQuality