Our job as developers is to change software. And that means that when we decide what to do, we’re not designing new code, we’re designing change.
Our software (if it is useful) does not work in isolation. It does not poof transition to a new state and take the rest of the world with it.
If our software is used by people, they need training (often in the form of careful UI design). They need support. hint: your support team is crucial, because they talk to people. They can help with change.
If our software is a service called by other software, then that software needs to change to, if it’s going to use anything new that we implemented. hint: that software is changed by people. You need to talk to the people.
If our software is a library imported by other software, then changing it does nothing at all by itself. People need to upgrade it.
Designing change means thinking about observability (how will I know it worked? how will I know it didn’t hurt anything else?). It means progressive delivery. It often means backwards compatibility, gradual data migrations, and feature flags.
Our job is not to change code, it is to change systems. Systems that we are part of, and that are code is part of (symmathesy).
If we look at our work this way, then “Change Management” sounds ridiculous. Wait, there’s a committee to tell me when I’m allowed to do my job? Like, they might as well call it “Work Management.”
It is my team’s job to understand enough of the system context to guess at the implications of a change and check for unintended consequences. We don’t all have that, yet. We can add visibility to the software and infrastructure, so that we can react to unintended consequences, and lead the other parts of the system forward toward the change we want.