The Best Change Management Habit I Ever Learned Came From a Regulator, Not a Consultant

If you spend long enough inside a regulated industry, you stop seeing the compliance requirements as a burden and start seeing them as a forcing function. Not always — some of them are genuinely just bureaucracy. But some of them encode hard-won wisdom about what actually has to happen for a change to stick, and that wisdom doesn't stop being true outside the regulatory context.

The habit I'm talking about came from years of working inside financial services under the oversight of regulators like OSFI — and specifically from the discipline those frameworks impose on how change gets documented, validated, and handed over. Not the paperwork for its own sake. The underlying logic of why the paperwork exists.

What the regulator actually taught me

The core insight is simple but not obvious until you've watched enough changes fail: a change isn't complete when it's launched. It's complete when it can be demonstrated to work without the people who built it.

Regulators in financial services don't just want to know that you implemented a new system or process. They want to know that you can demonstrate the control is functioning as intended, that someone accountable can explain it clearly, and that it would survive the departure of the person who built it. You can't just point at a go-live date and call it done. You have to show the evidence of ongoing operation.

Most organizations outside regulated industries never think about change this way. The go-live date is the finish line. Once the system is up and the training is done and the announcement has gone out, the project is closed and the team moves on to the next thing. Whether the change is actually working — whether the new behavior has replaced the old one, whether the system is being used correctly, whether the intended outcome is materializing — that's someone else's problem, or nobody's problem, because the change team already disbanded.

The regulated version forces you to keep asking the question. And the more I applied that discipline outside the regulatory context, the more often I caught changes that had technically launched but hadn't actually landed.

What this looks like in practice

The habit I took from that environment is straightforward: before a change is considered complete, I define what evidence would demonstrate it's working — not just that it launched, but that it's running the way it was designed to.

For a technology implementation, that might mean active daily usage rates at or above target three months after go-live, or specific workflow steps being completed in the system rather than worked around. For a process change, it might mean a measurable reduction in the errors or delays the change was designed to address. For a team structure change, it might mean decision-making velocity — how long it takes a decision to move through the new structure versus the old one.

The specifics matter less than the discipline of defining them. When a team knows upfront what "it's working" looks like, the post-launch period stops feeling like a wind-down and starts feeling like a validation. People are watching for something specific, not just waiting for the initial friction to subside.

The organizations that skip this pay for it later

I've seen this pattern enough times to be confident in it: organizations that close the change before validating it are almost always the ones who end up reopening it six months later.

Not because the change was wrong. Because the change launched but didn't land — and without anyone watching for the evidence that it had landed, nobody caught the gap until a problem was visible enough to be undeniable. By that point, re-establishing the intended behavior is significantly harder than it would have been to validate it properly in the first weeks after go-live.

The cost of a 60-day post-launch validation period is small. The cost of a re-implementation is not.

What nimble organizations can steal from this

You don't need a regulatory framework to apply this discipline. You need a project close-out conversation that includes a defined validation period and someone accountable for what happens during it.

Before any change goes live, ask: what would we need to see in 60 days to know this is working? Who's responsible for watching for it? What do we do if it's not?

Those three questions are the distilled version of what regulators in financial services have been building into change frameworks for decades. They're not complicated. They're just not habitual in most organizations, because most organizations have trained themselves to treat the go-live date as the endpoint.

It isn't. And the regulator figured that out before most of us did.

Peter Dameski is a Change Management and L&D strategist based in Ontario, with nearly two decades of experience leading complex organizational change across financial services, logistics, and technology. He works with growing businesses in an advisory and fractional capacity through The Learning Plan.

Connect with Peter on LinkedIn or reach out through The Learning Plan if this is the kind of work your organization is navigating.