Why I am writing about this
Let's be honest, change enablement (previously known as management) is not a fun topic. But it's a must when your software impacts business, users, and ultimately the bottom line of the company.
I've seen three types of change management. The process that flows well. The process so rigorous it feels like the goal is to stop all changes, not assess them. And the process that doesn't exist at all, where a developer pushes new code straight into production, right there on a live call with you, complete freestyle.
Best results come from a streamlined process, where attention to change is proportional to the risk it carries. But what does that look like?
Moving from product to product, and reading a bunch of Reddit threads, I've noticed a pattern. People have good intentions. They want to create standards for this process. But they haven't seen good examples around them, or don't know what good even looks like.
Let's change that today.
A few most important questions answered about change management
What is change enablement (management)?
Change enablement is how a team decides, assesses, and approves a change before it hits production.
What is the goal?
The goal of change enablement is to get more good changes through, safely.
Why do we need change management?
Without a proper process to push changes to production, it's only a matter of time until something disastrous happens. Until a colleague pushes a change on Friday afternoon, leaves for vacation, and creates a big outage for users. And you are the one left to solve it.
And what is a change, exactly?
A change is any change in code, infrastructure, configuration, or UI that may impact the overall application, user experience, or business.
That means changes that don't impact users, like a new report or a DNS change, aren't a change?
Incorrect.
Change is change. Even if it carries lower risk, it's still a change.
There are countless examples I've seen, and you probably have too, where something small, a new feature that shouldn't have touched anything, ended up impacting other components and brought down an app.
You don't want to overkill change management for every single little change. But you also don't want to be dismissive of it. So what's the answer? It's categorizing changes based on their risk.
Types of changes and a risk assessment starting point
Here's the best-practice split for change requests.
→ Standard change: routine, low risk, done before. Pre-approved, no case-by-case review needed.
Standard changes are changes you've done before. There's an established step-by-step process, a known rollback mechanism, and low risk. If it's low risk, but it's the first or second time you're doing this type of change, it's not standard. It's a normal change.
→ Normal change: some risk or unknowns. Needs a look before it ships, a review.
A normal change is one you haven't fully proven out yet. There's some risk, some unknowns, or you simply haven't done this specific change enough times to call it routine. It still moves forward, but it gets a review first, one person checking scope, risk, and rollback plan, not a full committee.
→ Emergency change: something's broken now, needs to move fast.
Emergency doesn't mean no review, it means an abbreviated one. It still gets a quick check, one approver's sign-off, plus a mitigation plan, before it ships. The full, formal review happens after, once things are stable.
To sort a change into one of these, ask:
→ Have we done this exact change before?
→ What breaks if this goes wrong, and how many people notice?
→ Can we roll it back in minutes, or are we stuck with it?
The more "unknown" and "hard to undo" a change is, the more eyes it needs before it ships. Everything else should move fast.
Need support in classifying and assessing your change? Grab my free Notion template, it covers classifying the change, scoring the risk, and the checklist to prep before anything ships.
→ CLICK HERE TO DOWNLOAD
World without change management
Hopefully by this point, you're convinced that having change management is an important, essential part of delivering software in any company.
Before I show you what a good change management process looks like, let's first look at what it looks like without one.
Your team may be working in Agile and doing 100% of releases without any change review whatsoever:
Sprint → Review → Validation by the team → Push directly to production
This may work if:
→ Your product is small
→ Integrations are simple or nonexistent
→ All responsibility sits with a small, experienced team
It stops working when:
→ Your product is integrated with others
→ Your product shares res
ources with other products
→ The team is big
→ Not all team members are trained on best practices
World with good change enablement practices
Here's what a more mature pipeline looks like:
1. Requirements
2. Design
3. Development
4. CI (continuous integration)
5. Test
6. Change assessment, a risk level gets assigned.
→ Standard changes: approved by the team itself
→ Normal changes: reviewed by the change authority, checked against a checklist (rollback plan, blast radius, risk)
→ Emergency changes: fast-tracked. One approver plus a mitigation plan before it ships, full review after, once things are stable
7. Approved or declined. Declined sends it back to development. Approved moves forward.
8. CD (continuous deployment), with a rollback ready to trigger if something goes wrong.
9. Monitor
10. Feedback loop: what Monitor catches feeds back into Requirements, closing the loop instead of leaving it one-way.
The future of change management
This is where it gets interesting for PMs specifically.
Machine learning is starting to score changes automatically, using historical data to flag "this looks like the last 40 changes that caused an incident" before it ships.
That means the risk assessment above might not stay manual for long. Some of that "is this low or high risk" judgment call could get made by a model, not a person, before anyone even looks at it.
Worth watching, especially if your org is investing in this kind of tooling.
It's a case where the AI conversation in product isn't about writing code faster, it's about catching mistakes before they ship.
