The Dependency Tax
Every dependency between teams is a tax on delivery speed. When Team A needs something from Team B before they can proceed, Team A waits. The waiting time is rarely zero. It is usually days, sometimes weeks. The larger the organisation, the more dependencies, and the higher the cumulative tax.
This tax is real but largely invisible. It does not appear in velocity metrics. It does not show up in sprint reports. It shows up as "blocked" tickets that sit for days before anyone notices, and as commitments that slip because the blocking team had different priorities.
Most engineering organisations have no systematic view of their dependency landscape. They manage dependencies reactively - when a team hits a dependency problem, they escalate, negotiate, and eventually unblock it. The cycle repeats indefinitely because the root causes are never addressed.
Types of Dependencies
Understanding dependency types matters because the mitigation strategies differ.
Technical Dependencies
A technical dependency exists when Team A's code directly depends on infrastructure, APIs, or libraries owned by Team B. Team A cannot ship without Team B's component being in a working state.
Technical dependencies are often structural - they reflect architectural decisions that cannot be changed quickly. But they are frequently accidental too, the product of organic growth rather than deliberate design. A monolith with shared database tables between team boundaries creates technical dependencies that did not need to exist.
Team Dependencies
A team dependency exists when Team A needs Team B to take an action - review code, provide access, create a configuration, respond to a support request - before work can proceed. The dependency is on human attention rather than technical capability.
Team dependencies are often the most frustrating because they feel solvable in principle but require coordination that is expensive in practice. The other team has their own priorities. Their queue is full. Your request is important to you but not to them.
Organisational Dependencies
An organisational dependency exists when progress requires a decision, approval, or sign-off from a person or body with authority over both teams. Architecture review boards, security approval gates, change advisory boards - these create dependencies on process and authority rather than on other teams' output.
Organisational dependencies are often the hardest to address because they are frequently backed by governance requirements. Challenging them requires engaging with risk appetite and regulatory context, not just engineering design.
Mapping Your Dependencies
You cannot manage what you cannot see. The first step is to make dependencies visible across your teams.
Dependency Mapping Sessions
Bring together tech leads or senior engineers from adjacent teams. For each upcoming significant piece of work, ask: what do we need from other teams? What do other teams need from us? Map the answers explicitly.
This is not a one-time exercise. Run it quarterly as part of planning, and as a precursor to any significant programme of work. The map will be wrong - it will miss some dependencies and overstate others - but having a wrong map is better than having no map.
Board-Level Visibility
If your teams use planning boards, make cross-team dependencies visible on those boards. A blocked ticket should show what team it is waiting on. A ticket that is depended on by another team should show that dependency. When this information is on the board, it becomes part of the conversation in ceremonies rather than invisible background noise.
Asking the Right Questions
In planning conversations, the questions to ask are: what could stop this work from completing in the sprint? What do we need from teams we do not control? What have we committed to providing to other teams this sprint?
These questions surface dependencies before they become blockers rather than after.
The Cost of Dependencies in Cycle Time Terms
Dependencies do not just create waiting time for individual items. They create system-level effects that compound across a programme of work.
When two teams have a dependency, the team that depends on the other cannot complete their work until the supplying team delivers. If the supplying team is two weeks behind due to their own priorities and blockers, the dependent team is also two weeks behind - at minimum. In practice, the delay is usually longer because the dependent team has moved on to other work while waiting and now needs to context-switch back.
Across a large organisation with dozens of teams and hundreds of inter-team dependencies, the cumulative impact is enormous. Research in lean manufacturing and software delivery consistently finds that waiting time accounts for 60-80% of total cycle time. Most of that waiting is dependency-driven.
The implication: addressing dependencies is often more valuable than improving team-level efficiency. A team that delivers 20% faster but is blocked for two weeks waiting on a dependency has achieved nothing net.
Architectural Patterns That Reduce Dependencies
Many technical dependencies can be reduced or eliminated through deliberate architectural choices.
Team Topologies and Bounded Contexts
When teams are aligned to bounded contexts - clearly defined domains of the business with explicit boundaries and APIs between them - technical dependencies are limited to those interfaces. Teams can work within their domain without coordinating on internal implementation.
This alignment does not happen automatically. It requires deliberate design: defining domain boundaries, assigning team ownership clearly, and investing in the API layer between domains so it is stable and fit for purpose.
Asynchronous Integration
When Team A calls Team B's API synchronously in production, a technical dependency exists at the service level. When the integration is asynchronous - events, queues, messaging - teams decouple their deployment and operational concerns. One team can change their implementation without requiring coordination with the other.
Asynchronous patterns introduce their own complexity, but they substantially reduce the coupling between teams in ways that pay off at scale.
Internal Platforms
A platform team that provides shared infrastructure as a self-service capability removes the team dependency of waiting for an infrastructure team to action a request. When teams can provision their own environments, deploy to shared infrastructure, and access monitoring without raising tickets, a whole class of team dependencies is eliminated.
Platform investment is frequently underfunded relative to its return on the dependency reduction it creates.
Dependency Boards and Planning at Scale
At programme level - multiple teams working toward a shared goal - dependencies need management above the individual team level.
Programme Boards
A programme board maps the work across teams and makes cross-team dependencies explicit. Each team's planned items for a period are laid out side by side, and dependency lines are drawn between items that must be sequenced or coordinated.
Programme boards are used in frameworks like SAFe for this reason, though you do not need to adopt SAFe wholesale to benefit from a shared view of cross-team dependencies.
Dependency Owners
Every cross-team dependency should have a named owner - typically on the supplying team - who is accountable for communicating status and raising issues early. Ownerless dependencies are the ones that quietly slip.
Lead Time Buffers
When planning work that depends on another team's output, build in explicit buffer. If Team B says something will be ready in three weeks, plan Team A's dependent work for week five, not week four. Dependencies are frequently delayed, and planning for perfect execution across team boundaries is a reliable way to guarantee slippage.
Having the Conversation With Stakeholders
Dependencies are often invisible to stakeholders. Commitments are made at programme level without any accounting for the dependencies required to fulfil them.
The engineering leader's job is to make the dependency landscape visible to stakeholders in terms they can act on. This means:
Translating dependency risk into schedule risk. If three of our deliverables depend on Team B, and Team B is already at capacity, then those deliverables are at risk. Say that explicitly.
Proposing concrete choices. Stakeholders cannot reduce dependencies directly, but they can influence priorities and resourcing. Present options: we can de-scope Team B's other work, we can hire to give them capacity, or we can push our dependent deliverables later.
Tracking dependency resolution as a programme-level metric. If your programme's percentage of unresolved dependencies is tracked and reported at the same level as scope and schedule, it gets the attention it deserves.
Dependencies are an engineering problem that requires business-level conversations to solve. Engineering leaders who limit the conversation to the engineering level leave the most powerful levers untouched.