Refining Product Team Leadership in Software Engineering
Achieving Efficiency between Engineering Manager, Product Manager and Tech Lead
Many tech companies are either making the shift or are already embracing a product team organizational setup. The benefits? It’s straightforward. This setup grants teams greater agility and independence, empowering them to swiftly adapt to customer demands and fuel ongoing innovation.
A product team in a tech orgazation may consist of:
- Engineering Manager
- Product Manager
- Tech Lead
- X amount of engineers
- X amount of designers
- Any other specialist role that is important for the specific product
The total amount of people on a product team typically does not exceed the famous Two-Pizza team rule from Jeff Bezos.
A product team operates independently, with the freedom to chart its own course rather than follow directives from outside. This autonomy typically revolves around three key roles highlighted previously: the Engineering Manager (EM), Product Manager (PM), and Tech Lead (in some teams Design Lead). These pivotal figures steer the team, streamline decision-making, and collaborate seamlessly, forming what’s known as the product triarchy.
However, the collaborate seamlessly is not always the case..
The interference zones
Roles within a team often intersect, sometimes leading to duplicated efforts or, in more challenging cases, conflict. Conversely, it’s not uncommon to also feel sidelined when not being informed enough or at all. Key areas where these overlaps and exclusions can occur include:
- Backlog Management
- Roadmap
- Running sprints
- Stakeholder Management
- Keeping each other in sync
- Engineering practices
Now it probably feels like I just listed nearly everything. This is actually quite accurate as it often seems like the roles within a product team leadership blur together, and that’s especially true in smaller organizations where one person might juggle two or even all the three critical roles. In my own experience, our team, equipped with all three key personas, occasionally stepped on each other’s toes across various areas of potential overlap.
Take the backlog, for example. There have been instances where either I, as the engineering manager, or the tech lead ended up creating duplicate user stories. Similarly, the product manager and the tech lead have found themselves moving the same backlog items in opposite directions.
Then there’s the roadmap. Who should take the lead here? The engineering manager, the product manager, or perhaps the tech lead, especially when the roadmap leans more technical? The truth is, regardless of who takes charge, the most crucial aspect is alignment within the product triarchy, and ensuring the roadmap aligns with stakeholder expectations.
Lastly, managing stakeholders stands out as a prime area for duplicative efforts. Different threads in team chats, emails, and meetings — both in-person and virtual — often see members of the triarchy communicating separately. This lack of synchronization not only leads to frustration but also wastes valuable time, emphasizing the need for better coordination.
👑 Efficient product triarchy
To evolve into a more efficient product triarchy, we took two significant steps to ensure gradual improvement:
- Defining Areas of Accountability — We agreed on explicit boundaries for each person’s responsibilities, ensuring clear accountability within the triarchy.
- Product Triarchy Meetings & Priority Leaderboard — We initiated bi-weekly meetings for the product triarchy and introduced a priority leaderboard to streamline our focus and tasks.
Areas of accountability
The most crucial step towards enhancing our efficiency was establishing clear responsibilities. We meticulously examined each responsibility we held, guided by this fundamental principle:
The engineering manager bears the overarching responsibility for the team, focusing on leadership aspects such as people management, budgets, and representing the team in different forums. The product manager concentrates on maximizing the team’s value delivery, overseeing the backlog, roadmap, and gathering requirements from stakeholders. The tech lead, on the other hand, ensures the technical excellence of our delivery, spearheading the architecture, engineering practices, and the day-to-day operations of the product.
Nevertheless, this broad overview wasn’t sufficient for practical application. Therefore, we proceeded to map out the areas of accountability on a board as illustrated below:
The shared space to the right outlines our approach to stakeholder communication. Generally, we prefer that only the product manager and engineering manager participate in what we call pre-delivery discussions. These are typically high-level and lengthy, thus skipping those, allows the tech lead to devote more time to the team. Conversely, as conversations shift towards delivery specifics, the tech lead takes on a more prominent role in communications and engineering manager is pulled in only when needed. This strategy helps minimize the number of open communication channels and saves time.
The meetings guideline is essential for staying informed. The guiding principle is to include both other roles in invitations to all pertinent meetings. This ensures everyone is aware and can choose to participate if their schedule permits or decline if not. By doing this, we avoid situations where someone feels excluded from important discussions.
Finally, we recognized that while specific accountabilities are assigned, it doesn’t preclude collaboration outside those boundaries. For instance, the engineering manager or tech lead can still of course engage with the backlog, which fall into the accountability of a product manager. The key is ensuring that the person accountable for a given area is always kept in the loop and remains ultimately responsible for keeping that area in optimal condition.
Product triarchy meeting & priority leaderboard
The next step in ensuring we’re all moving in the same direction involved establishing a dedicated time and space for discussing topics and aligning on our priorities. We accomplish this through our bi-weekly product triarchy meeting, where we address issues based on urgency, make decisions, and determine our priorities using a priority leaderboard. The priorities we discuss often extend beyond a single sprint.
Unlike standard scrum meetings with the broader team, certain priorities are exclusively handled by the product triarchy. For instance, we might delve into our collaboration dynamics with another product team or evaluate if our vendors are meeting our expectations and decide on the necessary actions if they’re not.
This approach isn’t overly complex. We utilize a specific board during our meetings to ensure they are organized and focused on achieving tangible outcomes as shown below:
Conclusion
The engineering manager, product manager, and tech lead are expected to collaboratively lead the team, respecting the established accountability boundaries. Yet, it’s essential to recognize that these boundaries are permeable, allowing for flexibility and support when necessary in order to leverage the strength of having all three roles within a single product team.
Moreover, the product triarchy accountability board mentioned could be further refined, perhaps by incorporating the RACI framework for clearer role delineation. Substitutes for each accountability area might come in handy when things like holidays or illnesses might get in your way.
Remember to revisit! Regularly revisiting and revising your accountability board and working methods ensures that you continuously adapt to changes and insufficiencies.
If you want to read more on this topic, I also highly recommend this article.
