Dependency Management at Scale

Dependencies are the silent killer of large programs. A single unresolved dependency between two teams can cascade into weeks of delay, and at the scale of fifty-plus engineers across multiple workstreams, dependency management is not optional — it is existential.

The Visibility Problem

Most teams track their own dependencies informally. An engineer knows they need an API from another team. A tech lead knows they are waiting on infrastructure provisioning. But at the program level, these individual awareness points do not aggregate into a coherent picture. I have seen programs where twenty-plus cross-team dependencies existed and nobody had a complete view of all of them.

My Approach

I maintain a dependency board — a simple Jira board or spreadsheet, depending on the program — with five columns: Identified, Requested, Committed, In Progress, and Resolved. Every cross-team dependency gets a ticket with a clear description, the providing team, the consuming team, the needed-by date, and the impact if it is late.

This board is reviewed in a weekly fifteen-minute dependency sync that includes leads from all workstreams. The meeting has one purpose: surface blockers and confirm commitments. No status updates, no deep dives — just dependencies.

Patterns I Watch For

Dependency chains. When Team A depends on Team B, which depends on Team C, the risk compounds. I map these chains explicitly and escalate any chain longer than two links.

Silent dependencies. Teams that say "we are not blocked" but whose work implicitly assumes another team will deliver something by a certain date. I probe for these by asking, "What could prevent you from finishing on time that is outside your control?"

Dependency debt. Dependencies that get resolved with temporary workarounds rather than proper solutions. These accumulate and eventually cause larger problems.

The Cultural Dimension

The hardest part of dependency management is not the tracking — it is getting teams to surface dependencies proactively. Engineers often hesitate to flag dependencies because it feels like admitting they cannot do something independently. I normalize dependency reporting by celebrating early identification and treating missed dependency reporting as a process gap, not a personal failure.

Good dependency management feels invisible when it works. That is exactly the point.