Pursuing an Unpopular Project
27 June, 2020
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.
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.
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.
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.
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.
- 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.
Jeff Foster, Head of Product Engineering, shares how he managed to break down silos in his organization by encouraging their employees to choose their own team.
Head of Product Engineering at Redgate
Pierre Bergamin, VP of Engineering at Assignar, recalls his own transition to a leadership role in a new company and how he made everything smoother by embracing trust, delegating work and encouraging collaboration.
VP of Engineering at Assignar
Jose Pettoruti, Director of Engineering at CurrencyCloud, shares some tips on how to prioritize and balance tech work with ever-emerging new features by working closely with the product team.
Director of Engineering at CurrencyCloud
Jose Pettoruti, Director of Engineering at CurrencyCloud, describes how to handle multiple inputs from a number of people in an asynchronous mode.
Director of Engineering at CurrencyCloud
Murali Bala, Director, Software Engineering at Capital One, discusses the importance of psychological safety emphasizing its unparalleled significance during the Covid-19 pandemic.
Director, Software Engineering at Capital One
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.