A dependency between teams
A dependency is a relationship where one piece of work cannot proceed until another team or system delivers something first. It is the most expensive word in a plan. A single cross-team dependency can turn a two-week taskTaskProduct SpecificationA unit of work within a story or epicView reference → into a two-quarter negotiation, because the cost is rarely the work itself; it is the waiting, the queueing, and the coordination that piles up around the handoff.
Dependencies have been tracked in project schedules since the critical-path methods of the late 1950s, where a task'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 needNeedUserA user need, pain, desire, or constraintView reference → to wait on a person.
The thinking has since merged with flow metricsMetricStrategyA 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.
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 featureFeatureProduct SpecificationA product capability or featureView reference →, 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.
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 DependencyblocksTeamcross-domain and dependency_blocks_teamDependencydepends onTeamcross-domain, naming both ends of the handoff: who is waiting and who must deliver. The reciprocal dependency_depends_on_teamTeamdepends 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.team_depends_on_dependency
Type-specific fields on BaseNode
dependency_typestringNature of the dependency relationship
resolutionstringHow the dependency was or will be resolved
criticalitystringHow urgent the dependency is to resolve
target_datestringDate by which resolution is needed (ISO 8601)
workaround_availablebooleanWhether a workaround exists if the dependency is not resolved in time
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
4 phases — initial: identified
3 edge types connected to this entity.
team_depends_on_dependency1 framework use this entity type.