Team dependencies in software development are one of the least visible and most costly problems in growing organisations. At the start, everything works: teams are small, the codebase is manageable, and every developer knows enough of the system to move independently. But as the company scales, with more people, more teams and more features, dependencies between teams start to multiply.
The result is a progressive slowdown in delivery that has nothing to do with individual skill and everything to do with the structure of the organisation and the software. Features that used to take days start taking weeks. Releases pile up in coordination queues. Sync meetings multiply.
Yet almost nobody identifies dependencies between teams as the main cause. The problem gets blamed on product complexity, a lack of resources, or the need to hire more senior people.
These dependencies slow down delivery because they force teams to synchronise constantly, turning every feature into a multi-team project that needs explicit coordination, cross-team code review and orchestrated releases — overhead that grows exponentially with the number of teams involved.
How dependencies between software teams arise
Cross-team dependencies are rarely introduced on purpose. In most cases, they're the natural result of architectural decisions made when the organisation was smaller.
A monolith that worked perfectly with a five-person team becomes a bottleneck once three teams need to work on the same code. A shared database that looked like the simplest choice becomes a constant source of conflict once different teams start modifying the same tables. A central service handling cross-cutting business logic forces every team to coordinate before every release.
The pattern is always the same: decisions that were reasonable in the original context become structural constraints in the new organisational context.
This phenomenon is described by Conway's law, which holds that the structure of a piece of software tends to mirror the communication structure of the organisation that produces it. When the boundaries of the software don't match the boundaries of the teams, dependencies become inevitable.
Why dependencies slow down delivery
The software delivery slowdown caused by dependencies between teams isn't linear. At first it's barely noticeable — one extra meeting, a few days' wait for a code review — but as the organisation grows, the impact becomes exponential.
Every dependency introduces a coordination point. Every coordination point requires explicit communication, agreement on timing and managing priorities that cut across teams. The result is that actual development time — the time spent writing and testing code — makes up an ever-smaller fraction of total delivery time.
- Queues: a team has to wait for another team to finish a change before it can move forward
- Synchronised releases: several teams have to coordinate to release together because their changes are interdependent
- Cross-team code review: changes need sign-off from teams that own shared components
- Priority conflicts: team A needs a change from team B, but team B has other priorities
- Complex integration tests: every release requires end-to-end tests spanning components from several teams
Research from the DORA programme (DevOps Research and Assessment) shows that organisations with tightly coupled teams have significantly longer lead times than those with autonomous teams. The ability to release independently is one of the most reliable predictors of delivery performance.
The signs of a dependency problem
Dependencies between teams often go unrecognised as such. They show up as symptoms that get blamed on other causes.
The first sign is a rise in coordination time. When teams spend more time in sync meetings than on actual development, dependencies are probably eating into productive capacity.
Another sign is difficulty planning sprints. If a team's planning systematically depends on the priorities of other teams, the organisational boundaries don't match the boundaries of the software.
The most critical sign is when adding developers doesn't increase delivery speed. That indicates the bottleneck isn't development capacity but coordination capacity — and dependencies are almost always the cause.
Other concrete indicators include:
- Pull requests that sit open for days waiting on review from other teams
- Feature branches that drift significantly from main because multiple teams are editing the same areas
- Frequent rollbacks caused by conflicts between changes from different teams
- Recurring meetings whose only purpose is to coordinate releases between teams
The link between software architecture and team structure
The relationship between software architecture and team structure runs both ways. Architecture shapes how teams need to coordinate, and team structure shapes how the architecture evolves.
When an organisation grows and adds teams without rethinking the architecture, the new teams inherit the structural dependencies of the existing system. Every team working on a shared component has to coordinate with every other team that depends on it.
The concept of cognitive load, introduced in the book Team Topologies by Matthew Skelton and Manuel Pais, is central to this dynamic. Every team has a limited cognitive capacity. When dependencies force a team to understand and manage components it doesn't own, cognitive load goes up and productivity goes down.
The solution isn't simply to split the monolith into microservices. If service boundaries don't match team boundaries, microservices can actually make the problem worse, adding operational complexity without reducing organisational dependencies.
The right approach is to design the architecture around the teams, not the other way round. Each team should own a set of components with clear boundaries and well-defined interfaces. Our Embedded Teams service starts from exactly this premise: realigning architecture and organisation to give teams back their autonomy.
What to do in practice to reduce dependencies
Reducing team dependencies in an agile way means working on several levels at once: architecture, organisation and process. There's no single fix, just a set of practices that work together.
In the assessment we run at the start of every Embedded Teams engagement, cross-team dependencies turn out to be the primary cause of the slowdown almost every time — even when the team came to us for a different reason. A typical example: an organisation brought us in to "improve code quality". Within two weeks we found that the real problem was a database shared between three teams: every deployment needed coordination, every schema migration blocked everyone. Code quality was the symptom. The shared database was the cause.
The starting point is mapping the dependencies that already exist. That means identifying, for each team, which other teams it has to involve to complete a typical feature. The dependency map reveals the structural bottlenecks that don't show up in individual sprints.
The guiding principle is to maximise each team's autonomy by reducing the surface area of contact between teams.
Concrete actions include:
- Define clear ownership: every component of the system should have an owning team with full decision-making authority
- Introduce contracts between services: interfaces between components need to be explicit and stable, letting teams evolve their own services independently
- Eliminate shared databases: each team should own its own data and expose only well-defined APIs
- Reduce synchronised releases: invest in independent deploys and feature flags to decouple releases
- Align software boundaries with team boundaries: when a team has to modify another team's code to finish its own work, that's a sign the boundaries are wrong
This process doesn't happen overnight. It takes a deliberate, iterative investment. But the results are measurable: shorter lead times, higher deployment frequency and more predictable delivery.
To measure the impact of these dependencies on your organisation, you can use the Consistency Impact Calculator, which quantifies the economic cost of structural slowness.
The role of technical leadership
Reducing dependencies between teams isn't a job that can be delegated to individual teams. It requires organisation-wide vision and architectural decisions that cut across team boundaries.
The CTO or VP Engineering has to lead this process, creating the conditions for teams to operate autonomously. That means investing in internal platforms, setting architectural standards and protecting the time needed for structural refactoring.
Technical leadership also has to resist the temptation to fix the slowdown by hiring more people. If the problem is structural, adding developers without reducing dependencies makes things worse by increasing the coordination load.
Organisations that scale successfully are the ones that invest in the structure of the system before the slowdown becomes critical.
The alternative — stepping in once delivery is already compromised — is possible, but costlier and riskier. A Targeted Intervention can unblock the situation, but prevention remains the more effective approach.