Cross-team dependency impact

Cross-team dependency impact is the measurable delay and rework a piece of work absorbs because it has to wait on a team other than the one delivering it. If a feature takes ten working days to ship and four of those days were spent waiting on a design review, a security sign-off, or a data pipeline owned by another team, then 40% of the delivery time was dependency impact rather than build time. The metric isolates the cost of the handoff itself.

It matters because the slowest part of most delivery is not the work, it is the waiting. A team can be fast and disciplined and still miss every deadline because the things it needs arrive late from elsewhere. When you do not measure this, the blame lands on whoever delivers last, even though the delay started three handoffs upstream. Measuring dependency impact moves the conversation from who is slow to where the system stalls.

The simplest version divides blocked time by total cycle time and expresses it as a percentage. To make the number useful you need to capture each handoff cleanly, which means recording when work moves into a waiting state and which team it is waiting on.

1. 1

   Total cycle time

   The elapsed time from when work started to when it was delivered. This is the denominator. Without an accurate end-to-end clock, every other figure is meaningless. Track it the same way you track cycle time for any work item.

2. 2

   Blocked time per dependency

   For each external team a work item waits on, record the hours or days it spent blocked. A single item can have several dependencies, so capture each one separately rather than as a single lump.

3. 3

   Owning team of each block

   Label every block with the team responsible for clearing it. This is what lets you attribute impact rather than just measure it, and it is what turns the metric into something a specific team can act on.

4. 4

   Number of dependent items

   Count how many work items in the period touched at least one cross-team dependency. A high impact concentrated in a few items is a different problem from a moderate impact spread across everything.

A worked example makes the maths concrete. Say a quarter ships 50 work items with a combined cycle time of 500 days, and 150 of those days were spent blocked waiting on other teams. The cross-team dependency impact is 150 divided by 500, or 30%. If 120 of those 150 blocked days trace back to a single platform team, you now know exactly where to focus, even though the delay surfaced as missed deadlines across five different squads.

A metric tree decomposes cross-team dependency impact into the specific handoffs that create it, then traces each handoff back to the team that owns the wait. This is the difference between knowing delivery is slow and knowing which queue to clear first.

The first level splits the impact by the type of dependency: approvals and sign-offs, shared platform or data work, design and content, and external vendors. Each branch decomposes further. Approval delay is a function of how many approvals are required and how long each approver takes to respond. Platform delay depends on the depth of the platform team backlog and how long a request sits before it is even picked up. Reading the tree, you can see whether the impact is caused by too many handoffs or by slow response within each one.

KPI Tree models this by attaching RACI ownership to every node, so the team accountable for clearing a given block is named on the branch. When dependency impact climbs, the push goes to the accountable owner of the handoff that moved, not to the team that happened to deliver last. The verified impact loop then checks whether a change, such as pre-approving low-risk work, actually reduced the wait or just shifted it elsewhere.

Benchmarks vary by how interconnected the work is. A self-contained product team will see low impact, while a team building on shared platforms and tight compliance gates will see far more. The useful comparison is against your own trend and against the share of impact that sits in a single owner.

A falling impact percentage is only good news if cycle time is falling with it. If teams cut dependency impact by simply doing more work themselves, the headline number improves while quality and consistency quietly degrade. Always read this metric alongside total cycle time and rework, not on its own.

Reducing dependency impact means either removing handoffs or making the ones that remain faster. The most common mistake is to push every team to be quicker without asking why the work needs to leave the team in the first place.

The metric tree approach starts by finding the single node with the largest gap between current and acceptable wait time. If one platform queue accounts for most of the impact, adding capacity there beats asking five delivery teams to plan around it. If approvals dominate, the fix is fewer or faster sign-offs, not more diligent chasing.

KPI Tree connects each branch of the dependency tree to the team and the action that influences it. The team that owns a shared platform sees its own node and how its backlog feeds the delivery delays downstream. When the metric moves, the accountable owner of the handoff is notified rather than the team that delivered last, and accountability lands where the wait actually started.

1. 1

   Counting internal backlog as dependency impact

   Time a team spends working through its own queue is not a cross-team dependency. Only count time genuinely blocked on another team. Mixing the two inflates the metric and points the fix at the wrong place.

2. 2

   Blaming the team that delivers last

   The delay usually starts several handoffs upstream. Without attributing each block to its owning team, the cost lands on whoever finishes the work rather than whoever caused the wait.

3. 3

   Treating all handoffs as equal

   A two-hour approval and a two-week platform build are both dependencies, but they do not deserve the same attention. Decompose the impact by owner so effort goes to the nodes that actually move the number.

4. 4

   Improving the percentage by hoarding work

   Teams can lower dependency impact by doing everything themselves, which raises rework and erodes shared standards. Always read the metric alongside cycle time and quality so the improvement is real.