How I Succeed at Convincing… Everyone

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.