In 2017, I ran a network infrastructure rollout that required coordination across four internal teams: field technicians, provisioning, the NOC, and our billing systems group. Each team performed well in isolation. Sprint velocity looked healthy. Individual ticket resolution times were strong. But the project ran six weeks late because nobody tracked the spaces between the teams. Field completed installs sat in a queue for provisioning. Provisioning finished configs that billing couldn’t process because of a schema mismatch nobody surfaced until week eight. Every team hit their numbers. The project missed its deadline.
That experience changed how I think about operational throughput. The work inside each team is rarely the problem. The gaps between teams are.
The 75% Problem
A Harvard Business Review study of 95 teams across 25 leading corporations found that 75% of cross-functional teams are dysfunctional. Researcher Behnam Tabrizi evaluated teams against five criteria: budget adherence, schedule adherence, specification compliance, customer expectations, and alignment with company goals. Three out of four failed on at least three of those measures.
The cause wasn’t talent. It was structural: unclear governance, unspecified accountability, goals too vague to coordinate against, and organizations that treated cross-team work as something that would “just happen.”
Gartner’s 2024 survey reinforced this. 84% of leaders report experiencing high “collaboration drag” from cross-functional work: too many meetings, too much feedback from too many people, and unclear decision rights. Organizations with high collaboration drag are 37% less likely to hit revenue goals.
These numbers describe most mid-sized operations. If your team’s output depends on input from another team, you have a dependency. If you haven’t mapped it, you’re carrying risk you can’t see.
Three Types of Dependencies Your Team Carries
Not all dependencies look the same. The framework that changed my operational thinking breaks them into three categories.
Knowledge dependencies exist when your team can’t proceed without information held by another group. A product launch stalls because the legal review hasn’t been communicated back. A process change fails because the team executing it never received the context behind the change. These dependencies hide in email threads and undocumented tribal knowledge. If your team frequently stalls waiting for answers rather than deliverables, you have a knowledge dependency problem, and better process documentation is usually the first fix.
Task dependencies exist when one team’s output is another team’s input. This is the classic handoff problem: development finishes a feature, QA can’t test it until staging is deployed, and staging deployment requires an infrastructure team that’s in a different sprint cycle. Asana’s Anatomy of Work research found that knowledge workers spend 58% of their time on coordination activities rather than the skilled work they were hired for. Task dependencies are the primary driver.
Resource dependencies exist when multiple teams compete for the same constrained resource: a shared database administrator, a single test environment, a compliance officer who reviews every release. These are the most invisible because they look like individual workload problems until you map the demand patterns.
Most managers can name their task dependencies because those produce visible queues. Knowledge and resource dependencies tend to stay hidden until they cause a failure.
Mapping What’s Between the Teams
The most practical tool I’ve used is simple enough to sketch on a whiteboard: a dependency matrix.
List every team your group works with across the top of a grid. Down the left side, list your team’s key outputs and recurring deliverables. For each intersection, mark whether the dependency is an input (you need something from them), an output (they need something from you), or shared (both directions).
Then add one critical dimension: frequency. A dependency that fires once per quarter is manageable through project planning. A dependency that fires daily or weekly is an operational chokepoint that needs structural attention.
When I started using this approach during fractional COO work with a 40-person product organization, the matrix surfaced 14 active dependencies across three teams. Only five had any coordination mechanism in place. The other nine were being managed through informal Slack messages and hoping for the best.
The DORA research program at Google has studied this pattern extensively. Their findings are consistent: teams working in loosely coupled architectures with fewer cross-team dependencies ship faster, recover from incidents faster, and report higher job satisfaction. Tightly coupled teams with heavy dependencies see little benefit from process improvements because the bottleneck isn’t inside the team.
Reducing the Dependency Load
Once the map exists, three strategies actually work.
Internalize the most painful dependency. If your team depends on a shared UX designer for every feature release, make the case to embed a designer on your team. If provisioning always waits on a single infrastructure engineer’s approval, train a second person or push for a self-service tooling investment. The highest frequency, highest friction dependency on your matrix is the one to attack first. McKinsey’s research on team-focused organizational transformations shows that restructuring around outcomes rather than functions can yield 30% efficiency gains, largely because it internalizes the dependencies that slow teams down.
This is also a work intake decision. Every dependency you internalize adds to your team’s scope. Make sure the tradeoff is worth it by validating the frequency and cost of the dependency before absorbing the work.
Create interface agreements. For dependencies you can’t eliminate, define the handoff explicitly. What format does the input need to arrive in? What’s the turnaround commitment? Who owns escalation when the commitment is missed? I use the term “interface agreement” rather than “SLA” because it emphasizes that both teams negotiate the terms. A one-sided SLA breeds resentment. A mutual agreement builds operational trust.
These don’t need to be formal documents. A shared checklist in your project management tool, reviewed monthly, is enough. The point is making the implicit explicit.
Synchronize planning cycles. Many dependency failures happen because teams plan in isolation. Your team commits to a Q3 deliverable that requires input from a team still planning their Q3 priorities. By the time their plan is set, your timeline is already at risk.
The fix is unglamorous: get 30 minutes on the other team’s planning calendar. Share your upcoming dependencies before your plan is final. In scaled Agile environments, this is what PI planning exists for. In non-Agile shops, a quarterly dependency review between team leads accomplishes the same goal with less overhead.
When the Dependency Won’t Budge
Some dependencies are permanent. You will always need legal to review contracts. Finance will always own budget approvals. The platform team will always control the deployment pipeline.
For permanent dependencies, the operational play is reducing the cost of each interaction rather than eliminating the interaction itself.
Batch requests instead of sending them one at a time. If legal reviews take five business days regardless of volume, submit three items on Monday rather than one item on Monday, Wednesday, and Friday.
Pre-qualify your submissions. If 40% of your requests come back for revisions, the problem isn’t the other team’s speed. It’s the quality of what you’re sending. Build a checklist based on the last ten rejections and review against it before submitting.
Track the actual cycle time across the dependency. Most managers track their own team’s throughput but not the wait time between teams. When you can show that your team’s two-day deliverable sits in an eight-day queue before the next team touches it, you have data for a structural conversation with your leadership. Without that data, you have a complaint; with it, you have a root cause.
The Throughput Is in the Gaps
Operational efficiency conversations usually focus on what happens inside teams: better tools, better processes, clearer roles. Those matter. But the largest untapped efficiency gains in most organizations sit in the spaces between teams, in the queues nobody owns, the handoffs nobody designed, and the coordination overhead that eats more than half the workweek.
If you manage an operations function, mapping your cross-team dependencies is the single highest leverage diagnostic you can run this quarter. The teams aren’t slow. The connections between them are.