Back to resources

Pursuing an Unpopular Project

Leadership
Internal Communication
Convincing

27 June, 2020

Tim Olshansky
Tim Olshansky

Chief Product & Technology Officer 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

10x engineer or 10x impact?

26 May

Hiring 10x engineers is hard for most companies. It’s a tough battle out there for talent. So how should most companies approach building their team?

Building A Team
Leadership
Hiring
Coaching / Training / Mentorship
Vaidik Kapoor

Vaidik Kapoor

VP Engineering - DevOps & Security at Grofers

The Art of Asking Why: Narrowing the Gap Between Customers and Users

24 May

Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.

Customers
Innovation / Experiment
Product
Personal Growth
Leadership
Stakeholders
Users
Jord Sips

Jord Sips

Senior Product Manager at Mews

Managing Different Time Zones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Managing Remotely: Balancing Team Cohesion and Focus Time

26 May

Jonathan Belcher, Engineering Manager at Curative, explains how to balance team cohesion and individual focus time, tapping into his experiences of working remotely for seven years.

Remote
Micromanagement
Meetings
Internal Communication
Productivity
Psychological Safety
Performance
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

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.