Why Team Dependencies Are Killing Your Engineering Velocity

The Silent Tax on Your Engineering Organization

Your teams are staffed with talented engineers. Your roadmap is clear. Your tooling is modern. And yet, quarter after quarter, delivery timelines slip. Features that should take weeks stretch into months. The culprit is rarely a lack of skill or effort — it is the invisible web of cross-team dependencies that silently devours your engineering velocity.

If you are a CTO, VP of Engineering, or engineering manager, you have felt this pain. A team is blocked waiting on an API from another team. A shared service change requires coordinating three squads across two time zones. A "simple" feature touches five repositories owned by four different groups. Each dependency is a queue. Each queue is a delay. And the delays compound in ways that are devastatingly non-linear.

The Math Is Brutal: Brooks's Law and Beyond

In 1975, Fred Brooks observed that "adding manpower to a late software project makes it later." The reason is coordination overhead. In a team of n people, the number of communication channels grows as n(n−1)/2. Double the team from 5 to 10, and you go from 10 channels to 45 — a 4.5x increase in coordination pathways.

Now extend that logic across teams. Research consistently shows that cross-team coordination costs can consume 20 to 40 percent of total engineering time in large organizations. Studies of developer experience have found that engineers in organizations with high cross-team dependencies report spending less than 30% of their time on actual coding, with the rest lost to waiting, meetings, and context-switching.

The numbers get worse at scale. An organization with 10 interdependent teams does not have 10 times the coordination cost of a single team — it has closer to 45 times, following the same combinatorial explosion Brooks described. This is why companies that double their engineering headcount rarely see anything close to double the output.

How Dependencies Create Bottlenecks

Dependencies between teams create bottlenecks through several reinforcing mechanisms:

• Queueing delays: When Team A needs something from Team B, that request enters Team B's backlog. Team B has its own priorities. The average wait time in enterprise organizations is 2 to 4 weeks per dependency — and features often have multiple dependencies in sequence, not in parallel.
• Priority conflicts: Team B's top priority is never the same as Team A's. Work that is critical for one team is "nice to have" for the team that must deliver it. This misalignment is structural, not personal, and no amount of "better communication" will fix it.
• Batch size inflation: To reduce the overhead of cross-team coordination, teams naturally batch requests. Batching means larger changesets, longer review cycles, more risk per deployment, and slower feedback loops — the exact opposite of what agile delivery demands.
• Hidden coupling: Dependencies often reveal tight technical coupling between systems. A change in one service unexpectedly breaks another. Integration testing becomes a coordination nightmare. Deployment windows shrink because nobody is confident about the blast radius.
• Cognitive load explosion: Engineers forced to work across team boundaries must hold mental models of systems they do not own. As Matthew Skelton and Manuel Pais argue in Team Topologies, when a team's cognitive load exceeds its capacity, quality and speed both collapse.

Real-World Impact: What This Looks Like in Practice

Consider a mid-size fintech company with 120 engineers organized into 15 teams. They want to launch a new payment flow. The feature requires changes to the API gateway (Platform team), the payment processing service (Payments team), the fraud detection system (Risk team), the customer notification service (Comms team), and the front-end application (Product team). That is five teams that must coordinate to ship a single feature.

Each hand-off introduces a minimum two-week delay. The critical path through these dependencies is at least six weeks of wait time — even if the actual coding work for each team is only a few days. The feature that "should" take three weeks takes three months. Leadership sees the timeline and assumes the teams are slow. The teams know they are not slow — they are stuck.

This pattern repeats across the industry. Spotify famously struggled with cross-squad dependencies even within their celebrated squad model, leading them to invest heavily in platform capabilities that reduced coupling. Google's internal research has identified cross-team dependencies as one of the largest predictors of project delays, outweighing technical complexity, unclear requirements, and staffing gaps.

The Team Topologies Perspective

Skelton and Pais offer a powerful framework for thinking about this problem. Their core insight is that team boundaries should be deliberately designed to minimize dependencies, not drawn around existing org charts or technology stacks. They propose four fundamental team types — stream-aligned, enabling, complicated subsystem, and platform — each with clear interaction modes: collaboration, X-as-a-Service, and facilitating.

The key principle is that most interactions between teams should be X-as-a-Service: one team provides a well-defined capability that others consume through a clean interface, with no ongoing coordination required. When every feature requires real-time collaboration between multiple teams, it is a sign that your team boundaries are drawn in the wrong place.

This connects directly to Conway's Law — the observation that organizations design systems that mirror their communication structures. If your teams are tangled, your architecture will be tangled. If your architecture is tangled, your teams will be forced into constant, expensive coordination. Breaking this cycle requires intentional redesign of both.

The Cognitive Load Connection

Every dependency a team carries increases its cognitive load. Engineers must understand not just their own domain, but the interfaces, release schedules, and quirks of every team they depend on. Research in cognitive psychology suggests that humans can effectively hold about four to five complex mental models at once. When a team depends on six other teams, each with its own service contracts, deployment cadences, and communication norms, the cognitive overhead alone is enough to slow delivery to a crawl.

High cognitive load leads to mistakes. Mistakes lead to incidents. Incidents lead to more process, more review gates, and more coordination overhead. It is a vicious cycle that no hiring spree can solve — because adding people only adds more communication channels to an already overloaded system.

Making Dependencies Visible: The First Step

You cannot reduce what you cannot see. Most organizations have no clear picture of their dependency landscape. Dependencies live in tribal knowledge, in Slack threads, in the frustrated sighs of engineers waiting on pull request reviews from other teams. Making dependencies visible is the essential first step toward reducing them. When you map out which teams depend on which other teams — and for what — patterns emerge immediately. You see the bottleneck teams that every other team is waiting on. You see the features that require five teams when they should require one. You see where your team boundaries are fighting your architecture instead of reinforcing it. Visibility transforms dependencies from a vague, chronic pain into a concrete, actionable problem. And concrete problems can be solved — by redesigning team boundaries, investing in platform capabilities, decoupling architectures, or restructuring ownership. But it all starts with seeing the web clearly.