The demo is going well until it isn't. Two teams have spent a quarter building toward the same launch, each from its own end. The first team shows its piece and it works. The second team shows its piece and it works. Then someone tries to connect them live, and the room goes quiet, because the format one team produces is not the format the other team consumes. Neither team did anything wrong against its own plan. The plans simply never agreed on the seam.
What is striking is not that the dependency existed. Dependencies always exist between teams shipping toward a shared outcome. What is striking is the timing. The mismatch was true in week one. It was true every single day of the quarter. Both dashboards stayed green the entire time. The system did not surface the dependency until two humans physically tried to plug the cables together in week twelve.
Why the demo is where dependencies go to be discovered
A demo is the first moment in most companies when the actual interfaces between teams are forced to touch. Until then, each team works against its own internal model of what the other team will deliver, and those models are never reconciled because nothing reconciles them. Status updates do not reconcile them, because each team reports green against its own plan and both are telling the truth. The green dashboard problem is not that people lie. It is that local green and global green are different measurements, and most tools only show the local one.
A dependency is a claim by one team about another team's output: its shape, its timing, its meaning. That claim lives, if it lives anywhere, in a planning doc that was accurate the day it was written and has been quietly diverging from reality ever since. Nobody is watching the claim. They are watching their own tasks. So the dependency sits there, perfectly stable on paper and steadily rotting in practice, until the demo collides the two halves and reveals the rot all at once.
The hidden cost is the silence, not the surprise
The expensive part is not the moment of discovery. A surprise in a demo costs a few awkward minutes and some rework. The expensive part is the twelve weeks of silence that preceded it, during which both teams felt confident, reported progress, and consumed budget building toward a join that was never going to work as drawn.
This is the structural failure behind most cross-functional dependencies: the dependency is real, but it has no owner and no home. It belongs to the space between two teams, and the space between two teams is exactly where every tool stops. Each team's project tool knows its own tasks. Neither knows the other's. The dependency is a relationship, and the tools store objects, not relationships, so the most important fact about the launch is the one fact nothing is tracking.
Why "more communication" misdiagnoses it
The retro will conclude that the teams should have talked more. They should sync weekly. They should have a shared Slack channel. This feels right and changes little, because Slack channels are not status and a weekly sync surfaces a dependency only if someone happens to ask the precise question that exposes it. Hope is not a mechanism.
The deeper issue is that the dependency was never made into a tracked object that both teams could see change. When a dependency is just a sentence in a kickoff doc, its drift is invisible. When team A quietly reschedules the work team B was counting on, nothing in team B's world turns yellow, because team B is not subscribed to team A's plan. The communication advice assumes humans will manually carry information across a boundary every week without fail for a quarter. They will not. They have their own work.
What it takes to surface the seam early
A dependency surfaces early only when it is a first-class object with a status of its own, visible to both sides, that changes when either side's plan changes. Team B should not have to attend team A's standup to learn that the interface slipped. Team B should see the dependency it relies on turn yellow the moment team A's underlying work turns yellow, because the two are linked in the structure rather than in someone's memory.
This is what it means to connect projects to goals and to each other rather than letting them run as parallel silos. The launch is not two projects that happen to share a date. It is one outcome with a seam down the middle, and the seam needs an owner, a status, and a place to live. When the seam is modelled, the demo stops being a discovery event and becomes a confirmation of something both teams have been watching for weeks.
What to do this quarter
Take your next cross-team launch and find the seams before the demo does. For each pair of teams shipping toward it, write the explicit claim each is making about the other: what shape, by when, in what format. Then ask who owns each of those claims and where its status is visible to both sides. Almost always, the answer is that the claim lives in one team's doc and the other team has never seen it.
Make one seam a tracked object this quarter. Give it an owner who is not on either team, or who is explicitly accountable for the join. Watch whether it turns yellow before the demo. If it does, the mechanism worked, and the awkward silence in week twelve never happens.
FAQ
Why do cross-team dependencies surface so late? Because the dependency is a relationship between two teams, and most tools store objects within a single team. Each side reports green against its own plan, both honestly, while the seam between them drifts unwatched. The first moment the interfaces are forced to touch is usually the demo, which is week twelve, not week one.
Won't a weekly cross-team sync catch this? Only if someone asks the exact question that exposes the mismatch, every week, without fail. A sync surfaces a dependency by luck, not by mechanism. The reliable fix is to make the dependency a tracked object with its own status, visible to both sides, that changes when either plan changes.
Who should own a dependency between two teams? Someone accountable for the join itself, not for either half. When ownership of the seam is unassigned it defaults to nobody, which is why the project that belongs to no one is where dependencies quietly fail.
How is this different from a Gantt chart with dependency arrows? A Gantt arrow records the dependency once, at planning time, and does not update when the underlying work moves. What matters is a live link: when team A's work slips, the dependency team B relies on turns yellow automatically. Static arrows document the seam. A linked structure watches it.