When Two Teams Are Both Waiting on Each Other: A Dependency Story
A mid-sized public agency was rolling out a new permitting portal. Two groups carried the work: an internal applications team building the front end, and a data team standing up the records database behind it. On paper the plan was tidy. In practice, the two teams were working from different floors, different time zones after a remote shift, and two different project trackers. Names and dates have been changed, but the shape of this will feel familiar.
How it stalled
The applications team assumed the data team would hand over a finished API by the end of March. The data team assumed the applications team would send finalized field requirements first. Neither assumption was written down anywhere both teams could see. For three weeks, each side believed it was blocked by the other and quietly worked on lower-priority tasks instead. The first time anyone said the word 'blocked' out loud was at a steering meeting, when the sponsor asked why the demo date had slipped. By then, two sprints were gone.
Nothing here was incompetence. Both teams were busy and capable. The failure was that the dependency between them lived only in people's heads — and in a remote, hybrid setup, the hallway conversation that used to catch this never happened.
What would have surfaced it earlier
A dependency is a promise: one team agrees to deliver something another team needs, by a date, in a defined form. The fix is to make that promise explicit, visible, and owned. A few habits do most of the work:
Name the dependency as a two-sided commitment. Write down who needs what, from whom, in what form, by when — and have both sides confirm it, not just the receiving team.
Give it a single owner. Each cross-team dependency needs one named person accountable for the handoff, on the providing side. 'The data team' is not a person.
Put it on one shared view. A simple dependency log or a shared board beats two separate trackers. If a dependency is not visible to both teams in the same place, it does not really exist.
Review it on a short cadence. A 15-minute weekly sync between the two leads, focused only on upcoming handoffs and changed dates, catches slippage while there is still time to react.
The deeper lesson
Cross-team dependencies are where projects quietly die, because no single team owns the gap between them. The risk is highest exactly when people are distributed and informal coordination has thinned out. You do not need heavyweight governance to manage this — you need a shared, honest list of who is waiting on whom, reviewed often enough that a slipped date is noticed in days, not at the demo.
Make 'I am blocked' a normal, early thing to say, not an admission of failure.
Track dates the providing team commits to, not dates the receiving team hopes for.
When a date moves, trace it forward: whose work just slipped because of it?
If your delivery keeps stalling at the seams between teams, XNM's program & project delivery advisory can help you make those dependencies visible and keep them moving.