How do you manage cross-team dependencies?

Question

Accepted Answer

A **dependency** is something your work needs from another team or system before you can finish. **Cross-team dependencies** are one of the top causes of delay, because they put part of your timeline outside your control. Managing them is about visibility, early coordination, and reducing reliance where you can.

## Make dependencies visible

```text
✓ MAP them early → what do we need, from whom, by when?
✓ Identify the CRITICAL PATH → which dependency, if late, delays everything
✓ Track each one explicitly (a RAID log or dependency board)
✓ Confirm the OTHER team agrees to the timing — a date you assumed isn't a commitment
```

## Coordinate proactively

```text
✓ Talk to the other team EARLY — give them lead time
✓ Agree on interfaces/contracts up front so both sides can work in parallel
✓ Re-confirm as deadlines approach; check in, don't assume
✓ Have a fallback if the dependency slips
```

## Reduce dependencies where possible

The best-managed dependency is the one you removed. Can you stub/mock the other team's piece and integrate later? Sequence work to start independent parts first? Decoupling buys resilience.

## A concrete example

Your feature needs an endpoint from the platform team. Instead of waiting, you agree on the API contract now, build against a mock, and integrate when their endpoint lands. The dependency no longer blocks your start — only your finish.

## A common pitfall

Assuming another team's timeline without confirming it, then being blindsided when their priorities shift. Their roadmap isn't your roadmap unless they've agreed.

## Why it matters

A project can be perfectly run internally and still slip entirely because of one unmanaged external dependency.

Visibility (map and track), early coordination (agree contracts and dates), and decoupling (mocks, parallel work) turn dependencies from silent timeline bombs into managed, predictable hand-offs.