Driving changes can introduce a lot of toil. First of all, take a step back and think of whether or not you have the time and energy to push for a change. If not, full stop, that’s a clear indicator that perhaps now is not the right time or that you should rely on your sphere of influence to get someone else to own the change (Unless that change solely falls under areas that you have full control of).

Structure of a change

I selected anatomy purposely since I believe that changes become living organisms within any organization. Changes have a structure to them that understanding it can help being successful at championing them. A change, while it may seem targeted, normally has a broader impact than the particular area you are aiming for. In summary, a change impacts:

• People

• Process

• Technology

The real triad of any organization and the collection of what eventually become systems.

Therefore, understanding how a change is structured and how to own each area effectively is key.

Skeleton of the change

The core of the change is not just necessarily what needs to be changed but the analysis of whether or not is now the right timing for the change. By timing, I mean not just a reference of time but also a reference of organizational willingness (or lack of) to the change. Are you trying to introduce a change in an area that is not the biggest burning fire? Have you contemplated the culture of the organization? This will be key to determine if the change will be sustained or die quickly. Finally, is this the hill you want to climb now or are there other pressing needs that you may have more control of to earn sure victories?

Muscle of the change

This is what will be built on top of the foundation of an organization that will support the change. In this part of the change, it’ll determine how strong of a bond you can form between the core of the change and what the change will end up looking like. Here is where you can rely on your sphere of influence and discuss the proposed change with those you believe can provide you meaningful input on your prior analysis of timing and the organization’s ability to support the changes you wan to make. There isn’t a number too high of people you can get feedback on. However, it is very easy to get into paralysis by analysis if you are uncertain of success. If this is the case, that’s a signal you should consider that perhaps now is not the right time and put the change in your backlog for later.

The look of the change

This is where the actual change management occurs. Making a change will most likely not happen overnight. Every change is always met with some sort of resistance (as shown below) and every part of the system that the change touches must be allow to adapt to it at its own pace. At this stage is where you think about how you want to divide the change into smaller milestones. Pick paths of least resistance to allow the change win small victories which create the momentum to go to the harder parts of the change.

Depending on the change, you may want to select the first few phases of the change to be things that are considered well understood or accepted. Are there obvious parts of your change that you know from the stages above that if introduced the impacted system will accept? At every phase of the change, you have to make sure that you keep a watchful eye on how the change is being adopted and adapted to. Be quick about making decisions the moment you see the change going wrong or if the resistance to the change is for sure going to halt everything.

Don’t be afraid to pull a change if during the changes you encounter critical difficulties. This tells you that the organization is not ready for such change or the solution you are trying to introduce isn’t the right one.

If your change has made it through the curve, congratulations. But the job isn’t over yet, now you have to manage the change and make sure that it has a life of its own. This means that you will most likely need to make adjustments as the needs of the organization change or if and when the parts of the change become irrelevant.

Anatomically speaking, do not forget about the fact that a change within an organization has long extremities. That means there will be areas of the organization that the change will touch that were previously blind spots to you. Be nimble and work through all these phases to make sure that the change gets its full reach and potential.

Quick example

To bring some reality to my points, I wanted to highlight a large change that I was a part of driving at a prior employer. The change was part of the company’s decision to migrate all critical services to the cloud and as part of that, we wanted to completely change the security model that the infrastructure had. Following the structure above:

• The skeleton of the change was:

  • Understand the reasons for why the company chose to move to the cloud and align with some of those reasons and include security debt to it – reliability and security can go hand to hand.

  • Yes, this is a change that we need to work on now (tl;dr; a lot of toil was in place for keeping some of the tech/security debt in place).

  • Yes, my team owned a large portion of the change.

  • Yes, the organization had matured enough to be able to sustain such change.

• The muscle of the change:

  • We socialized the change and talked about the additional security controls we wanted to introduce and the why. In order to find a sticky substance outside of security (to drive more acceptance), we postured the change more of a freeing time (toil) from the engineers’ day to day and had automation handle most of the challenges.

  • We communicated the phases of the change, as an example: New services will be adopted into this new framework vs let’s do a Big Bang roll-out.

  • We also associated security to overall quality of the service to help drive more adoption as we all wanted to prioritize quality.

• The look of the change:

  • We phased this out as mentioned above.

  • We identified that in order to facilitate the change and drive general adoption, my team had to own and build a lot of the systems. We did that.

  • Throughout the implementation, we had ongoing discussions with the impacted stakeholders to evaluate the progress and identify any issues.

    • This caused us to pivot a few times in certain areas. Luckily we had phased this out and it did not put the whole project at risk.

  • We were obtaining constant feedback by the general users (engineers) to allow us to know where we should move next or pivot from.

  • We dealt with the change curve – particularly the shock and resistance part by demoing implementations of the change to showcase the ease of use and how much less toil the teams would have to deal with.

  • We also responded to the extremities of the change by working with teams outside of the immediate engineering organization and address their use cases as well.

  • Progress/debt reduction was being measured throughout the whole process.

Closing thoughts

Remember, making a successful change within an organization can be very rewarding but also an easy point of failure if not managed well. Before proposing a significant change, ask yourself:

• Is this the most immediate thing you need to focus on now?

• Are there any parts of the system that are under your full control instead?

• Do you understand the culture of the organization enough to drive a change?

• Is this something that meets a need and can the organization handle it (maturity wise)?

• What are the parts of the change you can introduce first to earn credibility and reduce resistance?

• How are you going to manage the change throughout and after?

Following this structure will give your change a high chance of success.