Cross-team dependency analysis

Cross-team dependency analysis is the practice of mapping where one team work depends on another, then measuring how often those dependencies arise and how much delay they cause. A dependency exists whenever a team cannot finish its work until another team delivers something first, an API, a design, an approval, a data feed. The analysis makes those links explicit and attaches numbers to them so they stop being invisible.

Most delivery delays in a multi-team organisation are not caused by any single team being slow. They are caused by waiting. Work sits blocked while it waits on a dependency from another team, and that wait time is rarely measured because it falls in the gap between two teams. Dependency analysis closes that gap by tracking how much of total cycle time is spent blocked rather than being worked on.

The practice produces two outputs. The first is a map of which teams depend on which, showing the structure of coupling across the organisation. The second is an impact measure, the share of delivery time lost to waiting, which tells you which of those dependencies actually cost you. A dependency that resolves in an hour is structurally present but practically harmless. A dependency that routinely blocks work for days is where the analysis earns its keep.

There is no single formula for dependency analysis, because it combines a structural map with an impact measure. The core impact figure is the share of cycle time spent blocked waiting on another team, but the analysis is only useful when you also capture where the blocking happens and why. Each input below is something to record as work moves across team boundaries.

1. 1

   Dependency links

   Record which team is waiting and which team it is waiting on, for each blocked piece of work. Aggregated, these links form the dependency map and reveal which teams are most depended upon and which are most blocked.

2. 2

   Blocked time

   Measure how long each work item sits blocked waiting on a dependency, from the moment it is blocked to the moment the blocker clears. This is the raw material for the impact figure and the most commonly missing data point.

3. 3

   Dependency frequency

   Count how often a given dependency arises across work items. A dependency that appears in nearly every project is structural and worth designing around, while a one-off dependency rarely justifies a process change.

4. 4

   Resolution path

   Capture how the dependency was resolved, whether by a request, a handoff, or an escalation. Recurring escalations on the same dependency point to a structural fix rather than a one-time unblock.

Putting these together, the impact figure divides blocked time by total cycle time to show what share of delivery is lost to waiting. If a feature took ten working days end to end and four of those were spent blocked on another team, 40 per cent of the cycle was waiting. Combine that with the dependency map and you can see not just that work is slow, but exactly which inter-team seam is causing it and how often.

A metric tree decomposes dependency impact into the factors that create it, then traces each one to the team or interface that owns it. Dependency analysis on its own produces a map. The tree turns that map into a set of decisions about what to decouple, what to staff, and what to escalate.

The first level splits dependency impact into dependency volume, wait time per dependency, blast radius, and resolution speed. Each branch decomposes further. Dependency volume depends on how tightly coupled the work is and how many handoffs a typical item requires. Wait time depends on the responsiveness and capacity of the team being depended upon. Blast radius depends on how many downstream teams a single bottleneck blocks. Resolution speed depends on how clearly requests are routed and how quickly escalations are handled.

This structure lets you target the right lever. A high impact driven by sheer volume of dependencies needs decoupling, while one driven by long wait times on a single overloaded team needs capacity or prioritisation, not architectural change.

Dependency impact has no fixed industry benchmark, because the acceptable level depends on how interdependent the work genuinely is. The ranges below describe the share of cycle time lost to waiting on other teams, which is the most comparable figure across organisations. Use them to judge whether your blocking is healthy friction or a real drag on delivery.

As with most flow metrics, the trend matters more than the absolute level. A team whose blocked share is climbing quarter on quarter is heading toward a delivery problem even if it still sits in a comfortable band. Watch for concentration too. If a single upstream team appears in most of the blocked time, the benchmark of the whole organisation is being set by one bottleneck, and that is where the analysis should focus.

Improving the outcome of dependency analysis means reducing the delay that dependencies cause, not eliminating every dependency. Some coupling is necessary and healthy. The aim is to cut the waiting on the dependencies that sit on the critical path and block the most downstream work.

The metric tree approach starts by finding the branch with the largest impact, then assigning the fix to the team that owns the interface. KPI Tree lets you connect each dependency to the upstream team responsible for clearing it, with explicit RACI ownership on every node. When a dependency starts blocking work for longer than usual, the change is pushed to the accountable upstream owner rather than sitting unnoticed in a backlog. The verified impact loop then checks whether the decoupling or capacity change actually reduced the blocked time, so you know which interventions worked rather than assuming they did.

1. 1

   Counting dependencies instead of their impact

   A raw count of dependencies says nothing about which ones hurt. A team can have many fast-resolving dependencies and few problems, or one slow dependency that wrecks delivery. Measure the blocked time each one causes, not the count.

2. 2

   Treating all coupling as bad

   Trying to eliminate every dependency is wasteful and often impossible. Some coupling reflects healthy specialisation. The goal is to reduce harmful waiting, not to make every team self-sufficient.

3. 3

   Ignoring blast radius

   Focusing on the dependency with the longest single wait while missing the one that blocks five teams at once leads to fixing the wrong thing. Weight dependencies by how many downstream teams they hold up.

4. 4

   Not measuring blocked time at all

   Most teams track how long work takes but not how long it spent waiting. Without blocked time, dependency analysis is a map with no impact data, and you cannot tell which seams are actually costing you.

5. 5

   Blaming the upstream team rather than the structure

   When a team is constantly depended upon and keeps blocking others, the issue is usually structural overload, not poor effort. Treating it as a performance problem misses the real fix, which is decoupling or capacity.