Pursuing an Unpopular Project

Problem

The company I was working for had a very lucrative sales opportunity with a large government department and part of the deal included requirements around information security processes. More specifically, we had to go through a certification process that required changes to how we deployed software to production, how we kept track of any modification to our system and how we documented a number of things that we were doing at that time.

"We had to go through a certification process that required changes to how we deployed software to production, how we kept track of any modification to our system and how we documented a number of things that we were doing at that time."

While the requirement to document things didn’t sound burdensome, due to the scale of the team -- we had several hundred engineers operating to an extent independently -- it factually was. Generally, we favored an environment that granted team members autonomy over their workflow, and these requirements entailed that everyone had to do things the same way and document it in a universal form. Naturally, that provoked a lot of internal pushback mainly caused by concerns about deadlines, scopes, and cultural impact.

"Generally, we favored an environment that granted team members autonomy over their workflow, and these requirements entailed that everyone had to do things the same way and document it in a universal form. Naturally, that provoked a lot of internal pushback mainly caused by concerns about deadlines, scopes, and cultural impact."

Actions taken

As the person responsible for the engineering organization I decided to embrace the unfavorable situation as a possibility for success while balancing the propelling sales opportunity with the team’s discontent.

My job was to implement the changes, but I was, nevertheless, continually advocating for what I thought was right instead of merely following what the business thought needed to be done. At that time I strongly felt that the right thing to do was not to follow the explicit requirements, but rather the intent and do what was specified in the certification while finding a way to meet the requirement by the right level of automation and documentation that would not cause drastic changes to how we did things and that would isolate the changes as much as possible.

"At that time I strongly felt that the right thing to do was not to follow the explicit requirements, but rather the intent and do what was specified in the certification while finding a way to meet the requirement by the right level of automation and documentation that would not cause drastic changes to how we did things and that would isolate the changes as much as possible."

I tried to emulate the common practice regarding the Payment Card Industry (PCI) compliance -- to be able to accept payments over the Internet with credit cards, you have to go through certification. What I wanted to do and what I effectively implemented was to isolate certification-related changes and apply them to a small team of people. I limited the scope of the changes to affect only 15 to 20 percent of our process and hired a team whose sole responsibility was to manage the new workflow. As a result, the impact on the broader organization was limited and didn’t require everything to drastically change.

"What I wanted to do and what I effectively implemented was to isolate certification-related changes and apply them to a small team of people. I limited the scope of the changes to affect only 15 to 20 percent of our process and hired a team whose sole responsibility was to manage the new workflow. As a result, the impact on the broader organization was limited and didn’t require everything to drastically change."

The other thing I did was to reframe the key objective. The person who was in my role before me, made everything look like an inevitable consequence of a single sales deal that was driven externally and imposed on us. The reality was that our existing internal workflows, processes, and security capabilities were not satisfactory. In the grand scheme of things, these changes were unavoidable and would significantly improve our performance. People who were discontent were unaware of the context and it was on me to educate the team and explain to them why we should be doing this, regardless of that deal.
I was inspired throughout my actions by a quote from Kent Beck, an American software engineer and the creator of extreme programming, who said, Make the change easy, then make the easy change. I tried to make the change easy enough for everybody that all of the internal fighting against it would disappear because it would be a very easy change to make.

"The reality was that our existing internal workflows, processes, and security capabilities were not satisfactory. In the grand scheme of things, these changes were unavoidable and would significantly improve our performance. People who were discontent were unaware of the context and it was on me to educate the team and explain to them why we should be doing this, regardless of that deal."

"I was inspired throughout my actions by a quote from Kent Beck, an American software engineer and the creator of extreme programming, who said, Make the change easy, then make the easy change. I tried to make the change easy enough for everybody that all of the internal fighting against it would disappear because it would be a very easy change to make."

Lessons learned

• Traditional change management prescribes that you start with the context, provide everybody with information, and explain the benefits. Then, in the application of changes, you should select a small segment to apply them first, prove them successful, and take lessons learned and extrapolate them to the wider organization. However, in the face of pushback, I had to apply a more unorthodox approach and limit the scope of the changes altogether. Keeping the change small and easy is what makes bigger change management successful.
• If possible, before a project is broadly communicated, try to determine all of the unpopular parts ahead of time. We mistakenly assumed that people would be happy with this change, not only because it was a great sales opportunity but because it would accelerate the inevitable changes. We failed to vet the reality beforehand and that could have easily been done by testing the reactions of people before any action.