Back to resources

How I Succeed at Convincing… Everyone

Convincing

2 April, 2021

Irina Stanescu
Irina Stanescu

Tech Lead & Staff Software Engineer at Ex-Google Ex-Uber

Irina Stanescu, ex-Tech Lead at Google and Uber, describes how she convinced her PM and a partner team to change the course of an already designed & architected project by means of compelling arguments.

Problem

I came back from vacation only to realize that my PM and a partner team agreed to move on with a feature that was building on top of one of my team’s features.. I strongly disagreed with their approach and eventually managed to change the course of the project by convincing every single one of them (design, product & eng) to re-think their solution.

Actions taken

The PM and partner team didn’t properly take into account how the new feature would fit in with the rest of the features. It did not take into account some corner cases and it was also changing the paradigm we were following until then, making it hard to maintain.

In short, it was not thought through. I strongly felt that I or someone else from my team -- other than the PM -- should have been included in that discussion to provide more context and bring up some of our concerns sooner. This feature was in a relatively advanced state, designs were finalized, teams had already met and agreed to move forward, engineering started coding.

I could’ve given up thinking it's too late. I knew time was critical, there wasn’t enough time to kickstart an email thread with everyone, and their calendars for the week were packed. So what I did instead was try to find the decision makers in person in the office, briefly explain why the solution was lacking and ask them to make some time to meet again to walk them through the details. Folks were obviously not happy about it, but at least they agreed to meet with me.

Once we were all in the same room, I realized I was the only person who had strong opinions against the feature, but as it would turn out, by the end of the meeting, all of them were persuaded by my arguments.

I started the discussion by asking them to elaborate on what they were trying to build and how. I acknowledged the business need -- which seemed reasonable -- but questioned their approach of how they were trying to build it. They then walked me through their understanding of how what they were building on top of worked and proceeded to describe their solution in more details. That actually allowed me to spot the issues even better and validated my team’s concerns. I asked them if they had thought of x and y or how z was impacting xy. The more questions I was asking, the clearer it became to them that their solution was not the right one.

Besides the specifics of implementation, I brought up the long-term maintenance because their solution was much harder to maintain, and basically duplicating code, and my team was the sole maintainer of that system. I believe that corroborating my arguments with empathy, solid data and clear messaging helped me change their minds. Even the designers who spent three weeks on a new solution agreed to discard their own work for the sake of a better and simpler solution.

Lessons learned

  • Don’t give up. The decision of the new feature was made while I was out of office, so naturally I could’ve thought it was too late to change anything. But I didn’t because I thought it was my responsibility to at least try and voice my concerns. People need to feel empowered to speak up, if they have compelling arguments to do so.
  • It was the right thing to do not to follow the regular process in order to speed things up. I know what wouldn’t work -- spending endless time on emails, even Slack or GoogleDocs, back on forth. Due to the urgency of the business need the other team was trying to solve, I knew I had to bring all the actors together in one room and, without delay, open up the discussion. I also knew that I had to involve more people from my team to explain better the context and the implications their solution would have on my team.
  • Resolving conflict can actually strengthen cross team collaborations. Since this incident, the partner team and my team have actually had very efficient collaboration and there were no more miscommunications and throw away work.

Discover Plato

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


Related stories

The Importance of Effective Communication Skills in Technical Roles

3 June

Dursun Mert Akkaya, Software Development Manager at Product Madness, encourages a change in mindset for heavily technical individuals as he explains the importance of communication skills.

Different Skillsets
Personal Growth
Leadership
Internal Communication
Collaboration
Convincing
Career Path
Mert Akkaya

Mert Akkaya

Software Development Manager at Product Madness

Checking For Values Alignment When Considering a New Role

20 June

Tommy Morgan, VP Engineering at Crystal Knows, recalls a time in his career when his values didn’t align with his superiors and shares his insights on preventing this outcome when taking on a new role.

Changing A Company
Goal Setting
Managing Expectations
Company Culture
Leadership
Productivity
Convincing
Motivation
Psychological Safety
Toxic Atmospheres
Health / Stress / Burn-Out
Performance
Tommy Morgan

Tommy Morgan

VP Engineering at Crystal Knows

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

The Evolution of a Startup Co-Founder

15 March

Shawn Sullivan, Co-founder & CTO at Phase Genomics, shares how his career has spanned from working at a tech giant to co-founding a startup in every stage of his growth.

Changing A Company
Dev Processes
Company Culture
Impact
Convincing
Changing Company
Career Path
Shawn Sullivan

Shawn Sullivan

Cofounder & CTO at Phase Genomics

What Companies Can Do to Reduce Technical Debt

8 March

Tejas Kokje, Senior Software Engineer at Netflix, Inc., highlights how long-term thinking, planning, and organizing can reduce technical debt in a product organization.

Dev Processes
Convincing
Tech Debt
Tejas Kokje

Tejas Kokje

Senior Software Engineer at Netflix, Inc