The Critical Role of Conflict Resolution in Teams

Problem

As a Product Manager, I routinely developed new features or products. About 3 - 7 engineering teams were responsible for delivering the quality from one end to the other. To make progress in such an environment, the individual teams that I worked with developed their own points of view about how the solution should work.

I often saw conflicts between engineering teams. At one point there were loud arguments in the meeting room. Although it resulted from their passion for the product, sometimes it got so extreme that we had to end the meeting abruptly. In this case, we were able to align on a high-level solution. I went from having a room full of engineers shouting at each other to a solution where everyone agreed on a single solution.

Actions taken

My initial step as the product manager was to work with each team independently. I set up my time accordingly to have a conversation with one of the teams to understand their solution deeply. From their point of view, I had to understand two different key elements:

• What were the fundamental problems they had to fix as part of their engineering solution?
• Why were those problems important to solve?
  

I did the same thing with the opposite team, where I had to understand why they disagreed with the other team or why their solution was superior to the others? In short, it was all about meeting with the different groups, having empathy for their points of view. I had to have empathy and deeply understand or gain expertise in what they were trying to achieve, what they identified as their problems, and why they arrived at the solution that they did.

The second step was to identify the hidden understandings of whether the solutions that the teams had were requirements for the feature of the product. I had to think from the central product manager's point of view. After my evaluation, I had conversations with the teams separately, whereby I swapped each other's solutions. I went to team A and identified the cases they were trying to solve, while I went to team B and presented them with what team A had given me.

Finally, once we all had time to think it through, I brought the new solutions independently to the new teams. In tune, I had to ensure to get more alignment before the next meeting to conclude finally. In the meantime, both teams had grown empathy towards each other, which helped us develop a unified perspective. Finally, when I had aligned with the engineering leads on both teams, it was easier to work towards the new direction that everyone had agreed to.

Lessons learned

• As a product manager, you do not necessarily need to solve engineering problems. You are responsible for translating the team's needs to each other to better understand the overall product vision.
• When working with several teams, sometimes there are some hidden assumptions made. However, as the product manager, it is important to be transparent; otherwise, the solution developed will not solve it.
• It would help if you always were willing to change your mind in the face of new information.
• Do not be afraid to course-correct your event that may delay your project. It is always better to be correct and on point rather than being mistaken.