Feast or Famine in Change Management

This is the second of two related posts; the other one is here.

In theory I am all for change management; in IT change is inevitable. In fact, to keep things the same you often have to change them constantly. In a field with so much flux built in, managing the change is essential.

In practice I see two problems with how change management is implemented. In accordance with common practice I will keep my rants to one issue per post.

This post is about the difficulty of avoiding ruts in Change Management. One rut is to say "every change goes through maximum change management" and the other rut is to say "change management is so painful that we will create an 'emergency change' or 'trivial change' pathway and use that pathway ALL THE TIME."

(In this context, "overhead" means testing, validating, documenting and deploying.)

In the previous post I examined how difficult it is to be sure that a given change is as small (in scope and therefor presumed possible consequence) as it appears, leading to the temptation to not us enough overhead when releasing that change. I also examined the flip side of that problem: not realizing that a large (in scope and therefor presumed possible consequence) is actually small in risk and therefor not deserving of lots of overhead.

In this post I am examining the tendency of organizations to have that outcome (too much or too little overhead) not on some misjudged changes, but on every dang change they make.

For some reason, organizations seem to find it exhausting to make a practice of weighing each change and acting accordingly. What I see in the field is a tendency to have a one-size-fits all policy at the top, usually in favor of lots of  safety-assuring overhead. This is the drive toward maximum overhead all the time. At the same time, there is a tendency among those who actually do the work to chafe at maximum overhead for minimum changes (or at least changes that seem minimal to the worker bees). This leads to the requirement of bureaucracy to ensure that the unpopular policies are followed.

The situation is further compounded by the occasional but real phenomenon of senior managers putting their fingers on the bureaucratic scales to make sure that changes THEY want get out the door in a reasonable amount of time. This leads to a policy & bureaucracy arms race: more change management leads to more cheating to get around it which leads to more bureaucracy to stop the cheating. Round and round we go.

"Reasonable" is the key here: we often have an intrinsic sense of how big a change is. This leads us to an expectation of how quickly that change can work its from wherever it starts to wherever we can see that change. If change management can deliver that change to us in what seems like a reasonable amount of time, then we are all for change management--who doesn't want greater safety and stability?

But if the change takes much longer than seems appropriate then we feel justified in being frustrated and annoyed. This is how we end up bending rules and sometimes having those bent rules trip us up.

As a tech leader, especially in cybersecurity, it is part of your job to make sure that "reasonable" includes the notion of risk of a cybersecurity problem. Your job is to maximize authorized access and minimize unauthorized access. Sometimes that means pointing out that a small change (in scope) carries an out-sized risk and therefore requires lots of overhead and therefor lots of time. Even if a vice president or an important client really wants to see that change ASAP. Their desires don't make the change any safer and rushing the change to please them makes that change riskier.

Helping you be the voice of clear-eyed risk assessment without becoming a pariah is part of our work making cybersecurity leaders effective members of the senior management team. This is hard. We can help.