Improving your working relationship with your product team

Problem

It can be quite difficult for different teams to have a good working relationship if there's no clarity on how they should work together. However, when I was a Director of Engineering, I received feedback from my company's Sales and Operations team that what we were building was not the right product. Also, there was a lot of friction between the Engineering, Product, Operations and Sales teams. It felt we were spending more time resolving disagreements due to this friction than we were on creating value. The reality was, we were not working as one big team.

Actions taken

While people often assume that engineers love technology for technology's sake, this isn't the case. Engineers love to build software that solves real problems, and not just to write code. Every time my team got negative feedback about not producing the right products, it had an enormous negative impact on their morale. My first step in solving this issue was talking to the Director of Product so we could be on the same page on what steps we will take to align our teams and get his buy in on my approach, we agreed that he would start the process of defining an updated vision for our Product and I would drive the definition of our process, roles, and responsibilities. I started with the Product team because is whom we work closely together with, if I could build a better relationship with Product, it would be easier later to fix the relationship with the Operations and Sales teams. I started writing down what I thought was a good reflection of our current process, roles, and responsibilities with a particular focus of answering why we do what we do. Next, we met multiple times with Engineering Managers and Product Managers, and we used this document as the centerpiece to what would become "the way on how we build software" a document that explains why, how and what do we do to deliver value as a Product and Engineering team. Since we agreed on the first version years ago, it has become part of our culture to review and challenge what is written there; we try to keep the process up to date with the learnings and changes that we implement across teams to keep improving while keeping it lightweight. This document has finally become an essential tool to get Product and Engineering aligned and working as one team.

Lessons learned

A team first approach is always the way to go to create successful products, and we should never forget that the team is more than just your fellow Developers. Throughout the software development process, we will go through stressful times, and we will disagree many times, to be able to succeed we need to provide our teams a solid vision, objectives, and clarity on their roles and responsibilities so we can minimize confusion and misunderstandings. Always get buy in from your Product counterpart and involve your team, put out a proposal and get their input so this becomes something created by the team and not just you, define clear goals for the adoption and ensure that everyone commits to review and update regularly. If you are going through a similar challenge and you want to go in depth into examples on how to solve this problem ask for some time with me so we can talk.