Every feature needs coordination across three teams.No one can ship independently
Cross-team dependencies are the invisible brake on delivery. The more teams you have, the slower you get — because coordination grows exponentially.
Signs you'll recognise
If more than one sounds familiar, it isn't a coincidence — it's a pattern.
The problem isn't communication between teams — it's the architecture that forces them to communicate too much.
Why it happens
Conway's law explains it: software architecture mirrors organisational structure. When module boundaries don't match team boundaries, dependencies are inevitable.
A tightly coupled, monolithic architecture forces multiple teams to work on the same codebase, generating conflicts, waiting and coordination.
The solution is the reverse Conway manoeuvre: redesigning the architecture's boundaries to align with the teams, giving each one a clear, independent area of responsibility.
It's not just an architectural change — it's an organisational one. Teams, ownership and processes all need to evolve together.
How we step in
We work inside your organisation, not from the outside. Change happens in the code and in the teams.
Mapping the dependencies
We analyse the real dependencies between teams and modules, identifying where coordination can be avoided and where it is structural.
Redesigning the boundaries
We redesign the boundaries between modules and teams to maximise autonomy. Each team owns an area of the system end to end.
Interfaces and contracts
We define clear interfaces between modules. Teams communicate through APIs and contracts, not shared code.
Lightweight governance
We introduce minimal processes to manage the few remaining dependencies: a tech radar, communities of practice, architecture decision records.
What changes afterwards
Autonomous teams
Each team can ship its own area without waiting on other teams.
Reduced lead time
Features pass through one team, not three. Cycle time drops dramatically.
Organisational scalability
Adding a team speeds up delivery instead of slowing it down.
Less coordination
Sync meetings shrink. The time freed up goes back into development.
Do you recognise these signs in your organisation?
How we can help
The services we use to tackle this kind of problem.
Related problems
These warning signs tend to show up together. Explore the related topics.
Further reading in Learn
Articles by our team that look closely at the issues behind this challenge
Team Topologies for people running a software company
Team Topologies principles translated into concrete decisions for CEOs and CTOs. How team structure determines the speed of your software, and what to do when groups start blocking each other.
Team dependencies in software development: the real bottleneck
In software scale-ups, delivery slowdown rarely comes down to how talented the teams are. More often, the real bottleneck is the dependencies between teams, which multiply as the organisation grows.
Cost of change in software development: why it keeps growing
As software grows, changing the product gets harder and harder. The cost of change is one of the clearest signs that architecture, organisation and delivery have stopped evolving together.
Tell us where you're stuck
A fragile prototype, a burdensome legacy codebase or unpredictable delivery: that's where we start