Why Change Management Is an Engineering Problem, Not a Training Problem

"They just need more training" is usually the wrong diagnosis, and it's an easy one to reach for because it puts the problem on the user instead of the system.

I watched this play out directly while migrating a large set of Workflow Rules and Process Builder automations to Flow ahead of Salesforce's deprecation deadline. The technical migration was the smaller part of the job. The harder part was that dozens of teams depended on automations they didn't know existed, a field update here, a notification there, quietly doing work nobody remembered configuring. Break one without warning and you don't get a training request. You get an outage, and a team that now distrusts every future change you make.

The instinct in that situation is to over-communicate: send more emails, hold more meetings, explain the change more times. Sometimes that helps. More often, the real fix is upstream of communication entirely, mapping dependencies before touching anything, staging changes so nothing breaks silently, giving teams a way to flag "we rely on this" before it's gone rather than after. That's not change management in the traditional sense. That's engineering discipline applied to the fact that systems have downstream dependents who weren't in the room when the system was built.

Training assumes the system is right and the people need to catch up to it. Sometimes that's true. But often what looks like resistance to change is actually accurate risk detection, people have learned, correctly, that changes to this system tend to break their work without warning. The fix for that isn't a better slide deck. It's making the system change process itself trustworthy: predictable, reversible, and honest about what it touches. Do that consistently and the "resistance" mostly evaporates on its own, because it was never about the training in the first place.