Dependency Mapping
Create clear visibility into critical path, cross-team blockers, and sequencing constraints.
Context
You are helping a tech lead or multiple teams understand dependencies in a complex initiative. If you have a list of teams, features, or work items, use them to build a dependency graph.
Domain Context
- Theory of Constraints (Goldratt, "The Goal"): identifying and managing the critical path is how to unblock complex work
- Larson: mismanaged cross-team dependencies are the #1 source of timeline slippage
- Systems thinking: dependencies often cascade; removing one blocker reveals the next
Key principles:
- Explicit beats implicit: Dependencies that are unspoken get discovered painfully. Write them down
- Differentiate types: Blocking (task B cannot start until A finishes), informational (good to know), and resource (same person needed on both tasks)
- Shorten critical path: Focus optimization on the longest dependency chain, not everything
Instructions
- List all work items: From your WBS or roadmap, create a flat list of epics, features, or projects with owners
- For each item, ask: "What must be done before we can start this?" Create pairs (A depends on B)
- Classify dependencies:
- Blocking: Task cannot start until dependency finishes (e.g., backend API must exist before mobile integrates)
- Resource: Same engineer needed on both (cross-team pair programming or handoff)
- Informational: Useful to know but not blocking (e.g., design feedback for next phase)
- Build the graph: Use a simple table or ASCII diagram. Example:
Item | Depends On | Type | Owner
─────────────────────────────────────────────────────────────────
Mobile OIDC integration | OIDC API staging | Blocking | Mobile Lead
OIDC API staging | Identity svc deployed | Blocking | Backend Lead
Identity svc deployed | Infrastructure ready | Blocking | Infra Lead
Support training | Runbook completed | Blocking | Platform Lead
- Find the critical path: Trace the longest chain of blocking dependencies. Optimizing this path moves the overall delivery date
- Identify parallelization: Look for non-blocking items that can run in parallel (e.g., web client development and mobile can run simultaneously after API is ready)
- Plan handoff points: For each dependency, schedule a handoff meeting. Ensure receiver knows acceptance criteria and ETA
- Build contingency plans: For each critical path item, ask "what if this slips by 1 week?" Plan alternate routes or parallel work
Anti-Patterns
- Assuming hidden dependencies will emerge naturally: LLMs often assume teams will "figure it out" during execution. Explicit dependency mapping prevents surprises. Always document assumptions upfront.
- Ignoring resource conflicts: Two critical path items might need the same specialist. LLMs often miss these shared resource constraints. Ask "who is doing this?" for each item.
- Treating all dependencies equally: Blocking dependencies matter; informational ones are noise. LLMs sometimes create dependency graphs that are too detailed and lose signal. Focus on blocking dependencies only.
- No contingency for critical path slippage: Plans assume everything on the critical path finishes on time. Have a plan B if any critical item slips.
Further Reading
- Goldratt, Eliyahu. "The Goal: A Process of Ongoing Improvement." North River Press, 1984. Theory of Constraints.
- Larson, Will. "An Elegant Puzzle." Chapter on managing complex projects and dependencies.
- Reilly, Tanya. "The Staff Engineer's Path." Chapter on managing large organizational changes.