Overview
Based on "Making Work Visible" by Dominica DeGrandis. Hidden dependencies are one of the five time thieves that kill delivery flow. The key insight: dependencies only become visible when you explicitly surface them as work items - not as footnotes in a ticket or assumptions in a plan. A dependency map exposes which teams are waiting on which, so you can sequence work and eliminate the invisible queue.
Workflow
Step 1: Gather the delivery inventory
Ask the user to list all active workstreams, epics, or initiatives currently in flight. For each item, capture:
- Name of the workstream
- Owning team
- Current status (not started / in progress / blocked / done)
- Target completion date
If the user provides a list, extract these fields. If they give a narrative, parse it into this structure before continuing.
Step 2: Identify the dependency type for each workstream
For each workstream, ask: "What does this need from outside the team before it can proceed?" Classify each dependency:
| Type | Definition | Example |
|---|
| Sequential | Team B cannot start until Team A finishes | API contract from backend before frontend builds |
| Shared resource | Both teams need the same person, system, or service | One DBA serving three teams |
| External | Waiting on a vendor, third party, or regulatory approval | Payment provider certification |
| Knowledge | Depends on expertise that lives in one person | Only one engineer knows the legacy auth system |
Step 3: Build the dependency matrix
Create a table:
| Workstream | Needs From | Type | Status | Due Date | Risk |
|-----------|-----------|------|--------|----------|------|
| [Team A: Feature X] | [Team B: API v2] | Sequential | Blocked | [date] | HIGH |
| [Team C: Migration] | [DBA: schema review] | Shared resource | Waiting | [date] | MED |
Rate risk as:
- HIGH: dependency is on the critical path, already delayed, or owned by a single person
- MED: dependency exists but has a known resolution path
- LOW: dependency is confirmed and on track
Step 4: Identify the critical path blockers
From the matrix, surface the top 3 dependencies that, if unresolved, will delay the overall program. For each:
- Name the owner responsible for resolving it
- State the specific action needed (not "coordinate with Team B" - "Team B needs to deliver API contract by [date]")
- Assign a resolution date
Step 5: Generate the dependency map output
Produce two artifacts:
Artifact 1: Dependency Summary Table (paste into Confluence, Notion, or Jira)
DEPENDENCY MAP - [your program] - [date]
========================================
HIGH RISK (resolve this week)
- [Workstream X] is blocked by [Team Y / deliverable Z] - Owner: [name] - Due: [date]
MEDIUM RISK (monitor weekly)
- [Workstream A] waiting on [shared resource B] - Owner: [name] - Due: [date]
RESOLVED / ON TRACK
- [Workstream C] dependency confirmed with [Team D] - no action needed
Artifact 2: Mermaid dependency diagram (paste into Markdown or Notion)
graph LR
A[Team A: Feature X] -->|needs API v2| B[Team B: Backend]
C[Team C: Migration] -->|needs schema review| D[DBA]
B -->|delivers| E[Integration complete]
Adapt the diagram to the user's actual workstreams. Use -->| label | syntax to name each dependency.
Step 6: Recommend resolution actions
For each HIGH risk dependency, recommend one of:
- Negotiate an earlier delivery date with the upstream team
- Create a stub or mock so downstream work can proceed in parallel
- Re-sequence - move the dependent work out of the current cycle
- Escalate - surface to leadership if the dependency is outside the team's control
Anti-Patterns
1. Tracking dependencies as ticket comments
Bad: "We need API from backend" buried in a Jira comment.
Good: A standalone dependency row in the matrix with an owner, due date, and risk rating.
2. Mapping every dependency including obvious ones
Bad: 40-row matrix including "frontend needs design mockups" for every ticket.
Good: Map program-level and cross-team dependencies only. Intra-team sequencing belongs in sprint planning.
3. No owner on the resolution
Bad: "Team A is blocked by Team B" with no named resolution owner.
Good: "[Name] from Team B will deliver [artifact] by [date]. [Name] from Team A is accountable for following up."
4. Building the map and never updating it
Bad: One-time dependency audit done at program kickoff, never revisited.
Good: Dependency map is a living artifact - reviewed in weekly program sync, statuses updated each cycle.
5. Treating all dependencies as fixed
Bad: "We can't start Feature X until Team B finishes."
Good: Ask first - can Feature X start with a stub? Can the API contract be agreed before the full implementation is done?
Quality Checklist