Managing Cross-Team Dependencies

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.