Why dependencies are where programs die
I have read a lot of program post-mortems. The proximate cause is almost always something specific, like an integration that didn't work or a vendor that missed a date. The root cause is almost always something more boring: a dependency between two teams that crossed an org boundary, sat on a tracker for weeks, and was nobody's actual job to chase.
The team running the work is usually fine. The work happening inside a team's boundaries gets done because the team is staffed, focused, and accountable to itself. The work that has to cross between teams is where programs lose their grip.
"A dependency is structurally different from a task. A task lives inside a team's accountability. A dependency lives between two teams, in a space neither of them owns by default."
Most PMs, when they manage dependencies, manage them by tracking them. They build a list, assign owners, set dates, and review the list weekly. The list grows. The dependencies, meanwhile, continue to live in the gap between teams, untouched. The fix is not better tracking. The fix is treating each dependency as a relationship, not a row.
The single most underused move in dependency management
Put both names on the row. Not "Engineering" or "Marketing." Humans, by name. The asker (downstream) and the asked (upstream). This is the cheapest move available and the one most PMs skip.
Once both names are on the row, schedule the conversation. Not the meeting where the dependency gets reviewed in front of the program team. The conversation where the two named humans agree, between themselves, that the work is real and the date is real.
When the conversation happens, dependencies usually clarify themselves. Half were misunderstood. A quarter were misdated. A few turn out not to be real dependencies at all. The remaining ones are the ones to track carefully. Most PMs spend their dependency-management energy on a list that is mostly noise. They should be spending it on the small subset that survives the conversation, and following them like a hawk.
The cadence that holds
- On any new dependency: Put both names on the row. Schedule the 15-minute call within 7 days. The call is the work, not the tracker.
- Weekly: 10-minute scan of the top dependencies (the ones that survived the conversation). What slipped? What new ones surfaced? Anyone need to be escalated?
- Monthly: Walk the cross-org dependencies with the program sponsor. These are the ones that need air cover, not tracking.
- On a slip: Pull both humans into the same room (or call) inside 48 hours. Slips that linger become disasters; slips that get a conversation become trade-offs.
