Coordination Problems Explained: Why Smart People Working Together Still Fail

On January 28, 1986, the Space Shuttle Challenger disintegrated 73 seconds after launch, killing all seven crew members. The cause was a failed O-ring in the right solid rocket booster, which engineers at Morton Thiokol had warned about the night before. The engineers knew the cold temperatures forecast for launch day would compromise the O-ring's seal. They communicated this concern to management. Management communicated a modified version to NASA. NASA, under political and scheduling pressure, decided to launch anyway.

The Challenger disaster was not a knowledge problem -- the relevant information existed. It was not a competence problem -- the engineers were among the best in their field. It was a coordination problem: information failed to flow effectively between the people who had it and the people who needed it, decision authority was misaligned with technical expertise, and organizational pressure distorted the signal at each handoff point.

Coordination problems are among the most expensive and least understood failures in organizational life. They do not announce themselves as dramatically as technical failures or financial crises. They manifest as gradually accumulating friction: duplicated work, blocked progress, misaligned priorities, and interpersonal tension that participants attribute to personality differences when the real cause is structural. This article examines why coordination problems occur, how to identify them before they cause serious damage, and what mechanisms actually reduce coordination overhead without creating bureaucratic overhead that is equally destructive.

The Fundamental Sources of Coordination Problems

Interdependence Plus Imperfect Information

Coordination becomes necessary whenever people's work affects each other and they do not all know the same things at the same time. These two conditions -- interdependence and information asymmetry -- are present in virtually every team and organization. The only question is the degree.

Tight coupling creates intense coordination needs. In software development, when Module A depends on Module B's API, any change to Module B's interface requires coordination with Module A's developers. In manufacturing, when Station 3 cannot begin until Station 2 completes, any delay at Station 2 cascades through the entire production line.

Loose coupling reduces coordination needs. When two marketing teams run campaigns for different products in different markets, their work rarely intersects. Coordination is minimal because interdependence is minimal.

Example: Amazon's organizational design reflects a deliberate strategy to reduce coordination overhead through loose coupling. The "two-pizza team" structure -- teams small enough to be fed by two pizzas -- combined with service-oriented architecture means each team owns its services independently. Teams coordinate through well-defined APIs (technical interfaces) rather than through meetings, documents, and human communication. This architectural choice reduces coordination problems by reducing interdependence.

The coordination challenge is that real work rarely allows pure independence. Even Amazon's autonomous teams must coordinate on shared infrastructure, common customer experience standards, and organizational priorities. The goal is not eliminating coordination but minimizing unnecessary coordination while making necessary coordination efficient.

The Communication Scaling Problem

Fred Brooks articulated this in The Mythical Man-Month (1975): communication channels grow as n(n-1)/2, where n is the number of team members.

Team Size Communication Channels
3 3
5 10
8 28
10 45
15 105
20 190

This non-linear growth means that adding the 20th person to a team creates 19 new potential communication channels that need to be managed. The coordination cost of each additional person increases with team size, and at some point, adding people actually slows the team down because coordination overhead exceeds the new person's productive contribution.

Example: When Spotify reorganized its engineering teams in the early 2010s, it addressed the scaling problem through its "Squads, Tribes, Chapters, and Guilds" model. Squads (small autonomous teams of 6-8 people) had minimal internal coordination overhead. Tribes (collections of squads working in related areas) coordinated through dedicated alignment mechanisms. Chapters (cross-squad groups of people with similar skills) coordinated professional development. Guilds (informal communities of interest) enabled knowledge sharing. The structure created multiple small coordination surfaces rather than one massive coordination challenge.

Temporal Coordination Challenges

When team members work at different times -- whether due to time zones, flexible schedules, or shift work -- coordination that could be resolved with a quick conversation requires asynchronous mechanisms instead.

The handoff problem: When a developer in San Francisco completes work at 5 PM and needs a team member in London to continue it at 9 AM, the context for the handoff must be communicated in writing. Implicit knowledge that would transfer in a hallway conversation must be made explicit in documentation. Every gap in the handoff -- missing context, ambiguous instructions, unstated assumptions -- creates delay or error.

The feedback loop problem: In co-located teams, questions can be answered in minutes. In distributed teams spanning 8-12 time zones, a question asked at 4 PM in one location might not receive a response until the next morning -- a delay of 14-16 hours. If the response generates a follow-up question, another day is lost. What would have been a 10-minute conversation becomes a 3-day email chain.

Example: GitLab, with over 2,000 employees in 65+ countries and no offices, addresses temporal coordination through its "handbook-first" approach. Every process, policy, and decision is documented in a publicly accessible handbook exceeding 2,000 pages. When a team member in Japan needs to coordinate with a colleague in Brazil, they reference the handbook rather than waiting for a synchronous conversation. The documentation investment is significant, but it reduces the cost of temporal coordination to near zero for matters covered by the handbook.

Identifying Coordination Problems Before They Escalate

The Warning Signs

Coordination problems rarely announce themselves. They manifest as symptoms that are easily misattributed:

Recurring questions about the same things indicate that information is not flowing effectively. If multiple people ask "Who owns this?" or "What was decided about X?" the coordination system is failing to distribute critical information.

Duplicated work indicates that people do not have visibility into what others are doing. When two engineers independently implement the same feature, or two marketing teams create similar content, the coordination mechanism for making work visible has failed.

Frequent blocking indicates that dependency management is inadequate. When team members regularly cannot proceed because they are waiting for someone else's output, either dependencies are not being communicated, or the sequencing of work is not accounting for them.

Rework after integration indicates that teams are not coordinating on assumptions and interfaces. When individual components work in isolation but fail when combined, the coordination of shared assumptions has broken down.

Example: In 2019, Boeing's 737 MAX crisis revealed catastrophic coordination failures between Boeing's engineering teams and the FAA's certification process. Different engineering groups made assumptions about how the MCAS system would behave that were internally consistent but mutually contradictory. No coordination mechanism existed to reconcile these assumptions before the aircraft entered service. The result was two crashes killing 346 people. Congressional investigation identified "fragmented engineering organization" and "inadequate coordination" as root causes.

Surprises in status meetings indicate that information is not flowing between checkpoints. If standup meetings regularly reveal "I didn't know you were working on that" or "I thought we decided differently," the coordination system is not maintaining adequate shared awareness between formal check-in points.

Interpersonal friction with no clear personal cause often indicates structural coordination problems masquerading as personality conflicts. When two people regularly clash, look for unclear role boundaries, conflicting priorities from different managers, or resource contention. The personal tension may be a symptom, not the cause.

Mechanisms That Actually Reduce Coordination Overhead

Architectural Approaches: Reduce the Need for Coordination

The most effective way to address coordination problems is to eliminate the need for coordination through structural design:

Modular work design: Structure work so that individual pieces are as independent as possible, with well-defined interfaces between them. In software, this means microservices with clear APIs. In organizations, this means autonomous teams with clear ownership boundaries.

Example: When Shopify restructured its engineering organization in 2020, it moved from large cross-functional teams to smaller "pods" that owned specific customer-facing capabilities end-to-end. Each pod included all the disciplines needed to ship features independently: engineering, design, product, and data. By reducing cross-team dependencies, Shopify reduced the coordination overhead that had been slowing feature delivery.

Clear ownership boundaries: When everyone knows who owns what, coordination questions about authority and responsibility disappear. The most common coordination conflict -- "Who should handle this?" -- is eliminated when ownership is unambiguous.

Standard interfaces: When teams agree on how their work connects -- data formats, API contracts, process handoffs, deliverable specifications -- they can work independently within those agreements. The coordination happens once (establishing the interface) rather than continuously.

Process Approaches: Make Necessary Coordination Efficient

When coordination cannot be eliminated, make it as efficient as possible:

Regular cadences: Predictable coordination points (daily standups, weekly syncs, sprint planning) create structured opportunities for alignment without requiring continuous interruption. Between cadence points, people can work independently with confidence that alignment will be verified at the next checkpoint.

Async-first coordination: For distributed teams, defaulting to asynchronous coordination -- written proposals, async video updates, documented decisions -- enables coordination across time zones without requiring simultaneous availability. Reserve synchronous time for discussion that genuinely benefits from real-time interaction.

Decision documentation: When decisions are documented with context, rationale, and implications, they do not need to be re-coordinated. The single most expensive coordination failure is relitigating settled decisions because no one can find (or remember) what was decided and why.

Example: Amazon's "six-page memo" practice serves as a coordination mechanism. Before any significant initiative, the proposer writes a structured narrative memo covering the problem, proposed solution, alternatives considered, and expected outcomes. Meeting participants read the memo silently at the start of the meeting, then discuss. This practice eliminates coordination overhead from misaligned understanding (everyone reads the same document) and creates a permanent record of the decision context.

Information radiators: Dashboards, project boards, and status pages that are always current and always visible enable self-service coordination. Instead of asking someone "What's the status of X?" you check the dashboard. Instead of interrupting someone to ask "Is this blocked?" you check the project board.

Organizational Approaches: Structure for Coordination Efficiency

Conway's Law observes that organizations design systems that mirror their communication structures. If the organization requires extensive cross-team coordination, the systems it produces will also require extensive cross-system coordination. Conversely, organizations designed for team autonomy tend to produce modular, loosely coupled systems.

This principle can be applied deliberately: design your organization to match the coordination pattern you want in your outputs. If you want independent product modules, create independent product teams. If you want integrated customer experiences, create cross-functional teams organized around customer journeys.

Liaison roles: When cross-team coordination is unavoidable, dedicated coordination roles (program managers, technical program managers, integration leads) ensure someone is explicitly responsible for making coordination happen. Without explicit ownership, coordination becomes everyone's responsibility -- which effectively means it is no one's.

Shared goals and metrics: When teams share metrics (customer satisfaction, product quality, revenue goals), they are incentivized to coordinate because their success depends on each other. When teams have independent metrics that conflict (one team measured on speed, another on quality), coordination breaks down because helping another team comes at the expense of your own metrics.

Cross-Team Coordination: The Hardest Challenge

Why Cross-Team Coordination Fails

Within a team, coordination benefits from shared context, established relationships, and common goals. Cross-team coordination lacks all three:

  • Different contexts: Each team understands their own constraints, priorities, and challenges but not the other team's
  • Weaker relationships: Team members interact daily with teammates but only occasionally with members of other teams
  • Competing priorities: Each team has their own goals, and helping another team may compete with achieving their own

Example: The 2013 launch of HealthCare.gov exemplifies cross-team coordination failure at scale. Over 55 contractors worked on different components of the website with no central technical authority to coordinate their work. Each contractor met their individual contract requirements, but the components failed catastrophically when integrated. No contractor was responsible for the system working as a whole -- only for their piece working in isolation. The website crashed on launch day and required months of remediation.

What Works for Cross-Team Coordination

Explicit coordination protocols: Document how teams interact -- what information flows between them, at what frequency, through what channels, and with what expectations. Make the coordination mechanism visible and agreed-upon rather than ad hoc.

Regular cross-team forums: Not general all-hands meetings, but focused coordination sessions between specific teams whose work intersects. Keep attendance minimal -- only people who need to coordinate should attend.

Shared documentation spaces: When teams maintain separate documentation systems, information does not flow. Shared spaces where cross-team decisions, dependencies, and interfaces are documented enable coordination without requiring synchronous communication.

Escalation clarity: When cross-team disagreements occur (and they will), clear escalation paths prevent either gridlock (nobody decides) or unilateral action (one team decides without the other). The escalation path should be: attempt resolution between teams, escalate to shared manager if stuck, escalate to executive if still stuck. At each level, the expectation is resolution, not blame.

Coordination in Remote and Distributed Teams

The Amplified Challenge

Remote teams face every coordination challenge that co-located teams face, plus additional ones unique to distance:

  • No ambient awareness: In offices, you overhear relevant conversations, see who is working on what, and naturally absorb context. Remote work eliminates this ambient information.
  • Reduced social cues: Text-based communication misses tone, body language, and facial expressions that help interpret meaning and build relationships.
  • Time zone fragmentation: When the team spans multiple time zones, synchronous coordination windows shrink and asynchronous delays extend.

Remote-Specific Coordination Practices

Over-communicate context: What would be obvious to someone sitting next to you is invisible to someone on another continent. Be more explicit about decisions, reasoning, and status than feels necessary. If it feels like you are over-explaining, you are probably communicating at approximately the right level for remote work.

Written handoffs: When work transitions between people in different time zones, explicit written handoffs prevent dropped balls. "I've completed X. The next step is Y. You'll need to know Z. The relevant documents are linked here. I flagged one concern about W that you should review." A complete handoff like this eliminates an entire coordination cycle that an incomplete handoff would require.

Visible work: Use tools that make work in progress visible -- project boards showing what everyone is working on, pull requests showing what is being reviewed, documentation showing what decisions have been made. The more visible the work, the less coordination is needed to maintain shared awareness.

Structured async updates: Regular written updates (daily or weekly depending on pace) that cover: what was accomplished, what is in progress, what is blocked, and what help is needed. These replace the ambient awareness of office environments with explicit information sharing.

Example: Doist, the company behind Todoist and Twist, operates across 35+ countries with no offices. The company uses a weekly async update format where each team member posts a structured summary in Twist (their async communication tool). The format is standardized: "Done this week / Doing next week / Blocked on / Help needed." This creates a comprehensive picture of team activity that any team member can review at any time, in any time zone.

The Meta-Coordination Problem

There is an important final paradox: coordination mechanisms themselves require coordination. Implementing a new project management tool, establishing new meeting cadences, or creating documentation standards all require the team to coordinate on how they will coordinate. This meta-coordination creates several risks:

Over-coordination: The cure becomes worse than the disease when the overhead of coordination mechanisms exceeds the overhead of the coordination problems they were designed to solve. Five status meetings per week to ensure alignment may create more overhead than the misalignment they prevent.

Coordination theater: Teams adopt coordination mechanisms (standups, retrospectives, documentation standards) as rituals without evaluating whether they actually reduce coordination problems. Going through the motions of coordination is not the same as actually coordinating.

Coordination fatigue: When teams spend so much time coordinating that they have insufficient time for the actual work, burnout and resentment follow. People feel they spend all day in meetings and writing updates, with no time left for the work the meetings and updates are about.

The resolution is right-sizing coordination to the actual complexity of the work. Simple work with loose coupling needs minimal coordination. Complex work with tight coupling needs more. The goal is the minimum coordination investment that prevents coordination failures, not maximum coordination investment that prevents any possibility of misalignment.

As organizational theorist James March observed: "The best organizations don't solve coordination problems. They don't create them in the first place."

References

Tags

coordination teamwork project-management collaboration work-skills

Share this article