Cross-Team Dependencies: Why They Stall Projects and What You Can Do About It
Published
A lot of project delays don't start inside a single team. They start in the gap between teams — the moment one group finishes its part and passes the work on, and something quietly goes wrong in the handoff.
That gap is where cross-team dependencies live. Once you can see the structure of the problem, you can start working with it instead of around it.
What a cross-team dependency actually is
A dependency is a relationship where one piece of work can't move forward until something else is done first. When that relationship crosses team boundaries — Team A waiting on Team B, Team B waiting on Team C — you have a cross-team dependency.
These aren't unusual. In organisations running more than one project at a time, cross-team dependencies are common. The engineering team needs a design spec before they can build. The marketing team needs a product feature before they can launch. The operations team needs a process documented before they can train anyone.
None of that is inherently a problem. Dependencies become problems when they're invisible, misunderstood, or forgotten.
Why they cause projects to stall
There are a few structural reasons cross-team dependencies break down, and they tend to make each other worse.
Each team sees only its own slice of the work
When teams operate in separate tools, separate calendars, or separate conversations, they naturally build separate pictures of what's happening. Team A knows its own deadlines and blockers. Team B knows theirs. But neither team has a clear view of how their timelines connect.
This isn't a failure of effort or communication. It's a structural gap. When the work lives in different places, the connections between the work become invisible by default.
Some practitioner discussions describe this as one of the harder parts of scaling coordination — not that people aren't trying, but that the structure itself makes shared visibility difficult. You can find one such discussion in this practitioner conversation about cross-team communication.
Assumptions travel poorly across boundaries
When a dependency is first identified, the people in the room share a set of assumptions: what "done" looks like, what format the output will take, what the timeline is, what happens if it slips. Those assumptions feel obvious in the moment, so they often don't get written down.
By the time the work reaches the next team, those assumptions have evaporated. The receiving team makes their own assumptions — which may be different — and the gap only surfaces when something breaks.
Status information decays quickly
A dependency that was on track last Tuesday might be blocked by Friday. But if the teams involved aren't in regular contact, the downstream team may not find out until they're ready to start their own work and discover the input isn't there.
The longer the gap between when a dependency shifts and when the affected team learns about it, the harder it is to recover. Buffer time gets consumed. Options narrow. Pressure builds.
Accountability diffuses across layers
Inside a single team, it's usually clear who owns what. Across teams, ownership gets murkier. Who is responsible for flagging when a dependency is at risk — the team creating the output, or the team waiting for it? When no one has explicitly claimed that responsibility, it tends to fall through the gap.
In environments where projects span multiple teams, each with their own leads, priorities, and reporting lines, this diffusion gets worse. There are more layers between the people who notice a problem and the people who can resolve it.
The multi-layer problem
A single project with two teams is manageable. You can track the dependency in a shared document, a conversation, or even a sticky note. The problem is that it scales badly.
When you have five projects running in parallel, each touching three or four teams, the number of dependencies grows faster than the number of projects. Some are direct — Team A needs Team B's output. Some are indirect — Team C's capacity depends on Team B finishing on time, which depends on Team A delivering early enough.
At that scale, no one person can hold the full picture in their head. The dependencies that are visible are the ones that have been explicitly mapped. The ones that haven't been mapped are the ones that tend to cause surprises.
This is why multi-layer environments need more than a list of tasks. They need a way to see how work connects across teams and across time — not just what each team is doing, but how those streams of work relate to each other.
What makes dependencies more manageable
There's no single workflow that works for every team. But a few practices can reduce the damage cross-team dependencies cause.
Make the dependency explicit and shared
A dependency that only one team knows about is a risk. When both teams — and ideally their leads — share the same understanding of what's needed, by when, and what "ready" looks like, there's a shared basis for conversation when things shift.
This sounds obvious, but it requires deliberate effort. Dependencies don't document themselves. Someone has to name them, write them down, and make sure the right people can see them.
Preserve the context around the dependency
The dependency itself — "Team B needs Team A's output by the 15th" — is only part of the picture. The context matters too: why that date, what happens if it slips, what assumptions are baked in, what decisions were made along the way.
When that context is preserved and accessible, teams can reason about the dependency together. When it's lost — because it lived in someone's head, or in a message thread that's now buried — teams are left guessing. And guessing under pressure tends to go badly. Some practitioner conversations touch on exactly this: how much coordination effort gets lost when the reasoning behind decisions isn't carried forward with the work itself. One example appears in this discussion about lost project context.
Build in a way to see the work across time
Dependencies are time-sensitive by nature. A dependency that's fine today might be critical in two weeks. Being able to see how work is distributed across time — not just what's due today, but what's coming, what's at risk, and where the pressure points are — gives leads the lead time they need to act before a dependency becomes a blocker.
How Tindlo approaches this
Tindlo is built around the idea that teams need to see their work across time — not just as a list of tasks, but as a shared operational view that brings projects, teams, and work types together on a common time axis.
Work items in Tindlo can carry context alongside the task itself: people, files, links, a brief, comments, and schedule information. That means the reasoning behind a piece of work — the decisions, the assumptions, the dependencies — can travel with the work rather than getting left behind in a conversation.
The Day and Week views let leads see how work is distributed across teams and time. That makes it easier to spot where dependencies are creating pressure before that pressure turns into a missed deadline.
Tindlo also connects to Google Calendar, so the work your teams are already scheduling there can sit alongside the operational view rather than living in a separate place.
If you're managing work across more than one team and finding that the connections between teams are harder to track than the work itself, it might be worth seeing how Tindlo's multi-layer workspace fits your situation. You can explore Tindlo here.
A structural problem, not a people problem
Cross-team dependencies stall projects for structural reasons, not personal ones. When teams can't see each other's work, when context gets lost at handoffs, when status information decays before it reaches the people who need it — delays follow. That's a visibility and context problem, not a reflection of how hard anyone is working.
Treating the connections between teams as something worth actively tracking — rather than something that will sort itself out — is one of the more practical habits a project lead can build. It doesn't require a perfect process. It just requires making the invisible a little more visible.