Effective collaboration with Product Managers, an Engineering Manager guide
While some organizations struggle with friction between product managers (PMs) and engineering managers (EMs), others achieve a harmonious alignment. The companies that manage it best can reach a harmony of alignment and trust. I have seen it, and it exists, trust me! 😀
I have been experimenting with different approaches to this problem domain in the past 7 years of my management positions. This post explores the reasons for this tension and offers practical solutions to bridge the gap and foster collaboration.
Example: integrating a new payment method
Consider a project in a fintech company to integrate a new payment method. The PM would push for a faster implementation from the options the engineering team presents, even if that’s not ideal for future scalability. The EM, on the other hand, might advocate for a more generic solution that accommodates future payment methods, even if it takes longer to develop.
Analogy: Project management triangle and CAP theorem
The fact is that even though all the employees in the company are aligned on shared goals, there still is a divergence of those goals based on the perspective of each discipline.
The inherent tension between PMs and EMs often stems from differing priorities. This can be illustrated by two well-known concepts:
- The Project management triangle: This principle states that once you start changing one of the three constraints of the triangle, another one has to compensate. Otherwise, quality will suffer.
- For example, cutting the budget without adjusting the schedule or scope will lead to lower quality.
There will always be trade-offs. - “Good, fast, cheap. Choose two.” as stated in the Common law of business balance.
- The CAP theorem (in computer science): This theorem states that a distributed data store can only guarantee two of the following three properties: consistency, availability, and partition tolerance.
Similarly, PMs often prioritize features and time to market (scope and time), while EMs prioritize technical quality and long-term maintainability (cost and quality). Both approaches are valid and aligned with the company’s goals, but achieving the ideal balance can be challenging.
Lesson learned: effective PM <-> EM collaboration
Long term: utopian ideal
In an ideal scenario, PMs and EMs would collaborate on all decisions, including capacity planning for various projects. While this utopian ideal is achievable, it requires a strong foundation of trust and shared understanding.
Building trust: the foundation for collaboration
As Patrick Lencioni highlights in his book The Five Dysfunctions of a Team, trust is the cornerstone of any effective relationship. Building trust between PMs and EMs takes time, but it allows for open communication and collaborative decision-making to address challenges.
How to build trust between EMs and PMs?
North star vision:
One effective way to build this trust is to build together a high-level Northstar vision. It doesn’t have to be a technical design, even having an alignment on the guidelines and high-level components of the systems we are building together can build that trust.
Shared wins:
When PMs and EMs achieve a common goal, for example celebrating a successful product launch or overcoming technical hurdles together, it reinforces a sense of shared purpose and accomplishment.
Open communication:
Regularly scheduled check-ins where both PMs and EMs openly share concerns and updates help to build trust and transparency.
Vulnerability and empathy:
By being open about challenges faced on both the product and engineering sides, and by actively listening to each other’s perspectives, PMs and EMs can build empathy and trust.
And what should I do before reaching the utopian ideal?
I know that it’s not very common to be able to reach the utopian ideal state. And it definitely doesn’t happen immediately. That’s way, hile building the necessary trust, I suggest you fallback to the proposed short-term solution described here.
Short-term solution: splitting ownership
As a practical solution in the short term, consider dividing ownership based on each role’s expertise:
- The PM’s skills make them the experts to answer the “Why” we are choosing to work on a specific project as they are experts in building a product vision and competitor analysis.
- The PM’s skills make them the experts to answer the “What” we are scoping to build and all items priorities as they are experts in defining an MVP to meet the user’s needs.
- The EM’s skills make them the experts to answer the “How” we are building the product as they are experts in the system design and engineering best practices.
You can use this separation to split the concerns of any projects between the EM and the PM. It will give the optimal results, as well as bring harmony to the teamwork.
I first came across this idea when I read this insightful post “PM & EM: Rules of Engagement”, and ever since I have used this separation to de-escalate conflicting situations between product and engineering.
And in my group, we split the project execution between the EM and PM primarily based on that separation.
Here are some examples to help visualize the separation:
- In the planning process
- The PM is responsible for creating a prioritized list of items we will work on
- The EM is responsible for sizing the engineering effort in the list of backlog items
- In the rollout process
- The PM is responsible for defining data analysis requirements
- The EM is responsible for creating the production monitors and alerts of technical health
Problem example: PM prioritizing technical backlog items
A common source of conflict arises when technical backlog items that address long-term maintainability and performance compete for priority with new features. While PMs typically prioritize based on business KPIs, technical backlog items focus on non-business metrics like development velocity and code quality.
And so, it’s difficult for the PM to understand the “Why” of technical backlog items.
Some will say that technical KPIs are also related to business KPIs, but at best, Dev velocity can be a lagging metric to business KPIs and as such it would be hard to visualize the impact of technical backlog items.
In the long-term utupian Ideal, a trusting relationship allows PMs and EMs to understand each other’s priorities and collaboratively build the backlog. As a short-term solution, consider allocating a portion of the team’s capacity (e.g., 20%) to addressing technical debt items.
Solution: prioritize backlog 80–20 to tackle technical backlog
A pragmatic approach I have used in the past involved splitting the team’s capacity to 80% product backlog and 20% technical backlog. I have seen this split in many variations in other companies.
With this approach’ you’ill be able to guarantee some capacity is allocated for the technical backlog items.
Also, it will prevent conflicts and arguments related to prioritizing product versus technical items.
It might be that the ratio of 80–20 doesn’t fit all. I have seen teams agree on other ratios (90–10 or 70–30). The agreed-upon ratio is not that important as long as it exists.
It’s ok if we won’t be able to prioritize all the necessary items we need, the most important thing is to have the tools in place to generate progression in product and technical backlog.
Key takeaways:
- PMs and EMs often have different perspectives, leading to friction if not managed effectively.
- Building trust is essential for fostering open communication and collaboration.
- PMs answer “Why” and “What,” while EMs answer “How.”
- In the long-term Utopian Ideal, the PM, and EM will be able to trust each other’s suggestions for priorities and build the backlog priorities together.
- A short-term solution is to split ownership based on expertise and allocate 20% capacity for the technical backlog to guarantee it will have some capacity and avoid neglect.
By following these principles, PMs and EMs can bridge the gap, achieve a harmonious working relationship, and deliver high-quality products that meet business goals.
