Managing Cross-Team Dependencies

Why Dependencies Kill Releases

Cross-team dependencies are the number one cause of missed release dates in enterprise environments. They're invisible until they're urgent, and by then it's too late to fix them without slipping the timeline.

The problem isn't that dependencies exist — they always will in complex systems. The problem is that nobody owns them until they become a crisis.

The Dependency Operating Model

1. Surface Early — The Dependency Discovery Ritual

Run a dependency discovery session at the start of every PI or quarterly planning cycle. Every team answers three questions:

• What do we need from other teams to deliver our commitments?
• What are other teams waiting on from us?
• What shared services or platforms could block us?

Format: 30-minute session per team. Use a shared board (Jira, Miro, or a simple spreadsheet). Each dependency gets a card with: description, provider team, consumer team, needed-by date, confidence level.

2. Own Explicitly — The Dependency Register

Every dependency must have:

• A single owner — not a team, a person
• An agreed delivery date — not "sometime in Q2"
• A confidence score — High / Medium / Low
• A RAG status — updated weekly

If a dependency doesn't have all four, it's not being managed — it's being hoped for.

3. Track Weekly — The Dependency Standup

A 15-minute weekly ceremony (not daily — that's too frequent for cross-team work):

• Walk the dependency board left to right
• Focus only on Amber and Red items
• Ask: "What's changed since last week? What's the blocker? Who's unblocking it?"
• Escalate anything that's been Red for 2+ weeks

Who attends: One representative from each team with active dependencies. Not the whole team — just the person who owns the dependency.

4. Escalate Fast — The 2-Week Rule

If a dependency stays Red for two consecutive weeks without a clear resolution path, it escalates automatically to the programme level. No judgement, no blame — just visibility.

The escalation format:

• What's blocked
• Who's blocking it (team, not person)
• What's been tried
• What decision is needed

5. Resolve Proactively — Dependency Patterns

Most dependencies fall into predictable patterns:

API / Integration dependencies: Agree on the contract (interface) early. Build against mocks. Integrate late.

Shared service dependencies: Book capacity in advance. Treat shared services like a restaurant — you need a reservation, not a walk-in.

Data dependencies: Define the schema and sample data upfront. Don't wait for the full dataset.

Environment dependencies: Automate environment provisioning. If you can't, escalate the infrastructure constraint.

The Dependency Heat Map

Build a simple heat map showing which teams have the most dependencies on each other. This reveals structural problems:

• If Team A depends on Team B for everything, consider reorganising
• If one shared service is blocking 5+ teams, it needs more capacity or a self-service model
• If dependencies cluster around release windows, your release process needs work

Common Mistakes

1. Tracking dependencies but not owning them A spreadsheet with 50 dependencies and no owners is just a list of future problems.

2. Only surfacing dependencies at PI Planning Dependencies emerge continuously. Your discovery process needs to run at least monthly.

3. Treating all dependencies equally A dependency with a 2-day lead time is not the same as one with a 6-week lead time. Prioritise by risk, not by count.

4. Waiting for the dependency to be "ready" before planning Plan around the dependency. Build what you can without it. Integrate when it arrives.

Tools

• Jira: Use linked issues with a custom "Dependency" link type. Filter by cross-project links.
• Spreadsheet: The dependency matrix template on this site works perfectly for teams not ready for Jira-level tracking.
• Miro / Mural: Great for visual dependency mapping in planning sessions.

---

Download the [Dependency Matrix template](/templates) to start tracking your cross-team dependencies today.