Skip to main content

Put the “Team” Back In Teamwork and Eliminate Dysfunction

Having trouble meeting deliverables? Are your teams squabbling? Services impacted? Eliminate dysfunction between Engineering and Product Management. Recently, I’ve had three different encounters where the relationship between Engineering and Product Management (PM) teams came up. Ensuring great teamwork requires us to pay close attention to dynamics.

I Know of What I Speak

I come by my interest in the interplay between Product and Engineering honestly, beginning my development career as an engineer/coder.  As part of a successful start-up in the late 80’s, I was a part of a team that built code and developed new processes. The goal was to solicit meaningful feedback from our customers and stakeholders. Great engineers, partnered with focused PMs, did their best work.

This was reinforced when I worked for a commercial software “mega vendor” in 2003 that had a Product Management function. In those early days, it was just considered a support function for the engineering team.  However, in 2006, the broader adoption of Agile processes brought a significant change. Product Management became more of a “partner” with traditional engineering teams.  Throughout my career, I’ve led organizations on both sides of the equation. When we get the synergy right, it’s a thing of beauty.  And when we don’t…well, it isn’t even close to being pretty. 

Teamwork is the ability to work together toward a common vision. Bottom line—any sort of significant dysfunction between Product Management and Engineering teams is deadly to the whole team’s overall success.

Do the Right Thing – Do the Thing Right

Your personal reaction to the above statement may give you some insight into the challenges faced by development teams today. It may also help explain why your teams may be struggling with synergy.

Do the Right Thing emphasizes that what gets built is aligned with the needs and priorities of the stakeholders.  Typically, this would require an understanding of the business activities being supported. It also requires a high level of communication and interaction with the various stakeholders in the solution’s success.

Do the Thing Right places the emphasis on how to create the desired capability. Deep, nuanced understanding of the technologies, tools, and capabilities are needed. This leads to a robust, efficient, and high-quality result.   

Who Does What?

Product Managers tend to have the resources and background to effectively focus on the first imperative, Do the Right Thing. Engineers, on the other hand, have the resources and background to focus on the second, Do the Thing Right.  Remember to keep in mind that I used the term focus here.  It’s entirely possible that one individual could have the necessary skills and resources to handle both imperatives.  However, the energy needed for adequate focus on one or the other calls for splitting these out.

This focus on ensuring that everyone stays in their lanes can create great teamwork. PM teams, with their deep understanding of the problem, can focus on defining what needs to be built. It also helps them in prioritizing a tidy backlog.  Engineering teams can then focus on the big-picture of what needs to be done. This includes what tools and technology are needed to deliver a solution. Easy in concept—tough to get right every day?

Synergy Breakdown…Why Isn’t This Working?

I’ve seen two related difficulties when talking about teamwork:  confusion about the roles, and just plain old difficulty with communicating.

Role Reversal

Confusion about roles happens easily enough.  Many PMs coming into the workforce today have some level of training in one or more programming tools.  They may find it “easier” to show someone in code rather than trying to describe it in Epics and Stories. The more the merrier when working towards a solution right?  Wrong!  Jumping into the engineering lane brings their personal perception of the solution into play. It can also impact the description of the problem to be solved, in addition to stifling the team’s cumulative creativity. Additionally, it also sends a not-so-subtle message to the engineering team that they could, and should, be doing their job. This is a sure-fire way to generate resentment.

Similarly, many engineers have had some experiences with defining business problems. This experience may lead to them injecting their own perspective of problem into the project. The problem may then take the form of features aligned with their vision of what is needed.  Since they control the resulting code, shouldn’t they get to set the priority of which capabilities get built first?  These sentiments have been voiced on teams I’ve been a part of. I’ve seen the damage done to collaboration when the PM’s value is trivialized in this manner. Achieving synergy under these circumstances becomes very difficult.

Communication Breakdown

More often than not, the biggest issue between the teams is communication.

You’d think that it’s easy enough to describe what you want built.  But it takes a very disciplined person to focus on describing a problem to be solved without offering their own solution. Using techniques like the canonical form for user stories helps, but it’s still difficult.

Making matters worse, many engineers place a higher value on technical prowess than communication skills.  This can shift much of the communication burden within the relationship onto the PMs. The one-way street reduces the ability of the engineers to give meaningful feedback to the PMs about how to convey requirements, so they can be understood.  It’s important to remind the whole team that requirements are the communication of what needs to be accomplished. The responsibility falls on the entire team. To be successful, it requires an effective feedback loop to ensure that information is being received accurately.  

Smooth communication eases the drama that comes along with any group of people working toward a goal under tight constraints.  When communication breaks down, it’s easy to have unresolved misunderstandings that lead to a lack of trust. That lack of trust can easily make interactions contentious and undermine the project.

Teamwork Makes the Dream Work

So how do you get things back on track and create synergy? Here are a few strategies that I have found to be helpful:

  • Assume positive intent – engrain this imperative in all your teams.
  • Help educate engineers and PMs on the different roles that they play and how those roles should be interacting.
  • Work with all team members to coach on improving communication skills like empathizing, active listening, paraphrasing, and asking clarifying questioning.
  • Establish TRUST!

I’ve had the honor to work on numerous teams that understood and valued the interaction between the Engineering and Product Management disciplines.  The projects created by those teams stand out as some of the best times of my working career.  I’ve also had the opportunity to help some teams get past communication difficulties and move on to a better approach. Those were some of the most exhausting and frustrating (but ultimately the most satisfying) activities I’ve been involved with. 

I’m glad for the team I have here at Tangoe. Everyone has a keen desire to deliver the very best for our customers and teamwork is a top priority. People are also very open to improving our ability to work together to that end.  That mindset makes it easy to keep the interaction between the teams properly tuned. Technology expense management is challenging. Great teams shouldn’t be.

So how is your team doing?  Have you paid attention recently to the care and feeding of the relationship between Engineering and PM?  It might be a good time to revisit this crucial element to ensure continued success and to keep the “team” in teamwork.