Managing Dependencies Before They Manage You

Projects rarely die from bad work. They die from good work waiting on other work. The feature was finished on time — but the API it needed shipped three weeks late. The campaign was ready — but legal review sat in a queue nobody was watching. The launch slipped — and in the retro, everyone agrees the delay was "coordination," which is the word teams use when a dependency failed and nobody owned it.

Dependencies are where project risk actually concentrates, because they combine two dangerous properties: they sit between teams, where no single person's job description covers them, and they fail silently, because the upstream team rarely feels the pain it is causing downstream. Managing them is a learnable system — mapping, contracting, buffering, monitoring, escalating — and this guide walks through each piece with the templates and scripts to run it.

Know what you are dealing with: a working taxonomy

"Dependency" covers several different animals, and they need different handling. Classify each one on two axes.

Axis one: how hard is the constraint?

• Hard dependencies — physically cannot start or finish without the input. You cannot test against an API that does not exist; you cannot print signage without the final logo.
• Soft dependencies — the work can proceed without the input, at a cost: rework risk, worse quality, or an ugly workaround. You can build against a mocked API and absorb integration fixes later.

Teams habitually misclassify soft as hard ("we're blocked!") and then wait when they could be building. The question that sorts them: "If the input arrived two weeks late, would we be idle, or would we be redoing some work?" Idle means hard. Redoing means soft — and soft dependencies are managed with rework budgets, not waiting.

Axis two: who is on the other end?

• Internal (same team): sequencing within your own plan. Cheapest kind — visible on your own board, fixable in your own standup.
• Cross-team: the expensive kind, and the subject of most of this article. The other team has its own priorities, its own planning cadence, and no automatic reason to care about your date.
• External (vendors, agencies, regulators, app-store reviews): the least controllable kind. You cannot escalate inside someone else's company; you can only contract, buffer, and chase.

One more distinction worth naming: resource dependencies — where the constraint is not an artifact but a person or a shared service. "We need the security team's review" and "we need Dana, the only person who knows the billing code" are dependencies too, and they hide from artifact-focused planning. Put them on the map with everything else.

Mapping: the 60-minute dependency workshop

Dependencies do not announce themselves; they are discovered — cheaply in a workshop or expensively in week nine. Run this session at kickoff and again at any major phase boundary. Attendees: the project lead, one representative of each workstream, 60 minutes, a shared surface everyone can draw on.

1. (10 min) List the deliverables. Not tasks — deliverables. The 10–20 concrete things this project must produce, on cards.
2. (20 min) Draw the arrows. For each deliverable, ask the room three questions: What must exist before this can start? What must exist before this can finish? Whose time does this need that we do not control? Draw every answer as an arrow. Expect the picture to get ugly — the ugliness is the information.
3. (10 min) Classify each arrow. Hard or soft; internal, cross-team, or external. Mark cross-team and external arrows in a different color. Those are your risk register now.
4. (10 min) Interrogate the surprises. Every workshop surfaces two or three arrows someone did not know about. "Wait — the email templates need translation? Since when?" Those two or three arrows are worth the whole hour; they are the ones that would have detonated in week nine.
5. (10 min) Assign an owner per external arrow. Not the person doing the upstream work — the person on your project accountable for watching, chasing, and escalating that dependency. One name per arrow. "The team" owns nothing.

Two questions that reliably flush hidden dependencies, worth asking explicitly in step 2: "What are we assuming will just be there?" (environments, credentials, data, budget approvals, a decision from an executive) and "Whose calendar are we assuming?" (the designer shared with two other projects, the release-review board that meets biweekly, the legal team with a three-week queue).

Visualizing: one picture per audience

Dependency information needs different renderings for different consumers. Three that cover almost every need:

The timeline with arrows — for planning and for leadership. Dependencies drawn between bars on a Gantt view make sequence and slack visible, and once arrows and durations exist, the critical path can be computed instead of guessed. This matters because the scariest-looking dependency is frequently not the one that controls the end date — arrows into slack absorb delay for free, while a modest-looking arrow on the critical chain moves launch day one-for-one. (If critical path mechanics are new, our explainer on the critical path method walks the math; for when a timeline beats a board at all, see Gantt charts are not dead.) In Openbook, the Gantt room does this directly — drawn dependencies between bars, milestones, and automatic critical path — so the workshop's whiteboard arrows can become the living plan rather than a photo in a slide deck.

The dependency table — for weekly management. A simple structured list beats a diagram for tracking state:

We need	From	Needed by	Type	Status	Owner (ours)	Last checked
Bulk-export API v2	Platform team	May 12	Hard, cross-team	At risk — their sprint slipped	Maya	May 2
Final brand assets	Design agency	May 5	Hard, external	On track	Jonas	Apr 30
Security review	SecEng	May 19	Hard, cross-team (queue)	Not yet requested	Maya	—
Translated templates	Localization vendor	May 16	Soft — English fallback exists	On track	Priya	May 1

Note the columns that do the real work: needed by (with buffer already applied — more below), last checked (a dependency unchecked for two weeks is a dependency in an unknown state), and owner (singular, on your side).

Board-level flags — for the daily working surface. Cards blocked by an external input get a visible marker and a reference to the dependency they wait on, so "blocked" becomes queryable instead of anecdotal. If more than about 20 percent of a board's in-progress work is flagged blocked, that is not a task problem; it is a portfolio-level dependency problem that no amount of individual chasing will fix.

The cross-team dependency contract

This is the practice in this article with the best effort-to-payoff ratio. Most cross-team dependencies fail not from malice but from vagueness: "Platform said they'd have the API ready around mid-May" contains four ambiguities ("Platform"? "the API"? "ready"? "around mid-May"?), and each one will be resolved differently by each side.

A dependency contract is a short written agreement — five fields, ten minutes to write, agreed by a named person on each side:

1. Deliverable, precisely. Not "the API" but "the bulk-export endpoint, deployed to staging, supporting CSV and JSON, handling 10k rows, with docs." The precision conversation itself surfaces mismatched assumptions — this is where you discover they were planning JSON only.
2. Date, singular. One date, agreed, written. "Mid-May" is not a date. If the upstream team can only commit to a range, take the late end of the range as the contract date and plan accordingly.
3. Definition of done, testable. How the downstream team verifies the deliverable: "our integration test suite passes against staging." This kills the most common failure — upstream says "done," downstream discovers it is 80 percent done, and the remaining 20 percent takes three weeks because upstream has mentally moved on.
4. Check-in cadence and channel. Where status updates happen and how often — weekly async update in a shared thread is usually right. Silence is the enemy; the contract makes silence a breach rather than the default.
5. Change protocol. What happens if either side's needs shift: who is notified, how much notice, who arbitrates if the two teams cannot resolve it. Naming the arbiter in advance — typically the manager both teams share, however many levels up — turns future escalation from a political act into an agreed procedure.

Keep contracts somewhere both teams actually look — a shared doc or a project status room, not a private notes file. And keep them lightweight: five fields, not a legal document. The moment contracts take longer to write than the check-ins they replace, they will be abandoned.

A realistic exchange when proposing one:

You: "Before we both plan around this — can we write down what 'ready' means and pick a real date? Five bullet points, so neither of us gets surprised in May." Platform lead: "It'll be ready when it's ready — we've got our own commitments." You: "That's exactly why I want the late-end date, not the optimistic one. If the honest answer is May 20, I'd rather plan buffers around May 20 now than find out on May 12."

Upstream teams almost never resist precision; they resist pressure. A contract that asks for their honest late date is pressure relief, and most teams sign on immediately.

Buffers: pricing the risk you cannot remove

Every dependency that crosses a team boundary carries schedule risk that contracting reduces but never eliminates. Buffers convert that risk from a surprise into a budget. Practical sizing rules:

• Internal dependencies: little or no buffer — your own standup catches slippage within a day.
• Cross-team, contracted, with weekly check-ins: 20–30 percent of the dependency's lead time. A deliverable promised in four weeks gets planned as arriving in five.
• External vendors and queues: 50–100 percent, calibrated by history. If legal review "takes two weeks" but took four the last twice, four is the number and the official two is folklore.
• Anything on the critical path: buffer at the top of its band, because there is no slack downstream to absorb what the buffer misses.

Two rules about buffer mechanics matter more than the percentages. First, buffers are visible, not smuggled. A hidden pad inside a task estimate gets consumed silently by ordinary work expansion; a visible buffer bar in front of a milestone can be watched, and its burn rate is your earliest warning signal. Second, a consumed buffer is information, not failure. Buffer half-gone with the dependency half-delivered is on plan. Buffer half-gone before the upstream team has started is your cue to escalate — this week, not at the deadline.

Soft dependencies get a different currency: instead of calendar buffer, budget rework. "We build against the mock now; history says integration fixes cost us two to four days; those days are in the plan" is a legitimate and often superior trade — you pay a known small cost to take a large uncertain one off the critical path.

Monitoring: catching the slip while it is cheap

A dependency's status has a short shelf life. The monitoring system is deliberately boring:

• The weekly dependency review — 10 minutes. Walk the dependency table in the project's weekly sync. For each open row: status per the agreed check-in, buffer remaining, any change to the needed-by date. Update last checked. Ten minutes, every week, no exceptions — the value is in the unbroken cadence, because a dependency that slips does so between the checks you skip.
• Watch leading indicators, not promises. "Still on track for May 12" is a lagging assurance. Leading indicators: has the upstream work actually started? Is it visible on their board? Did their sprint planning include it? A dependency due in two weeks that has not entered the upstream team's sprint is late now, whatever anyone says. It is entirely fair — and worth writing into the contract — to ask where you can see the work, not just hear about it.
• Make status public. A dependency table posted where both teams and both teams' managers can see it changes upstream behavior all by itself. Teams deprioritize invisible commitments; they honor visible ones. An async status room with standing questions ("any dependencies at risk this week?") does this structurally — the pattern we describe in status reports people actually read.

Escalation: a ladder, not an explosion

Escalation has a bad reputation because most people do it too late and too hot — silence for five weeks, then a furious email with three directors in CC. Done properly, escalation is a routine, pre-agreed mechanism with steps. The ladder:

1. Peer nudge (day 1 of concern). Owner to owner, in the contract's channel: "Check-in was quiet this week and the buffer's burning — what's the honest picture?" Most slips resolve here, because most slips are prioritization drift that the upstream lead can correct once aware.
2. Formal flag (roughly one buffer-third consumed). Written, in the shared channel, naming the impact: "If the endpoint lands after May 19, launch moves week-for-week. Can you confirm the date holds, or tell me the real one?" Not angry — precise. The goal is to force a true date into the open while options still exist.
3. Joint options meeting (buffer half gone, or date officially slipped). Thirty minutes, both leads, one shared agenda item: which option do we take? Reduce scope of the deliverable, lend downstream people upstream, accept a workaround, or move the date. Bring options, not blame — the meeting where someone must be found at fault produces defensiveness; the meeting that prices three options produces a decision.
4. Arbiter decision (options meeting deadlocks). The pre-named arbiter from the contract picks among the options, quickly. Because the arbiter was agreed in advance, invoking them is procedure, not politics — the difference between "we're following the process we all signed" and "I'm going over your head."

The cultural point leaders must repeat until it sticks: early escalation is a professional courtesy, not an aggression. A team that hears about a slip five weeks early can replan around it almost for free. The same slip disclosed five days early costs the full price. Whatever your process documents say, teams learn from what happens to the first person who escalates early — make sure what happens is "thank you."

The system in action: one dependency, end to end

Here is how the pieces combine on a single realistic case. A marketing team's product-launch project needs the platform team's bulk-export API — discovered as a hard, cross-team arrow in the kickoff workshop on March 3.

Week 1: Maya (the assigned owner on the marketing side) writes the contract with the platform lead. Precise deliverable: staging deployment, CSV and JSON, 10k rows, docs. The platform lead's honest range is "May 5 to May 20," so the contract says May 20. Launch needs it by June 2, so the plan carries a nine-working-day buffer. Definition of done: marketing's integration checks pass against staging. Cadence: Friday async update in the shared thread. Arbiter: the VP both teams report into.

Weeks 2–5: Friday updates arrive; the table's last checked column stays current. In week 4, Maya checks the leading indicator — the API work has entered the platform team's sprint. Green.

Week 6: The Friday update is silent. Rung one, Monday: "Quiet week — honest picture?" Answer: a production incident ate the sprint; the work is paused, new estimate May 27. Five buffer days gone before the deliverable is half built. That crosses the rung-two threshold, so Maya flags formally in the shared channel: "May 27 leaves four days of buffer for integration. If it moves again, launch moves. Can you confirm May 27 is the real date?"

Week 7: Platform confirms May 27 but flags JSON as at risk. Rung three — the 30-minute options meeting prices three choices: ship launch with CSV only (works for 90 percent of the use cases), lend a marketing engineer to platform for a week, or slip launch. Both leads pick CSV-only without needing the arbiter; JSON becomes a fast-follow contract with a new date.

June 2: Launch ships on time. Total management cost: one workshop hour, ten minutes a week, two short escalations, one meeting. The counterfactual — discovering the incident-induced slip in the last week of May — costs the launch date. That asymmetry is the entire business case for the system.

Reducing dependencies structurally

Everything above manages dependencies you have. The senior move is having fewer:

• Slice work vertically. Teams organized around layers (frontend team, backend team, database team) turn every feature into a three-team dependency chain. Cross-functional teams that own outcomes end-to-end convert those cross-team contracts into items on one backlog — an organizational choice with more schedule impact than any tracking system.
• Decouple with interfaces and flags. Agreeing an API contract up front converts a hard finish-to-finish dependency into two parallel workstreams plus an integration task. Feature flags let dependent code ship dark before its counterpart is ready. Every hard dependency softened this way is buffer you no longer need.
• Pool the queues. If every project waits on the same security review, design team, or release board, no per-project management fixes it — that is a shared-service capacity problem, and it belongs in portfolio conversations with data ("our last six projects each lost 2–4 weeks to this queue").
• Prefer boring inputs. Every novel vendor, new platform, and bespoke integration is a dependency with no history to calibrate buffers against. Sometimes novelty is the point; when it is not, the known-quantity option with the unglamorous track record is the faster plan.

Next steps

For a project in flight this week:

1. Run the 60-minute mapping workshop. Deliverables, arrows, classifications, one owner per external arrow. Expect two surprises; they are the payoff.
2. Build the dependency table with needed-by dates that already include buffers — 20–30 percent cross-team, 50–100 percent external.
3. Write contracts for your top three riskiest arrows. Five fields, ten minutes each, named people both sides, arbiter chosen in advance.
4. Install the 10-minute weekly review and track leading indicators, not promises.
5. Agree the escalation ladder out loud — especially the norm that early flags earn thanks.

If you want the system in one place instead of five, Openbook covers the full loop: map and compute the critical path in the Gantt room, track the dependency table in a Table Board, and run the weekly review through a Project Status room with standing questions — all in one space, free to start at openbook.work. The dependencies are coming either way; the only choice is whether you see them first.