Dependency

Origin & evolution

Dependencies have been tracked in project schedules since the critical-path methods of the late 1950s, where a task☑️TaskProduct SpecificationA unit of work within a story or epicView reference →'s start date hangs on its predecessor finishing. That framing treats a dependency as a sequencing fact to be drawn on a chart. It says when work can start; it says nothing about the organisational cost of the handoff.

The sharper modern treatment comes from Matthew Skelton and Manuel Pais in Team Topologies (2019). Their argument is that fast flow of change depends on teams that can deliver value without constant handoffs to other teams. Cross-team dependencies are the principal thing that slows delivery, because each one adds a queue and a communication channel. They tie this to cognitive load: a team that owns too many domains, or waits on too many others, cannot hold its work in its head well enough to move quickly. Their recommended team types (stream-aligned, platform, enabling, complicated-subsystem) exist largely to convert blocking dependencies into self-service ones, where a platform team's product removes the need🫀NeedUserA user need, pain, desire, or constraintView reference → to wait on a person.

An earlier strand of the same argument appears in Craig Larman and Bas Vodde's work on Large-Scale Scrum. Their central claim is that component teams — organised around technical layers rather than end-to-end features⭐FeatureProduct SpecificationA product capability or featureView reference → — structurally manufacture cross-team dependencies: every user-facing change touches multiple layers, so each team must wait on the others. Feature teams, by contrast, own a vertical slice of the product and can deliver without a ticket queue to another group. By that reading, a high dependency count is not bad luck or poor planning; it is a direct readout of how the organisation chose to divide work. The implication for dependency management is structural: reducing dependencies requires changing team boundaries, not just tracking handoffs more carefully.

The thinking has since merged with flow metrics🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference →. Teams now measure dependency the way they measure a bottleneck: by how long work sits blocked. The live question is which dependencies to remove (by giving a team ownership) and which to make self-serve (by building a platform), since not every dependency can or should be dissolved.

How it works in practice

A payments squad needs a new field exposed by the identity team's service to ship a fraud check. They file the request; the identity team is mid-quarter and slots it three weeks out. The fraud feature, two days of actual work, now has a three-week lead time, and the payments team idles or context-switches while waiting. Reading this through Team Topologies, the organisation sees the pattern repeat across five squads all waiting on identity. The fix is structural: the identity team ships a self-service schema extension that stream-aligned teams can use without a ticket. The dependency does not vanish, but it stops being a queue, and the next fraud feature ships in two days instead of three weeks.

Dependency vs. its neighbours

• Constraint🔒ConstraintStrategyA limit, requirement, or ceiling the product must respect, whether a self-imposed principle or an externally imposed boundaryView reference → is a fixed limit in the system itself, such as a rate cap or a budget. A dependency is a relationship of waiting on someone else. A chronic dependency can become a team's binding constraint, but a constraint needs no second party; it is a property, not a handoff.
• Risk🎲RiskComplianceA risk to the product or businessView reference → is an uncertain future event with a probability. A dependency is a known, present reliance. The dependency is near-certain to exist; the risk is that it slips. Teams often log the dependency and forget to log the slip risk that rides on it.
• Milestone⛳MilestoneProgram ManagementA key date or achievementView reference → is a fixed point in time the work is aiming at. A dependency is the upstream delivery that point may hang on. A milestone slips precisely when a dependency feeding it slips, which is why milestone planning that ignores cross-team dependencies tends to be fiction.

In the graph

In the Unified Product Graph, a dependency lives in the team and organisation region, where the relationships between teams are the structure that matters. It connects through dependency_blocks_teamDependencyblocksTeamcross-domain and dependency_depends_on_teamDependencydepends onTeamcross-domain, naming both ends of the handoff: who is waiting and who must deliver. The reciprocal team_depends_on_dependencyTeamdepends onDependencyhierarchy lets a team surface its full set of external reliances in one query. Modelling dependencies as nodes with explicit team edges, where a Gantt chart leaves them as arrows, makes the Team Topologies question answerable directly: which team is blocking the most others, and is that load a candidate for a platform that removes the wait.