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.

This was not a failure of intelligence. The engineers understood the problem. This was not a failure of intention. Nobody intended the launch to fail. This was a coordination problem — a failure in the systems by which information flows between people, by which decisions are made collectively, and by which individual knowledge is translated into organizational action.

Coordination problems are the reason that organizations of smart, capable, well-intentioned people regularly produce outcomes that no individual would have chosen. They explain why projects fail despite everyone's best efforts, why teams make decisions that are obviously wrong in retrospect, and why critical information sits in one part of the organization while the part that needs it proceeds in ignorance. Understanding coordination problems is a prerequisite for building organizations that actually work.

The Four Types of Coordination Problems

"Most organizational failures are not failures of intelligence or intention. They are failures of coordination -- the systems by which individual knowledge and effort become collective action." -- Gareth Morgan, Images of Organization, 1986

Coordination Problem Type Root Cause Common Symptom Primary Intervention
Information problems Information does not reach decision-makers in useful form Decisions made on incomplete data; redundant work Structured information routing, required summaries
Incentive problems Individual rewards conflict with collective goals Teams optimize locally at the expense of the whole Shared metrics, team-level accountability
Knowledge problems Expertise is distributed but not shared Reinventing solutions others have already found Documentation culture, communities of practice
Authority problems Unclear decision rights create bottlenecks or conflicts Decisions delayed indefinitely or made by wrong people Explicit RACI matrices, decision rights documentation

Coordination problems fall into four categories, each with different causes and different interventions.

Type 1: Information Problems

Information problems occur when the people who need information to make good decisions do not have it, while the people who have it do not know it is needed.

The Challenger disaster was primarily an information problem. The critical information — that O-ring performance degraded sharply in cold temperatures — existed. It was in the engineers' analysis. It was communicated through the decision chain. But it was communicated in ways that allowed the people making the launch decision to misunderstand its significance. The information problem was not just that the information did not reach the decision makers; it is that it reached them in a form that did not convey its urgency.

Information problems have several sub-types:

Information silos: Teams that develop deep knowledge of their domain but do not share it with other teams whose work depends on it. The classic example is the product team that makes architectural decisions without knowing the security constraints the infrastructure team has identified, or the sales team that promises features the engineering team has not begun building.

Information overload: So much information flows through organizational channels that critical information is missed or deprioritized. When every communication is marked urgent, nothing is urgent. When everyone is copied on everything, nobody is responsible for acting on anything.

Information filtering: Information is transformed as it moves through hierarchies — softened, summarized, and optimized for the preferences of the recipient. By the time information from the front line reaches senior leadership, it often bears little resemblance to the original observation.

Type 2: Incentive Problems

Incentive problems occur when the actions that are rational for individuals are collectively suboptimal or harmful.

The classic game-theoretic example is the Prisoner's Dilemma: two parties each face a choice between cooperation (which benefits both) and defection (which benefits the individual at the expense of the collective). Rational self-interest produces mutual defection even when mutual cooperation would be better for both.

In organizational contexts, incentive problems produce:

  • Silo competition: Departments that compete for resources, status, or credit rather than cooperating to achieve organizational objectives
  • Short-term optimization: Teams that optimize for their own quarterly metrics in ways that damage long-term organizational health
  • Risk avoidance: Teams that decline to attempt difficult but valuable work because failure is more visible than the absence of success

Example: General Motors' product development culture in the 2000s, described extensively in "The GM Bankruptcy and Coordination Failures" analysis, involved divisions that competed rather than cooperated — developing duplicate platforms, withholding technology from each other, and optimizing divisional sales rather than overall company profitability. The coordination failure was structural: the incentive system rewarded divisional success at the expense of organizational coherence. The bankruptcy in 2009 was the ultimate cost.

Type 3: Cognitive Problems

Cognitive problems occur when teams reach incorrect conclusions despite having adequate information, because of biases, mental models, or reasoning errors that distort how information is processed.

Groupthink, identified by Irving Janis through his analysis of historical policy failures including the Bay of Pigs invasion, occurs when cohesive groups prioritize consensus and harmony over accurate assessment. Dissenting views are suppressed, alternative interpretations are not explored, and the group converges on a shared conclusion that individual members might not hold independently.

Shared information bias, documented by Garold Stasser and William Titus in 1985, describes the tendency of groups to spend disproportionate time discussing information that all members share, while under-discussing information that only one or few members hold. The result is that unique knowledge — often the most valuable input to a decision — is systematically underweighted in group decisions.

Authority bias distorts cognitive processing in hierarchical groups: information provided by higher-status members is weighted more heavily than information from lower-status members, regardless of its quality. In the Challenger decision chain, the engineers' technical assessment was overridden by the managers' judgment about organizational pressure — a status-based cognitive override of expert knowledge.

Type 4: Structural Problems

Structural problems occur when the organization's design — its reporting relationships, communication channels, decision authorities, and process requirements — produces poor coordination outcomes regardless of individual behavior.

Conway's Law, articulated by Melvin Conway in 1968, states that "organizations which design systems are constrained to produce designs which are a copy of the communication structure of those organizations." Teams that do not coordinate produce systems whose components do not integrate. The technical architecture reflects the organizational structure.

Diffusion of responsibility (also known as the bystander effect, first studied by John Darley and Bibb Latané following the Kitty Genovese murder in 1964) describes the reduction in individual felt responsibility when others are present. In organizational contexts: when a task is visible to multiple people, each person feels less responsible for it than they would if they were the only one who could act. Tasks with multiple nominal owners are often tasks with no actual owners.

The Coordination Tax

Every coordination mechanism imposes overhead — the coordination tax. Meetings, review processes, documentation requirements, approval chains — all consume time and attention that could otherwise be spent on productive work.

The coordination tax is unavoidable in teams larger than a handful of people. The question is not whether to pay it but how much to pay and for what return.

Too little coordination investment produces the coordination failures described above: information silos, incentive misalignment, structural dysfunction. The cost is visible in failed projects, duplicated work, and poor decisions.

Too much coordination investment produces bureaucracy: processes that consume more value than they create, decisions that require approval from so many people that they cannot be made, and organizational attention so consumed by coordination that insufficient attention remains for the substantive work being coordinated.

Example: Amazon's famous "two-pizza rule" — teams should be small enough that two pizzas can feed them — is specifically a coordination optimization rule. Small teams have lower internal coordination overhead, move faster, and are more accountable. The rule acknowledges that coordination overhead scales faster than team size: a team of ten has five times more coordination pairs than a team of four.

Structural Solutions to Coordination Problems

Different coordination problems require different solutions. Applying the wrong solution to a coordination problem produces overhead without improvement.

For Information Problems

Transparency by default: Making information available to anyone who might need it, rather than restricting access and relying on information-pushing from sources to recipients. Google's internal culture of making most project information accessible to any Google employee is an example — information consumers can find what they need without requiring information producers to push it to them.

Structured information-sharing forums: Regular forums specifically designed to share information across team boundaries — cross-team demos, architecture reviews, operational reviews. These create predictable opportunities for information exchange that do not depend on individuals proactively identifying what others need to know.

Direct communication channels: Removing intermediaries from important communication flows reduces filtering. When the people with information and the people who need it can communicate directly, the distortion of multi-hop communication chains is eliminated.

For Incentive Problems

Shared metrics: Replacing purely departmental metrics with metrics that capture cross-functional outcomes. If engineering and product share an uptime metric, they have a shared incentive to coordinate on reliability. If sales and product share a customer satisfaction metric, they have a shared incentive to coordinate on promise-keeping.

Cross-functional team structures: Organizing teams around outcomes rather than functions means that the people with different specializations who must coordinate to achieve an outcome are in the same team, with shared accountability. Spotify's "squad" model — cross-functional teams owning a product area end-to-end — is an example.

For Cognitive Problems

Formal devil's advocate roles: Assigning someone to actively argue against the group's emerging consensus forces engagement with dissenting views that might otherwise be suppressed.

Pre-mortem analysis: Before a decision is made, ask the group to imagine that the decision turned out badly and identify what went wrong. The framing bypasses the social pressure for consensus and activates the reasoning capabilities that would identify the decision's weaknesses.

Structured debate: Explicitly separating the generation of alternatives from the evaluation of alternatives reduces the tendency to converge on the first reasonable option.

For Structural Problems

Clear ownership: Every important task, decision, and outcome should have exactly one owner — the person accountable for ensuring it happens. Ownership shared by multiple people is ownership that belongs to nobody.

Team-of-teams architecture: Stanley McChrystal's transformation of the Joint Special Operations Command in Iraq, described in Team of Teams (2015), addressed structural coordination problems by creating a network of teams that operated with high autonomy but with dense cross-team communication. Each team maintained situational awareness of what other teams were doing; any team could act on shared information without waiting for cross-team coordination. The result was decision speed that hierarchical coordination could not achieve.

For related frameworks on how communication supports coordination, see cross-team communication and organizational alignment explained.

What Research Shows About Coordination Problems

The academic literature on coordination failure has produced specific, actionable insights that go well beyond the intuitive observation that communication is important.

Thomas Schelling's 1960 work The Strategy of Conflict introduced the concept of focal points — the tendency for people in coordination problems to converge on prominent, natural, or familiar solutions without explicit communication. Schelling demonstrated through thought experiments and game theory that coordination is possible even without communication, when a solution is sufficiently salient to both parties. In organizational contexts, focal points explain why shared cultural references, common professional training, and organizational norms reduce coordination costs: they create implicit agreement on what the "obvious" solution is. Schelling won the Nobel Prize in Economics in 2005 partly for this work. His research predicts that organizational changes that destroy focal points (reorganizations, culture shifts, leadership changes) should produce temporary coordination failure spikes, which has been observed empirically.

Elinor Ostrom's Nobel Prize-winning research on the governance of common pool resources (1990) directly challenges the assumption that coordination problems require either centralized authority or market mechanisms to solve. Ostrom studied fishing communities, irrigation systems, and forest management practices across dozens of countries and found that communities regularly developed effective self-governing coordination mechanisms without either top-down authority or market pricing. Her eight design principles for successful common pool resource governance — including clearly defined boundaries, rules adapted to local conditions, collective choice arrangements, and graduated sanctions — have been applied to organizational coordination design with significant results. Ostrom's core finding: the people closest to the coordination problem are often best positioned to design its solution, if given legitimate authority to do so.

Garold Stasser and William Titus published landmark research on group decision-making in 1985 that identified the "shared information bias" — groups spend disproportionate time discussing information that all members already know, while systematically under-discussing information that only one or a few members hold. In practical terms: the unique knowledge of individual team members — often the most valuable information for a group decision — is systematically underweighted in group deliberation. Stasser and Titus's research has been replicated dozens of times and extended to show that the effect is stronger when the group has a pre-existing preference (confirmation bias amplifies shared information bias) and when individual status is salient (higher-status members' information is discussed more regardless of quality).

Karl Weick's research on organizational sensemaking, particularly his analysis of the Tenerife airport disaster (1977) and Mann Gulch fire (1949), identified how coordination fails under extreme uncertainty and time pressure. Weick found that the collapse of sensemaking — the shared understanding of "what is happening here" — produces coordination failure even among highly skilled, motivated teams. His research found that coordination is not primarily about information sharing but about shared meaning construction: teams that maintained a common understanding of their situation coordinated effectively; teams whose members were operating from different mental models of the situation failed even with good information. The practical implication: explicit sensemaking — regularly asking "what is our shared understanding of this situation?" — is a coordination intervention, not just a communication nicety.

Amy Edmondson's research on psychological safety and team performance at Harvard Business School, beginning with her 1999 hospital study, has demonstrated that coordination quality is strongly mediated by psychological safety. Teams with higher psychological safety share information more completely, surface problems earlier, and integrate diverse perspectives more effectively. Edmondson found that the strongest predictor of medication error reporting in hospital teams was not team skill level but psychological safety — teams felt safe enough to report errors, which is a coordination behavior. Her subsequent research extended this finding across organizational contexts, consistently finding that the information coordination that prevents failures depends on psychological safety conditions.

Real-World Case Studies in Coordination Failure and Success

The NASA Mars Climate Orbiter loss (1999) is the canonical case of a Type 1 information problem producing catastrophic coordination failure. The spacecraft, which cost $327 million, was lost because one engineering team was using metric units and another was using imperial units. Both teams were competent; the information they produced was accurate within their reference frames. The coordination failure was not in the content of the information but in the absence of a shared standard that would have made the inconsistency visible. Schelling's focal point concept applies: the teams had no common focal reference that would have revealed the unit discrepancy before it killed the mission.

The Toyota Production System represents Ostrom's self-governance principles applied to industrial coordination at scale. Toyota's "andon cord" — a physical cord that any assembly worker could pull to stop the entire production line if they identified a defect — is a coordination mechanism that inverts the traditional hierarchy. The person closest to the problem has both the authority and the explicit expectation to halt the coordination system when something is wrong. This design produced Toyota's legendary quality outcomes: not by inspecting quality in at the end, but by enabling real-time coordination failure detection at the source. The coordination mechanism was designed by people who understood the specific coordination problem, consistent with Ostrom's principle that local knowledge should inform governance design.

The 2003 Space Shuttle Columbia disaster illustrates Weick's sensemaking failure applied to the most consequential organizational coordination problem. After the foam strike on Columbia's wing during launch, NASA engineers requested satellite imagery to assess potential damage and were denied. The sensemaking failure — the shared understanding among NASA management that the foam strike was "not a safety issue" — produced a coordination system that could not process the information that might have challenged that understanding. Engineers who raised concerns were working from a different mental model than managers who dismissed them. Weick's research predicts exactly this outcome: when the dominant sensemaking frame is wrong, information that contradicts it is not integrated into coordination decisions.

Spotify's Squad model is a deliberately designed structural response to coordination problems in a scaling technology organization. By organizing teams as cross-functional "squads" with end-to-end ownership of a product area — rather than functional departments that hand off to each other — Spotify eliminated many of the handoff coordination failures described in this article. The squads were small enough (Schelling: fewer coordination pairs) and autonomous enough (Ostrom: local decision authority) to make coordination decisions without cross-functional negotiation. The model also created "tribes," "chapters," and "guilds" as lateral coordination mechanisms that preserved knowledge sharing without creating coordination overhead. Spotify's model has been widely adopted and adapted, though its success in replication has been mixed — suggesting that the structural design must be adapted to local conditions, as Ostrom's research would predict.

Evidence-Based Approaches to Solving Coordination Problems

Research across game theory, organizational behavior, and management practice identifies specific interventions that reliably reduce coordination failures.

Focal point design, drawing on Schelling's research, involves deliberately creating shared reference points that allow teams to coordinate without explicit communication. Shared coding standards, API contracts, naming conventions, and design principles all function as focal points that reduce the coordination overhead required to integrate work across team boundaries. The investment in creating clear focal points upfront — the shared standards, conventions, and reference frameworks — pays coordination dividends throughout a project's life. The absence of focal points is not neutral; it forces expensive explicit coordination for every decision that shared standards would have resolved automatically.

Information market mechanisms, inspired by Ostrom's self-governance research and applied by companies including Google and Hewlett-Packard, involve creating internal prediction markets where employees can bet on project outcomes, product success, or risk events. These mechanisms aggregate distributed information (Stasser's unique information that formal meetings fail to surface) into price signals that indicate collective belief about the probability of various outcomes. Google's internal prediction markets on product launch dates were found to be more accurate than official project estimates because they aggregated the distributed knowledge of engineers who knew the actual state of readiness but had no formal channel to express it.

Structured role rotation across team boundaries, supported by research on information silos and knowledge transfer, involves deliberately moving people between teams on temporary assignments. The rotation creates personal networks that serve as informal coordination channels — when team A member Alice knows team B member Bob personally, Alice is more likely to reach out to Bob when she needs information from team B's domain, and Bob is more likely to share it. Research on cross-functional knowledge transfer found that personal relationships were the most reliable conduit for tacit knowledge that documentation could not capture.

Pre-mortem analysis for coordination risks specifically, adapted from Gary Klein's original pre-mortem concept (1989), involves asking "imagine the coordination between these teams failed — what specifically caused it?" before the coordination is needed. This surfaces coordination assumptions that both teams hold differently, reveals information that one team has and the other needs, and identifies structural ambiguities in ownership that would produce conflict under pressure. The pre-mortem is more effective at coordination risk identification than retrospective process review because it happens before the failure, when corrective action is still cheap.

References

Tags

coordination teamwork project-management collaboration work-skills

Frequently Asked Questions

What are the fundamental coordination problems teams face and why do they occur?

Fundamental coordination problems stem from interdependence combined with imperfect information—when people's work affects each other but they don't all know the same things at the same time. Work dependencies create coordination needs: if your task requires output from my task, we must coordinate timing, format, and expectations. The more interdependent work is, the more coordination required. Tightly coupled systems (each person's work immediately affects others) need more coordination than loosely coupled ones. Information asymmetry means different people know different things: you know your constraints and priorities, I know mine, but neither knows the other's full context. We make decisions based on incomplete information about how those decisions affect others. This creates unintentional conflicts. Distributed knowledge means no one person understands entire system: in complex projects, each person has expertise in their domain but imperfect understanding of other domains. Coordinating requires somehow combining these partial understandings into coherent action. Communication overhead scales with team size: in two-person team, one communication channel exists. Five-person team has ten potential channels. Ten-person team has forty-five. Each person added increases coordination cost non-linearly. Organizations try to solve this through hierarchy and structure, but that introduces new coordination problems. Conflicting goals and priorities create coordination challenges even with perfect information: if your priority is shipping fast and mine is ensuring quality, we'll naturally make different tradeoff decisions. Coordination requires reconciling these conflicts. Temporal coordination challenges arise when people work at different times: asynchronous work reduces interruptions but complicates coordination requiring real-time interaction or immediate responses. Remote and distributed teams face amplified temporal coordination challenges. Implicit dependencies aren't recognized until violated: sometimes people don't realize their work depends on others' until something breaks. Discovering dependencies through failure is painful coordination learning. Resource contention requires coordination: when multiple people need same resources (someone's time, shared infrastructure, budget), they must coordinate priority and allocation. Absent coordination, resources get over-committed or under-utilized. Finally, changing conditions require re-coordination: even if team coordinated perfectly initially, when requirements change, priorities shift, or people join or leave, coordination must be reestablished. Coordination isn't one-time activity but ongoing adaptation.

How do you identify coordination problems before they cause serious issues?

Identifying coordination problems early requires watching for signals: recurring confusion, duplicated effort, blocked work, interpersonal friction, and misalignment between teams—and creating visibility systems that surface issues. Recurring questions signal coordination gaps: if people repeatedly ask the same questions about ownership, process, or priorities, information isn't flowing effectively. The questions themselves indicate what coordination is missing. Track repeated questions to identify patterns. Duplicated work indicates coordination failure: if two people implement similar solutions unaware of each other, coordination broke down. This wastes effort and creates redundant systems. Regular sharing of in-progress work helps catch duplication early. Work blocking frequently suggests dependency coordination issues: if people often can't proceed because waiting for someone else, either dependencies aren't being communicated clearly or scheduling isn't accounting for them. Frequent blocking indicates coordination debt. Rework and contradictory decisions indicate misalignment: when team implements something then has to redo it because another team made different decision, coordination between teams failed. This is expensive and frustrating. Catch through better information sharing and decision visibility. Interpersonal friction sometimes stems from coordination failure not personality conflict: if two people keep clashing, look for unclear role boundaries, conflicting priorities, or resource contention. The personal tension might be symptom of structural coordination problem. Missed deadlines and scope creep often have coordination roots: underestimating interdependencies, poor communication about constraints, or changing requirements not properly communicated. Post-mortems on missed deadlines usually reveal coordination issues. Fragmented conversations about same topic in different channels signal coordination breakdown: if decision discussion happens in three places simultaneously with different participants, coordination has fragmented. Centralize important discussions. Quality issues at integration points suggest teams aren't coordinating on interfaces: if individual components work but fail when combined, teams didn't coordinate assumptions, requirements, or testing. Integration problems are coordination problems. Check-ins revealing surprises mean coordination isn't working: if standup or status meeting reveals 'I didn't know you were working on that' or 'I thought we decided differently,' coordination failed somewhere. Surprises indicate information isn't flowing. Create visibility systems that surface coordination needs: project boards showing dependencies, documentation of decisions, regular updates on progress and blockers. Without visibility, coordination problems hide until they're serious. Finally, explicitly ask about coordination: in retrospectives or team health checks, directly query where coordination is painful, what dependencies are unclear, or what information is hard to get. People usually know where coordination sucks; they just need permission to name it.

What mechanisms and practices effectively reduce coordination overhead in teams?

Reducing coordination overhead requires both structural changes (reducing need for coordination) and process improvements (making necessary coordination more efficient). Reduce coupling where possible: architect work so tasks are more independent. If you can structure projects so people's work doesn't constantly depend on others completing their work first, coordination need decreases. Modular design, clear interfaces, and loose coupling in software enable parallel work. Same principle applies to any collaborative work. Create clear interfaces and contracts: when work must be interdependent, explicit agreements about inputs, outputs, timing, and quality reduce ongoing coordination. 'I'll deliver X in Y format by Z date meeting Q quality standard' lets both parties work independently within agreement. Establish decision rights: clarity about who decides what prevents coordination overhead from decision-making. If everyone knows who owns each decision type, they don't need to coordinate to determine who should decide. Ambiguous ownership creates coordination debt. Use async-first communication: asynchronous communication allows people to coordinate across time zones and work schedules without requiring simultaneous availability. However, this requires good written communication and appropriate response time expectations. Implement regular cadences: predictable standup meetings, weekly updates, or sprint planning create structured coordination points rather than constant interruption. Between cadence points, people can work with less coordination. However, don't over-schedule—too much cadence time becomes its own overhead. Document decisions and context: coordination debt accumulates when decisions must be re-litigated because history wasn't documented. 'We decided X because Y' documentation prevents repeated coordination on settled issues. Create centralized information radiators: project dashboards, roadmaps, or status pages that people can consult rather than asking individuals for updates reduce coordination communication. Self-service information access is more efficient than request-response. Batch communication: instead of many small messages creating constant interruptions, batch updates into digests sent at regular intervals. This respects focus time while maintaining information flow. Establish communication protocols: clarity about what goes where (quick questions in chat, decisions in documentation, formal communication in email) prevents coordination confusion about appropriate channels. Use broadcast communication appropriately: instead of individually informing multiple people of relevant updates, broadcast to channels or distribution lists they monitor. However, over-broadcasting creates noise. Use tools that automate coordination: project management tools that show dependencies, calendar systems that coordinate scheduling, or Slack bots that surface relevant updates reduce manual coordination work. Finally, right-size team structures: smaller autonomous teams with clear ownership reduce coordination need. Conway's Law suggests systems reflect organization structures—design organization to enable desired system architecture.

How do you coordinate across different teams or departments with competing priorities?

Cross-team coordination requires explicit alignment mechanisms, liaison roles, transparency about priorities, and escalation paths for conflicts that individual contributors can't resolve. Establish shared goals or metrics that create aligned incentives: if teams are measured purely on their own objectives, they'll optimize locally at expense of global outcomes. Shared success metrics encourage coordination. For example, if both teams are measured on customer satisfaction, they'll coordinate to ensure handoffs work smoothly. Create liaison roles or coordination points: designated people responsible for coordination between teams. This might be project managers, technical leads, or rotating roles. Having explicit ownership prevents coordination from being everyone's responsibility (and therefore no one's). Regular cross-team meetings at appropriate level: maybe weekly coordination between leads, monthly alignment between managers, quarterly strategic planning. These create structured forums for resolving coordination issues. However, don't over-meeting—only include people who need to be involved. Use shared communication channels: joint Slack channels, shared documentation spaces, or combined project boards make coordination visible and reduce information silos. However, avoid forcing teams into fully shared spaces if their day-to-day work is independent. Make priorities and roadmaps transparent: if each team publicizes their priorities and upcoming work, others can identify potential conflicts or dependencies proactively. Hidden roadmaps make coordination reactive rather than proactive. Establish escalation paths for conflicts: when teams disagree on priorities, what's the process for resolution? Unclear escalation leads to either unresolved conflict or every small disagreement going to executives. Clear escalation might be: try to resolve between teams, escalate to managers if needed, go to shared executive if still unresolved. Document interfaces and dependencies: when teams' work touches, explicitly document how they integrate. Service level agreements, API specifications, or process handoffs create clarity that reduces coordination friction. Create shared documentation and decision logs accessible to both teams: cross-team decisions and context shouldn't live in one team's private space. Shared visibility ensures everyone has same information. Use program or product management to coordinate: roles explicitly designed to coordinate multiple teams working toward shared goal. These people understand each team's constraints and facilitate alignment. Build relationships across teams: coordination works better when people know and trust their counterparts in other teams. Invest in cross-team social connection, not just work interaction. Time-box coordination overhead: coordination can become its own full-time job. Be realistic about how much coordination time is reasonable and push back on unsustainable coordination demands. Sometimes this means restructuring work for less interdependence. Finally, accept some coordination conflicts won't fully resolve: sometimes teams genuinely have competing priorities. In those cases, explicit decision from leadership about which priority wins is better than pretending conflict doesn't exist.

What coordination patterns work best for remote and distributed teams?

Remote coordination requires more explicit communication, async-first approaches, documentation-heavy practices, and clear handoff processes compared to co-located teams where spontaneous coordination happens naturally. Document everything: coordination in offices happens through hallway conversations, quick desk drive-bys, or overhearing relevant discussions. Remote teams must intentionally document decisions, context, and status so information doesn't exist only in someone's head. This creates coordination overhead but also valuable searchable history. Use async-first coordination: remote teams often span time zones, making synchronous coordination difficult or requiring someone to work inconvenient hours. Default to async communication—written proposals, status updates, and async video—saving synchronous time for discussion genuinely benefiting from real-time interaction. Establish clear handoff processes: when work moves between people in different time zones, explicit handoffs prevent dropped balls. 'I've completed X, next step is Y which requires you to do Z, here's the relevant context' creates clean transition. Without explicit handoffs, work stalls waiting for someone to figure out it's their turn. Create comprehensive written updates: written status updates replace the ambient awareness of office environments where you overhear progress and blockers. Regular written updates should cover what's done, what's in progress, what's blocked, and what help is needed. Use time zone overlap strategically: identify overlap hours when everyone's available for synchronous coordination, then batch synchronous activities into those windows. Outside overlap, expect async operation. Design for independence: structure work so people can make progress without constant coordination. If every task requires immediate input from someone in different time zone, you'll constantly block. Modular work with clear interfaces enables parallel async progress. Over-communicate context: remote communication lacks the ambient context of office environments. Be more explicit about why decisions are made, what constraints exist, and how work fits into bigger picture. What seems obvious to you isn't obvious to teammate who doesn't share your physical context. Use video for richer communication: text misses tone and nuance that cause coordination confusion. Async video messages (Loom) or synchronous video calls provide richer communication for complex coordination. Maintain visible coordination artifacts: shared boards, dashboards, or documentation that show current state, dependencies, and blockers. These create shared understanding without requiring everyone to be in same place at same time. Establish coordination cadences: predictable times for updates, check-ins, or decisions create structure. For distributed teams, rotating meeting times can share time zone pain rather than always forcing some people to work inconvenient hours. Finally, invest in relationship despite distance: coordination improves when people know and trust each other. Periodic in-person gatherings or regular video social time builds relationships that facilitate smoother coordination.

Share this article