Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Pursuing an Unpopular Project

Leadership
Internal Communication
Convincing

27 June, 2020

Tim Olshansky
Tim Olshansky

EVP Product & Engineering at Zenput

Tim Olshansky, EVP of Engineering at Zenput, outlines how he managed to pursue an unpopular project by limiting the scope of the changes and reframing the key objective.

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.

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.

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.

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.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Specialization vs. Wearing Many Hats

23 November

William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.

Internal Communication
Collaboration
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

Firing Somebody for the First Time

23 November

William Bajzek, Director of Engineering at Sapphire Digital, remembers the first time that he needed to make the ultimate sacrifice on behalf of the well-being of his team.

Leadership
Firing
Team Reaction
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

Mergers and Acquisitions: Collaboration tools hold a key to bringing cultures together

23 November

Neelima Annam, Sr Director Information Technology at Outmatch, shares how something as minor as collaboration tools can be a BIG issue during mergers and acquisitions.

Acquisition / Integration
Internal Communication
Collaboration
Neelima Annam

Neelima Annam

Sr. Director Information Technology at Outmatch HCM

What it takes to become a great product manager

19 November

James Engelbert, Head of Product at BT, shares his deep understanding of the traits of a successful product manager and how to get aligned with the organization’s path to success.

Product Team
Personal Growth
Leadership
Strategy
James Engelbert

James Engelbert

Head of Product at BT

The art of managing up

19 November

James Engelbert, Head of Product at BT, shares how managing up is all about being an excellent manager to bring the best out of a team.

Mission / Vision / Charter
Managing Up
Internal Communication
Strategy
Stakeholders
Cross-Functional Collaboration
James Engelbert

James Engelbert

Head of Product at BT

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.