Change Management: It’s not about gatekeeping

This was originally written before I read chapter 18 of the DevOps handbook. I feel strongly that peer review has greater legitimacy and chances of success than a system where a change manager is solely responsible for changes that may or may not fall within their area of expertise. It further grants employees more agency and autonomy in performing their jobs. While not directly addressed below, peer review is compatible with my views on change management.

I have served as change manager for one of my customers since the summer of 2017, following three consecutive change and maintenance windows that resulted in downtime for one of my customers. Despite the fact that I’d never done it before, I was happy to be offered the role, and have enjoyed the work and getting to know both the processes and our systems better.

I have always been a generalist, a technician with a broad knowledge base, rather than deep competency with a single system. This is a natural consequence of being a support specialist, but also suits my varied interests very well indeed. As a result, I also know that the vast majority of changes requested, are requested by people with far better capabilities than my own with the system in question.

There is also the notion that there is no such thing as an axe murderer, meaning that everyone is assumed to be there to do their jobs, and do them to the best of their ability. The assumption that there is no intent of malice going into the decision to request a change is important, and borrows from the idea of blameless post mortems following major outages. At its core, the idea is that we trust our personnel to do their jobs, to provide us with good advice, and to deliver on their responsibilities.

I went to the task of change management very much aware that my job is to say yes. I should only say no when there is a good reason for it, and even then, I should never simply say no. Instead, I should say “no, but…”, or “no, and…”, always offering an explanation. I couch it in these terms because they are familiar to me (as they will be for anyone who has played Itras By, where these two represent two of the chance cards that make up the core mechanic).

What do I mean, then, by them? Well, they serve different purposes. “No, but…” generally means a deferment, where as “no, and…” generally means to scrap the proposed change altogether. The way I see it, change management is about coordination. Only say no when you have a very good reason for it, and always offer up that reason.

When looking at a proposed change, I always run through a list of questions:

• Has the change been properly described?
• Has the risks been evaluated and mitigated?
• Has relevant stakeholders been consulted?

Once these questions have been answered in the positive, scheduling the change is a matter of availability of relevant staff, coordination with other duty sections, and notifying affected customers and duty sections.