Team Flow and Cross-Team Dependencies: Where Flow Actually Broke
This page is built on an organisational change programme run inside one of the largest business units at a globally active research and advisory company. Nine teams covering product and technology sat behind yearly revenue in the hundreds of millions of dollars, tasked with doubling it. The programme was grounded in evidence: we put twenty-five dimensions to a scored question set and added a qualitative pass to surface what a score alone cannot say.
The analysis started with the map.
Start with the map
Correlation, not causation: every edge is a measured statistical association (p<0.05) from this engagement, not an asserted cause. Edges below |r|=0.35 are omitted for legibility; the rest are drawn thicker and more opaque the stronger they are. The map stays focused on Flow of work: hover any dimension to preview its own connections against it, and use the strength slider to keep only its strongest links.
The map opens centred on smooth flow of work: whether work moves without stalling. Its two strongest neighbours are the tell. Not batch size, not board hygiene: obstacle removal and one team: the dimension that measures how blockers get cleared, and the dimension that measures whether the organisation behaves like one team or many. Both are boundary dimensions. Flow, in this organisation, was a property of the spaces between teams.
What the numbers said
With a median of 8 out of 10 the tail still runs longer than most dimensions in this assessment: of sixty-one respondents, thirteen scored flow at 4 or below. Roughly one in five people experiences the work as something that stalls. Where it stalls is what the words answer.
What the words said
The two dark blobs not lining up is the chart.
This dimension carries six coded units from the team survey, five of them negative against one positive. On the same axis the words centre at 3 and the scores at 8. And the sore units share one shape: every stall happens at a seam, not inside a team:
“Interdepartmental requests have unpredictable response times. Some requests require multiple rounds of additional followup.”
“The flow of work from many directions and distribution of right balance of work is still a concern.”
“We do many tasks in parallel rather than finishing one thing at a time.”
And from the leadership interviews, what those seams do to the people standing in them:
“Frequent interruptions. They can’t focus on building the code.”
“Many of us wear multiple hats, task switching.”
Requests crossing department lines with no reliable response time, work arriving from many directions at once, parallel-everything as the coping strategy. WIP discipline inside a team cannot fix a queue that lives between teams.
Where it lived
Nine teams, anonymised, best to worst. Thin rows render wider and flatter; less data looks uncertain, not falsely precise.
Split across nine teams: six sit at 7 or better on the median, up to 9, and three sit below, down to 4.5. That split is what seam-bound flow looks like from above: your flow score depends on how many of your dependencies cross a team boundary, and whose queue your blockers die in.
What flow turned out to be entangled with
Measured next to it:
- Risk and obstacle removal (r = .71), the strongest single pull
- One team (r = .70)
- Product intake (r = .66)
- Delivery predictability (r = .64)
Obstacle removal at .71 makes sense the moment you read the units: unblocking is cross-team traffic control. And the one unit that names a specific fix names a seam, not a practice:
“For reporting teams we often have blockers at source systems that require a partner IT team member to prioritize our needs. This process is cumbersome and could be optimized.”
A blocker whose resolution lives in another team’s priorities is not an impediment, it’s a negotiation. The same load signature shows up from the human side in this client’s sustainable-pace case study: work from many directions, absorbed by evenings. This is why flow lines up with the boundary dimensions and not with any team practice. Correlation is what the reading rests on; cause is not established.
What happened next
The programme’s cross-team planning and unblocking structures were the levers aimed at exactly these seams; the organisation went on watching as things shifted, and the numbers that came after are not mine to claim. The check that travels: take your last ten stalled work items and mark where each one stalled, inside your team’s own control, or waiting on another team’s queue. If the stalls cluster at the seams, your flow problem is a boundary problem, and WIP limits inside the team are aimed at the wrong queue.
A note on the data
A real engagement; an unnamed client, and it stays that way. Team names and identifying details are removed, and quotes are lightly edited for anonymity. Every number here traces straight back to the underlying assessment data, recomputed at render time from roughly 2,000 combined data points across both survey streams, not asserted. One organisation, correlations not causes.
Read Next
- Value stream mapping: finding the flow interruption
The stalls this client measured live between teams, exactly the seams a value-stream map is built to expose.
- Team flow: identify flow impediments first
WIP overload and task switching are the impediments the sore units name, but here they arrive from outside the team’s own board.