Managing Two Teams With Different Needs

Problem

After joining a new company, I found myself working with two teams led by junior-level product managers. They were fairly new to the job and were having trouble making decisions about what we were doing from the perspective of the business.

Consider the big roadmap that this type of project would take to produce; it would take plenty of time to test and to gather feedback alone. Effective communication is vital to a successful working relationship between teams when producing something like this.

Actions taken

My job was to build up and to manage the Search and Discovery team, Greenfield-style. I also had to manage another team of the Brownfield persuasion. This second team was having some trouble. I started to work and look for a way to work with the Product Managers there. Then, I would be able to start building the teams around them. It was really interesting getting to experience managing two different teams in two different ways at the same time.

I came up with a list of pros and cons for each team. The Greenfield team was the first one that I actually worked with. They were having some trouble grasping the goals of the company from a business standpoint. The Brownfield team had some foundational understanding of the business domain. This was the first major difference in my eyes.

I then focused my efforts on building the teams up. For Greenfield, it took me a while to understand the different use cases and how we could translate their requirements to what we were doing on our end. I looked back into the technology in order to make sure that they were pushing the business and our KPIs forward.

In Brownfield, the technology and the set-up were already there. The business, at least, was up and running in this way. At that point, it was only a matter of improving the processes. I wanted to enhance the team’s communication so that productivity could be maximized.

Finally, the task of actually hiring for the team. Hiring for Greenfield was so much easier. I was very clear about the technologies and gaps that I was looking for. I was searching for a certain set of skills to help us build what we were trying to build.

We were finally able to measure productivity after we went live. We had a small demo up and running very quickly and were able to gauge how people were responding. We were finally able to gain a better understanding of what our intended product would require. Sometimes, taking a step back is all that you need to do.

Lessons learned

• When working with a new product manager, I need to build that sense of trust that allows for open and honest communication. I have worked with product managers who are really tough to get along with. When joining a team, I do everything that I can to show that I am present and ready to engage. We can do something here. We can fix the issues that we’re having. I find that it’s easy to solve conflict with the help of all of these different tools.
• Over time, you develop processes that help you work with one another. Collaboration improves and everybody ends up growing as a result. In a nutshell, you just need to work hard and gain the trust of everybody around you.
• As a manager, I always open the door for discussion in order to gain insight and feedback from others. I utilize all channels of communication when working with my team, not just email or Jira. I actively seek a conversation. I always feel the need to learn more in order to see the full picture. I try to validate everything that I say with a complete understanding of the problem.