Change Enablement: Designing a Process so Good People Want to Use it

Change Management has always had an image problem.

Ask around and you’ll hear it framed as a necessary evil – something you put up with to avoid bigger problems down the line. For many, it’s synonymous with red tape: slow, bureaucratic, and often disconnected from the reality of how work gets done. It’s the department that tells you “no”. The organizational equivalent of a line at the DMV.

My take is that we’ve been doing it wrong, and that Change Enablement could be something people actually want to use. And that to get there, all you need is to solve a design problem.

Boosting past the bottleneck

Let’s start by acknowledging the obvious: people don’t resist change controls because they want to cause chaos. They resist it because they don’t have a choice. The process is often clunky, overly complicated, or lacks any real value to the person making the change.

In some organizations, submitting a change feels like yelling into the void – you never know when (or if) you’ll get a response. And if you do, it might just be a terse “denied” with no context.

So people start finding workarounds. They roll things out quietly. They fix things under the radar. They bypass the system because the system doesn’t work for them.

The real problem isn’t bad behavior, it’s bad design.

When Change Enablement works well, it improves outcomes. It reduces mistakes. It prevents outages. It gives people a clear runway, not a wall. It should make someone more likely to succeed – not just more likely to follow procedure. That’s the bar.

Think like a service designer

This is where the shift in mindset comes in. Change Enablement shouldn’t be seen as a control function – it should be a service. A good one. Something that feels like support, not surveillance.

It’s the difference between walking into a well-designed airport lounge versus a TSA checkpoint. One is built around comfort, speed, and utility. The other is built around suspicion and control. They both exist in the same domain, but one is designed to facilitate efficient security at volume, and the other focuses on comfort and service for the customer.

So how do you design a Change Enablement process that earns trust and drives adoption? You start by thinking like a service designer. That means:

• Understanding the customer journey – Where do colleagues get stuck? What information are they missing? What are they afraid of? What do they need?

• Removing friction – Can this step be automated? Is this form necessary? Does this approval add value or just delay?

• Adding meaningful value – Could you offer impact assessments, risk scoring, templates, or communication plans as part of the process?

• Designing for trust – Are you building a culture where asking about the process or improving it feels safe?

The goal isn’t to make Change Management “fun.” You want to make it useful and valuable, making the benefits obvious and giving the customer power!

Success support instead of risk avoidance

Too often, Change Enablement is designed primarily to avoid failure. But what if we flipped that and made it about increasing success?

A high-performing change process doesn’t just stop bad things from happening – it actively helps people do their best work. That means designing with support in mind, not just oversight. Consider what that might include:

• Risk modeling tools that help change owners assess the likelihood and impact of issues – before they submit anything.

• Automated rollback plan generators that walk teams through creating a solid plan B.

• Collaboration features that connect people with peers or mentors who’ve successfully navigated similar changes.

• Communication tools for telling impacted customers and colleagues what is happening.

• Change rehearsals or test environments where teams can simulate deployments in a safe space.

• Modern ITSM tools that actually facilitate the change journey – integrating documentation, risk assessments, peer reviews, and communication planning into one streamlined experience. The best ones make it easier to do the right thing, not harder.

In other words, your tooling and adjacent services matters. If your ITSM platform is just a digital gatekeeper, it’s part of the problem. But if it’s designed to enable and support people (by providing templates, checklists, context, and clarity) then it becomes a core part of the solution.

Creating a culture of confidence

The goal is to create a culture where people feel confident making changes because they’re backed by a process that’s been designed to support them. 

It’s not compliance for compliance’s sake. Earn buy-in by offering VALUE – not by tightening the rules, but by improving the experience.

Of course, there’s still a place for governance. Documentation, approvals, and risk oversight aren’t going away. But if those are the only things your change enablement process offers, it’s time for a redesign.

Let’s stop designing processes that make people nervous and start designing ones that make them look good.

Practical starting points

So how do you actually start building a change enablement process that people don’t just tolerate but genuinely prefer to use?

Here are a few practical ways to begin reimagining your approach.

Interview your users

So many people want me to tell them to add a feature, remove a step or modify parts of the process, but nobody has these answers for you. A framework might help, but not as much as understanding your context and constraints. 

You can’t design a good experience in a vacuum. Sit down with the people actually using (or avoiding) your change process – engineers, analysts, support staff, implementation leads. Ask them what frustrates them. Where do they get stuck? What feels like busywork? What do they wish the process did for them?

Discuss and explore the upstream and downstream elements related to process. Is there an opportunity to improvise the triggers of change? What effects are we causing because of the way our process is designed?

This should help you bring patterns to the surface. Maybe people feel like change reviews happen too late, when it's already too risky to pivot. Maybe the forms ask irrelevant questions. Or maybe nobody even knows where the process is documented. 

Once you understand their perspectives and needs, you can start designing a process that fits their real-world needs, not just your risk spreadsheet.

Map the journey

Take your current change process and lay it out visually – from the first spark of an idea to implementation, follow-ups, and incidents created. Include every step, handoff, approval, form, and communication channel.

Then ask:

• Where are the delays?

• Where is the extraneous toil?

• Where is information lost or duplicated?

• What steps add value, and which ones just create drag?

This kind of journey or process mapping helps expose pain points and redundant complexity. It also reveals where small tweaks (like automating something or providing better guidance at a key step) can have an outsized impact on the overall experience.

There is massive value to be discovered by inviting stakeholders to co-create the map with you, turning the redesign into a shared effort rather than a top-down mandate.

People appreciate processes they built because they built them. 

Offer opt-in help

Instead of enforcing rigid checkpoints, why not offer support services that people choose to use because they’re helpful?

Think:

• Pre-change impact analysis tools.

• Communication templates.

• Consults with change advisors or SMEs.

• Peer review.

• Checklists.

• Sandbox environments for testing.

When done right, these services are so useful that people naturally want to engage with them. You're not forcing people through a funnel – you’re offering value, and they’re opting in because it helps them succeed and look good doing it.

And yes, you can still require certain governance steps when needed. But when people experience the process as additive instead of punitive, resistance drops dramatically.

Measure experience as well as compliance

Too many change processes define success by how many changes went through the system – or how many didn’t cause outages. But what about how people felt about the process? Did they understand it? Did it help them? Would they use it again?

Start collecting real experience metrics:

• Average time to implement.

• Customer satisfaction scores.

• Customer effort scores.

• Drop-off points (where people abandon the process).

• Post-change feedback surveys.

• Support requests related to the change process itself.

These data points give you a clearer picture of what’s working and what needs adjustment. Bonus: They help you make the case for improvements using something more compelling than gut instinct.

Celebrate good changes

People notice what you reward. So reward good change behavior.

Highlight successful implementations in internal newsletters or Slack channels. Give shoutouts to teams that used the process effectively. Tell the story of a change that went smoothly or saved our reputation because of solid planning and smart use of enablement resources.

Not only does this make the process visible and positive, it also builds a model for others to follow. You’re not just managing risk; you’re creating a culture where thoughtful change is recognized and celebrated.

And when that happens, people stop seeing change enablement as a hurdle and start seeing it as a launchpad.

We can do change better

We need to stop treating Change Enablement like airport security – something everyone grumbles about but accepts as the cost of doing business. Instead, let’s turn it into something closer to concierge service: smart, supportive, and designed around the person doing the work.

When people want to use your process, you don’t have to force compliance; you’ve earned it.