Mapping Dependencies Across Teams That Don’t Share a Calendar

A marketing team plans in monthly campaign cycles. Engineering plans in two-week sprints. Legal reviews things whenever legal gets to them, on a timeline nobody outside legal has ever seen written down. Put a project across all three and you get a dependency chain where each link is measured on a different clock, and the project plan — built, understandably, around whichever calendar the project lead is most familiar with — quietly assumes everyone else will bend to it.

They won’t, not because anyone is being difficult, but because their calendar exists for reasons that have nothing to do with your project. Engineering’s sprint boundaries were set to protect focus time. Legal’s review queue reflects everything else legal is doing, most of which you’ll never see. A dependency plan that ignores this and just draws an arrow from “design done” to “engineering starts” treats two different operating rhythms as if they were the same rhythm, and that’s usually where the first unplanned delay comes from.

The Arrow on the Gantt Chart Hides the Actual Handoff

A dependency arrow on a project plan represents a single point: task A finishes, task B begins. In practice, that handoff involves a queue, a review, sometimes a re-prioritization against other work the receiving team already had committed. If engineering’s next sprint planning session isn’t until eight days after design says it will be “done,” the dependency doesn’t clear the moment design finishes — it clears whenever the receiving team’s own planning cycle next has room for it. That gap is invisible on most Gantt charts, which draw the handoff as instantaneous, and it’s exactly the gap that eats the buffer nobody remembered to add.

Questions Worth Asking Before You Draw the Dependency

Before a cross-team dependency goes into a plan, it’s worth finding out a few things that aren’t visible from the outside: when does the receiving team actually commit to new work — is it continuous, or does it wait for a planning boundary? How much lead time does that team typically need to fit something in, separate from how long the work itself takes once started? Is there someone on that team who can flag early if their queue is already full for the relevant window? None of these questions require a formal integration meeting. A five-minute conversation with someone on the receiving team, asked early enough to matter, usually surfaces all three.

A Shared Reference Point Beats a Shared Calendar

Getting two teams onto the same planning cadence is rarely realistic and usually isn’t worth pushing for — each team’s cadence exists for good internal reasons. What actually helps is a shared reference point: a specific date, visible to both teams, that represents when a piece of work needs to change hands. It doesn’t need to live in either team’s native planning tool. It needs to be visible in both, which usually means somebody has to manually keep it synced, or the project needs to sit in a coordination layer that isn’t owned by either team’s internal system.

Coordination approach	Works well when	Breaks down when
Shared project tracker for the whole initiative	Teams are willing to check a tool outside their own	Teams already ignore tools outside their daily one
Manually synced key dates	Few cross-team dependencies, checked often	Many dependencies, sync forgotten under pressure
Dependency owner on each side	Someone is explicitly accountable for the handoff	No one is named, so no one notices drift
Buffer built into the plan	Timelines allow slack	Deadline is already tight and unmovable

The Dependency Owner Is More Important Than the Dependency Tracker

Any tool can hold a list of dependencies. What most cross-team delays actually reveal is that nobody on either side felt personally responsible for watching a specific handoff. The design lead assumed engineering was tracking it. Engineering assumed design would flag it if the date moved. Naming one person, explicitly, as the owner of a given dependency — usually someone close to the receiving side, since they’re the one with visibility into whether the queue is actually clear — closes this gap far more reliably than adding another column to a tracker that people were already not checking.

Buffers Need to Reflect Where the Uncertainty Actually Lives

Standard advice says to build buffer time into a schedule, and most project leads do add some. The mistake is sizing that buffer based on the work itself rather than the handoff. If the actual design work is well-understood and low-risk but the handoff to a team with an unpredictable planning cycle is the uncertain part, the buffer belongs there, sized against how long that team’s queue has historically taken to clear — not tacked onto the design phase where the risk was never concentrated in the first place.

When a Dependency Can’t Be Resolved, Say So Early

Sometimes the honest answer is that a dependency genuinely can’t be cleared on the timeline the project needs, because the receiving team’s planning cycle simply doesn’t allow it. Surfacing that early, even when it’s an uncomfortable conversation, is far less costly than discovering it once the project is already behind and stakeholders are asking why. Teams that map dependencies well tend to treat “this might not fit the receiving team’s cycle” as a normal planning input to raise in week one, not a failure to admit in week six.

Renegotiating a Dependency Beats Discovering It Broke

When a dependency owner does spot early that a receiving team’s queue is full for the relevant window, the temptation is to quietly hope it resolves itself rather than raise it, especially if the project is already under schedule pressure and nobody wants to be the one delivering bad news. Raising it immediately, even before it’s a confirmed problem, gives both sides room to actually renegotiate — pulling the request forward into an existing planning cycle, trading priority against something else on the receiving team’s plate, or adjusting the requesting project’s own timeline while there’s still slack to absorb the change. None of those options exist anymore once the dependency has already quietly slipped and the delay is discovered only in retrospect.

Visibility Across Teams Is a Deliberate Choice, Not a Default

None of this requires everyone to adopt the same tool or the same sprint length. It requires deliberately building visibility across a boundary that no single team’s calendar naturally creates on its own. The projects that get quietly stalled by cross-team dependencies are rarely the ones where someone made a bad estimate. They’re the ones where two teams’ separate, entirely reasonable planning rhythms were assumed to line up without anyone actually checking.