Change Management for Engineering Teams: A Practical Guide
Updated: Aug 20
Every engineering team eventually acquires a change process, usually after an incident, usually copied from somewhere else. The useful question isn't how much process to have. It's what each step is actually for.
Aldermoor Health's change process had eleven steps, a form with nineteen fields, and an approval rate of one hundred per cent across fourteen months.
That statistic is the whole problem in one number. A gate that never stops anything isn't a gate — it's a toll. And people who pay a toll for nothing eventually find a road around it, which at Aldermoor meant a category of work quietly reclassified as "config" so it didn't need a change record.
Then a token-expiry setting was changed on the auth service and the mobile app stopped working for four hours. The change had a record. The record had been approved. The approval had asked nine questions, and not one of them was who else depends on this?
The purpose is routing information, not granting permission
Here is the distinction that makes the rest of it decidable:
A change process exists so that someone who could have said "that will break X" gets the chance to say it, before it breaks X.
Not to create an audit trail — that's a side effect. Not to make someone accountable — the engineer was already accountable. Not to slow things down — that's a cost, not a function.
Read that way, each step in a process has to answer one question: what information does this move, and to whom? A step that moves no information to nobody is pure cost, regardless of how sensible it looks on a flowchart.
Aldermoor's nineteen-field form, audited against that question, had four fields that routed something and fifteen that were recorded and never read. The approval step routed nothing at all: the approver had no information the engineer lacked, and no basis on which to say no.
The test you can run: take your change form field by field and ask who reads each one and what they do differently as a result. Any field with no reader is costing you compliance and buying nothing.
Three things get managed, and only one is the change itself
Conflating these is what produces eleven-step processes, because each deserves different handling and a single pipeline tries to do all three.
What's being managed | The question it answers | Who needs to act |
The technical change | Will this work, and can we undo it? | The engineer, and a reviewer who knows the system |
The coordination | Who else is affected, and do they know? | Whoever depends on it — often outside your team |
The human transition | Will people actually use it? | The people whose work changes |
Most engineering change processes handle row one thoroughly, row two by accident, and row three not at all.
That distribution is exactly inverted from where the failures come from. Row one is largely handled by code review and testing before the change process ever sees it. Row two is where Aldermoor's four-hour outage lived. Row three is where a clean go-live becomes eleven people still on paper — which is an adoption problem that no change record will surface.
The test: for your last three changes, say which of the three rows the process actually helped with. If the answer is row one every time, you have a technical review with paperwork attached.
The minimum that earns its keep
Four things. Anything beyond these needs to justify itself against the routing question.
A record that exists before the change — what's changing, why, and how it gets undone. The value isn't the record; it's that writing it forces the rollback question early, when the answer can still change the plan. That's what a change request is for.
A classification that decides how much process applies. Most changes should skip most of it. This is the single highest-leverage piece and it's covered properly in standard, normal and emergency.
A dependency check that runs backwards — not what this change touches, but who touches the thing being changed. Aldermoor's outage was one query away. That's impact analysis.
A notification path to whoever is affected — which is a list of people, not a channel post. If nobody can name who should be told, that's the finding.
Notice what isn't on the list: an approval. Approval is not a fifth item, it's a property of item two — some classes need one, most don't. Nor is a release on the list: bundling changes together is a different job with a different object.
The test: count your process steps. For any beyond four, name the failure it has actually prevented in the last year. Most can't be named, and those are the steps people route around.
The approval question, answered honestly
Approval is where change processes go wrong, and the reason is that "approve" gets used for two completely different acts.
Ratifying — a senior person signs to accept responsibility. This routes no information. It moves blame, which feels like risk management and isn't. A 100% approval rate is the signature.
Reviewing — someone with knowledge the engineer lacks looks and can genuinely say no. This routes real information, and it should sometimes produce a no.
Only the second is worth anyone's time, and it has a precondition that's easy to check: the reviewer must know something the engineer doesn't. Usually that's cross-team context — what else is changing this week, what a downstream consumer is mid-migration on, what broke last time something similar shipped.
Which also tells you when an approval step is pointless: when the approver's only source of information is the change record itself. They're reading what the engineer wrote and agreeing with it. That's not a review, and the CAB is where this failure gets industrialised.
The test: ask your approver what they'd need to see to say no. If they can't describe it, or have never done it, the step is ratification.
Where a heavier process is genuinely right
The argument above is not "less process is better". It's that process should be proportional to what being wrong costs. Some situations move that dial up, legitimately:
The change is hard to reverse. A data migration that drops a column, a pricing change that has already billed. Reversibility, not size, is the variable that matters most.
The blast radius crosses teams who don't know it's coming. Aldermoor's auth change was three lines and took down a mobile app.
There's a regulatory requirement to demonstrate control. Then the audit trail is a genuine deliverable rather than a side effect — but keep it as a record of the routing, not as extra steps.
The team is new to the system. Process substitutes for context you haven't built yet, and should shrink as the context grows.
The thing that should not move the dial: the seniority of whoever requested the change, or how visible the project is. Both are common and neither predicts breakage.
The test: for your heaviest process step, name which of the four reasons above justifies it. If none does, it's there because of an incident whose lesson has already been learned by other means.
What to change this week
Don't redesign the process. Audit one form.
Take your change record, go field by field, and for each one name the person who reads it and what they do differently. Delete the fields with no reader — and expect that to be most of them.
Then add the one Aldermoor was missing: who depends on the thing you're changing, and have they been told? Not "who's affected", which people answer from memory and get wrong, but a query against what actually calls it.
Aldermoor's process is now four steps and a six-field form. The approval rate is no longer 100% — three changes were stopped last quarter, all three by the dependency question, all three by someone outside the requesting team.
