Communication between Teams is a Bug, Not a Feature

Every meeting, channel, and email thread comes with hidden costs: context switching, information overload, and delayed decision-making. Adding more communication treats the symptom, not the disease, and further slows delivery by distracting teams from their core work.

The Problem with Team Dependencies

When teams depend on others to achieve their goals, accountability breaks down. "We couldn't ship because Team X hasn't finished their API" becomes "I did my job" – creating a web of excuses that makes it impossible to hold anyone truly accountable for outcomes.

In the example above, teams are aligned by functional specialization: frontend, backend, and marketing. No single team can deliver a feature independently. Instead of solving problems autonomously, they rely on constant coordination, introducing delays and points of failure. This level of coordination signals that work is too interdependent. Rather than optimizing for more communication, we should eliminate the need for it through better team design.

The Goal: Autonomous, Accountable Teams

To truly empower teams they need to have the relevant cross-functional skills to bring an idea all the way to production. The vision is for each team to have zero blocking dependencies from idea to satisfied customers but this is really difficult to do in practice. There are some good strategies, borrowed from Domain Driven Design, to identify logical boundaries in your product where work can be done independently.

But the real world rarely allows for perfectly independent teams. Even with careful boundaries around user journeys and right-sized services, teams still need to share data, infrastructure, and platforms. The challenge isn't eliminating all dependencies because this isn’t possible – it's about eliminating the blocking ones.

Communication is a Scaling Bottleneck

More meetings, more check-ins, and more coordination might feel productive, but they create an exponential drag on execution:

• Teams struggle with cognitive overload from tracking external dependencies

• Decision-making slows as more people get involved

• Execution stalls as teams wait on each other

The best way to scale isn’t to improve communication - it’s to reduce the need for it.

Team Topologies: The Blueprint for Minimizing Communication

Matthew Skelton and Manuel Pais wrote a fantastic book, Team Topologies, focused on the challenges of team coordination. As organizations scale, inter-team communication becomes a bottleneck. The more teams need to coordinate, the slower and more expensive execution becomes.

In the book, they identified three fundamental collaboration patterns between teams:

1. Collaboration: Traditional cross-team coordination with meetings and tight alignment.

2. X-as-a-Service: Teams provide APIs or platforms that enable other teams to self-serve.

3. Facilitating: A coaching model where one team helps upskill another.

As organizations scale, they should prioritize X-as-a-Service interactions, enabling teams to work independently through well-defined interfaces.

Maintaining Product Coherence

When multiple teams work separately, there’s a risk of creating a disjointed, Frankenstein-like product. Duplication of work, conflicting decisions, and a lack of shared vision can emerge. However, relying on more communication isn’t the solution - it’s an abdication of product leadership’s responsibility.

There are multiple ways that organisations can ensure consistency across Stream Teams:

1. Product teams must define the vision, strategy, and objectives for Stream Teams.

2. Product Managers should follow a "certify, don’t brief" approach - engaging with teams to surface misalignments rather than micromanaging.

3. Platform products: Providing reusable capabilities for Stream Teams, but carefully balancing flexibility to avoid stifling innovation.

4. Design systems: Ensuring consistency in user experience across teams.

Individual Stream Teams don’t need to know what every other team is doing. Not only is it unnecessary, it actively harms productivity. Each Stream Team should focus solely on its value stream.

Coordinating Cross-Team Changes

Some changes genuinely do require multiple teams such as new regulations or major initiatives. But even then, the goal should be to preserve as much team independence as possible:

1. When the solution is clear (e.g. regulation): Teams can agree on interfaces upfront and work independently. They lose autonomy in deciding what to work on but retain execution independence.

2. When the solution is uncertain (e.g. new initiative): We don’t want to fall into the old trap of the Big Design Up Front, so we should continue the continuous research, design and development approach. This means temporarily merging two or more Stream Teams into a larger project team. This should be used as a last resort because it’s slow, expensive, and disempowers teams, but sometimes necessary.

Frequent reliance on cross-team projects can indicate deeper problems: mistrust in teams, a reliance on top-down planning, or incorrect team boundaries. If cross-team projects become the norm, it’s a sign the team structure itself needs to be reworked.

Conclusion: Rethinking Communication as a Systemic Issue

Communication isn’t a feature - it’s a symptom of a broken system. The best organizations minimize the need for inter-team coordination by designing teams that can operate autonomously.

If you need excessive meetings to get software delivered, the problem isn’t communication, it’s team structure. Fix the structure, and communication needs will shrink naturally.