A Product Manager’s Guide to Breaking & Rebuilding Technical Foundations, Part II: Managing Cross-Team Dependencies

In part I of our Product Manager’s Guide to Breaking & Rebuilding Technical Foundations we introduced the monolith, the foundational codebase that our product was built on. We already walked through our process for defining the scope and direction of this monolith deprecation journey, so today we’ll take the next step: managing cross-team dependencies.

Whether it’s a large-scale technical initiative the entire organization is working on or a local priority within your team, chances are high that you’ll face dependencies left, right, and center. A few of these common examples might sound familiar to you:

• Your team is spending a lot of time on code refactoring and therefore blocking another team in building a new feature for customers, because they would need you to make small adjustments to your part of the product to go along with their new feature.
• Your team is blocked by a centralized function working on the framework you’re currently trying to adopt for your replatforming, and every time you think you’re unblocked, a new edge case comes up, forcing you to stall your rollout plans.

Based on the discussion from Part I on being clear about the value you’re planning to deliver, it is equally important to understand to which degree some of the value is being blocked by cross-team dependencies. For instance, one team finishing off an important piece of discovery earlier than expected might unblock another team to start working on the implementation of a customer-facing feature, leading to a valuable cut in time to market. Another example would be system-wide performance gains enabled by improvements to a crucial platform component, which can positively impact the NPS of a product area that did not actively work on boosting performance.

Once these cross-team dimensions are understood in the context of your initiative, you and your peers need to set up good habits for collaboration and communication. If your team is executing on its roadmap successfully, we can assume that you have good internal communication habits already. In situations where other teams are highly dependent on you — or you are dependent on them — it is important to also foster alignment across these teams. For this, let’s focus on the two most important components: timeline and scope.

Yes, your timeline for single slices of work will move over time, but sharing these changes with stakeholders early on is key, as there is usually enough work to be parallelized. In other words, no one will be sitting around waiting for the one blocker to be resolved before they can continue to work. Especially during technical refactoring, a lot of cleanup work is produced, which can be picked up while waiting for others to unblock you.

Knowing as far as possible in advance when this moment will come allows you to refine these items in your backlog which you expected not to touch for a while. Of course, this requires that you challenge the team to create “cleanup stories” for the backlog as a regular part of the plan. It will be a lot harder to come back in the end and try to figure out what can and cannot be deprecated or dropped from the database.

In terms of scope, it is worth noting that this is not something you as the PM should be exclusively responsible for. We learned that it helps to establish a similar connection you might have with other PMs between the Engineering managers and/or lead engineers of those teams and regularly align in this small group.

Finally, it is important to keep your scope on individual Epics small enough to allow yourself and others to easily grasp what is included. Don’t try to hold on to a structure of Epics that you set up in the beginning with limited knowledge, but instead dare to re-evaluate and split up an existing Epic. Parallelizing work is a great option when dealing with dependencies, e.g. simultaneously building up your new system while preparing the soon-to-be deprecated one for the phase-out. At the same time, you should avoid running the same two Epics in parallel for months, otherwise it will feel like you’re never finishing anything, which can really kill motivation for you and your team.

Managing cross-team dependencies can be a challenge, but we suggest that you embrace the uncertainty and the fact that neither your nor your peers’ timelines can be predicted exactly! This means breaking your initiatives down into small Epics and doing your best to keep them contained. Make sure you communicate actively with your stakeholders about shifts in your timeline and have a backup plan for the times when you are being blocked. More than ever, in large-scale tech-refactoring it is on you to ensure an Agile mindset within the team, in order to minimize the time spent before you can go back to building customer-facing features.

In Part III of this series we’ll dive into best practices for managing the backlog — get excited! Until then, head to our careers page to check out our open roles.