Managing Cross-Team Dependencies
28 December, 2020

Principal Product Manager at Adobe
Problem
My team works with multiple stakeholders on different initiatives and all those different initiatives have some dependencies. Most of our dependencies are with the operations team. The operations team works on a project-by-project cadence and is driven by demand. When their stakeholders request something, they will do their best to make it a priority for another team. My team is, on the other hand, more agile and heavily relies on planning. We have our roadmap and are reluctant to take on ad hoc projects. The operations team would also commit to their stakeholders without acknowledging the dependencies with my team until the time would arrive to act on these commitments. From the stakeholders’ point of view, it would look like my team is blocking their initiatives.
Recently our chief business officer called a meeting with the two of our teams to understand the dependencies better and help us sort them out. We already discussed the problem before and I came up with a solution -- we would leave things as they were for the current quarter and only then prioritize for the next quarter. But, that was not a satisfactory solution for the operations team.
Actions taken
We sat down together to discuss our current situation and we concluded that our two teams are tightly dependent and that we would have to come up with a joint solution for mutual dependencies. I proposed to set up biweekly meetings to sync up with the other team and learn more about what they were doing or plan on doing. Even with a biweekly cadence, new requests and, therefore, dependencies kept popping up.
Frequent communication was insufficient to replace a much deeper misalignment between two of our teams. Namely, my team would do extensive planning; we would share our roadmap and be very transparent about things we would focus on in both the ongoing and upcoming quarter. I would be proactive in communicating this with different teams letting them know of our plans and encouraging them to deliver their request in advance so that we could slot them in early on. We use our product management framework to do prioritization and wouldn’t commit to anything without conducting a serious assessment first.
The problem was that the other team worked ad hoc driven by -- often urgent -- requests by their stakeholders. They would be quick to commit and then they would shovel these requests throughout the quarter.
In the most recent meeting we had with our CBO, I felt confident because I followed the plan and timely engaged everyone in the planning process. Everything that was on our list was discussed during the prioritization exercise that included all stakeholders and was aligned with the company goals. When the decision would be made at the executive level to re-prioritize on things or add a task, I would do so by dropping off whatever would be of the least priority. We would be very transparent about the whole process and everyone would know why something was added/dropped off.
Lessons learned
- Identify dependencies first. But identifying them is not nearly enough, they have to be called out repeatedly. Calling them out to stakeholders, users and the dependent team, so that there is a clear -- and well-communicated -- understanding about what the team is blocked on.
- In this particular case, dependencies were not clear to the end-user, that is, our CBO.
- The problem with the other team, emblematically, was the lack of a long-term vision and doing things ad hoc. Typically this approach would more often create dependencies and blockers and would consequently impede cross-team collaboration.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
26 May
Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Elwin Lau
Director of Software at JANA Corporation
19 May
Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Jonathan Belcher
Engineering Manager - Patient Experience at Curative
16 May
Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Alexis Philippe
Vice President, Product & Engineering at Amilla
16 May
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Snehal Shaha
Senior EPM/TPM at Apple Inc.
13 May
Tom Hill, Engineering Manager at Globality, Inc., describes his decision-making practices when making architectural decisions.

Tom Hill
Engineering Manager at Torii
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.
