Cross-team coordination

Cross-team coordination is the work of aligning decisions that touch several teams on one project, when no single team can settle them alone. It is hardest during discovery, when the problem is still being found: which teams a decision will affect, and what facts it depends on, are not yet known. The relevant research is spread across software engineering, large-scale agile studies, organisation science (where a set of teams pursuing a shared goal is called a multiteam system) and architecture-decision research. The central dispute is about amount: aligning with other teams is reported to cost autonomy and speed (Moe et al., 2019), while multiteam systems that failed were found to under-engage in between-team behaviours (Campbell et al., 2022). Direct measurement of the cost of cross-team decisions is thin, and most of the evidence is qualitative or comes from adjacent settings such as geographic distance and code-level dependencies.

History

Early empirical work asked why distributed software development was slow. Herbsleb and Mockus found in 2003 that distributed work items took about 2.5 times as long as co-located ones, and that the number of people involved was strongly related to completion time (Herbsleb & Mockus, 2003). Espinosa and colleagues followed with the argument that shared knowledge of the team reduces the damage distance does to coordination (Espinosa et al., 2007).

A second line, socio-technical congruence, asked whether the people who need to coordinate can be derived from technical dependencies and compared with who actually does. Cataldo and Herbsleb reported in 2013 that gaps between coordination requirements and actual coordination increased failures in two industrial projects (Cataldo & Herbsleb, 2013). Multiteam systems theory, in the same decade, treated change over time (dynamism) as a structural feature of a system of teams, with coordination mechanisms to hold the component teams together (Luciano et al., 2018).

Field studies of large-scale agile programs, where many teams work in parallel on one product, followed (Dingsøyr et al., 2018). A fuller history of the field, including its earlier theory of interdependence between units and the scaling frameworks, is missing.

Core concepts

Dependencies

A dependency is something one team needs from another before it can proceed. Strode and Huff derived a taxonomy from three agile case studies with three categories: task, resource and knowledge dependencies (Strode & Huff, 2012). Knowledge dependencies divide further into requirement, expertise, historical and task-allocation dependencies (Tkalich et al., 2025). In 17 interviews at two Nordic fintech firms, one team reported an expertise dependency, acceptance-testing skill held outside the team and borrowed from others, as critical (Tkalich et al., 2025).

Dependencies are not fixed. A longitudinal study of a large-scale agile program found that external and internal change events led to new or adjusted coordination mechanisms; the authors list technical dependencies among the things that change and call for work on how mechanisms respond to changing dependencies, so the shift in dependencies is assumed rather than itself measured (Berntzen et al., 2023). A study of automotive teams found that team interface management mattered most in the concept phase, and project structuring and support in the development phase (Hoegl & Weinkauf, 2005). At the level of code changes in OpenStack, about half of the dependencies between changes were identified only during code review, after the changes were created (Arabat et al., 2025). In the congruence study, over half of new out-of-group coordination needs arose between developers who had no interdependence in the previous month (Cataldo & Herbsleb, 2013).

Coordination mechanisms

A four-year program of up to 12 teams used many coordination mechanisms, and its practices changed over time (Dingsøyr et al., 2018). Two telecom cases kept alignment either top-down (centralised decisions for some areas, supervisory roles, mandatory processes, checklists) or through a bottom-up community of all teams (Moe et al., 2021). Literature cited by Dingsøyr and colleagues holds that under uncertainty and major change, hierarchies and rule-based systems are less useful and informal interpersonal communication matters more (Dingsøyr et al., 2018). In that program, cross-team decisions were discussed informally among relevant stakeholders and formalised afterwards, and informal coordination between members of different teams increased over time (Dingsøyr et al., 2018).

The decision loop

Decision loops across teams are costly in several ways. In a case study of a large-scale agile firm, 43% of survey respondents said they spend too much time and energy on decisions (Lastro & Schuster, 2024). Decisions affecting many teams without a clear owner led to repeated iterations and long processes, and work involving many teams beyond the immediate stakeholders lacked a synchronisation process (Lastro & Schuster, 2024). Finding a decision after it has been announced is also costly when announcements are spread over many channels, and the same decision may be in several places or nowhere (Lastro & Schuster, 2024). In large products, architecture decisions affect other decisions and other architects, and the environment hinders recording and follow-up (Power & Wirfs-Brock, 2018). Consulting teams on cross-team decisions was slow, which management found frustrating, but the teams felt better about the result (Moe et al., 2021).

Knowing who needs to hear what

Developers are often unaware of when they need to coordinate with others, and they described not knowing how their tasks affect other tasks or who is responsible for them, which led to duplicated or unmanaged work (Blincoe et al., 2015). Keeping aware of coordination needs is hard even for co-located teams and harder when distributed (Blincoe et al., 2015). In a survey of 92 engineers, not knowing whom to contact about what across sites led to serious coordination problems, most often delay in resolving issues (Herbsleb & Mockus, 2003). In two studied projects, actual communication only partly matched task dependencies, and boundary spanners with wide domain knowledge held key positions (Damian et al., 2013). These studies concern individuals within a project, not whole teams discovering new problems, so the transfer to teams is indirect. Shared knowledge of the team reduces the harm distance does to coordination (Espinosa et al., 2007).

Involving teams affected later

In requirements engineering, poor stakeholder identification in software ecosystems can surface as late requirements from critical stakeholders that threaten schedule, quality and scope, yet requirements managers believe all key stakeholders can be identified (Lewellen, 2021). Team-membership research treats each joining or leaving as an event whose effect depends on how novel, disruptive and critical it is for the team (Trainer et al., 2020), but it concerns single teams, not teams drawn into a decision after the fact. Socio-technical congruence is the nearest method: it derives who must coordinate from technical dependencies, though it works on developers and code (Cataldo & Herbsleb, 2013).

Decisions that depend on unknown facts

Practice offers two framings. Real options thinking defers decisions to the last responsible moment, a lean principle (Matts & Maassen, 2007). Architectural assumptions are dynamic and can turn out invalid during their lifecycle, according to a case study of 24 architects (Yang et al., 2017), yet a practitioner survey found few practitioners identify and record them, because approaches and tools are lacking (Yang et al., 2016). Architects reported noticing faulty decisions more often through outside triggers, such as changes in team structure and new requirements; they rarely revised the architecture completely and mostly accepted a sub-optimal situation or developed further (Wiese et al., 2023). Dewar’s Assumption-Based Planning names steps for this: identifying load-bearing vulnerable assumptions and agreeing on signposts to monitor them (Dewar, 2002).

Record keeping

The architecture decision record (ADR) stores each decision with a status, and marks reversed decisions as superseded rather than deleting them, so the reasons stay visible (Nygard, 2011). Its template records agreement through statuses such as proposed (stakeholders have not agreed yet) and accepted (Nygard, 2011). The MADR template has no assumptions field; revisiting is only a free-text suggestion in an optional section (MADR project, n.d.). Some templates build revisiting in: SoundCloud’s design-doc template includes a revisit date and a state field, and Stedi’s RFC template has Draft, Proposed and Published status (Orosz, 2022). Project-management assumption logs exist with owner, due date, confidence and severity fields (Gallagher, 2018).

Tools

Tools described on their own pages cover parts of the problem. Loomio records the decision, each member’s reasoning and the discussion in one place (Loomio Cooperative Limited, n.d.). Jira Product Discovery collects stakeholder input through comments, votes and reactions and links product decisions to Jira delivery work (Atlassian, n.d.). Productboard centres on customer feedback and feature requests (Productboard, n.d.). Fireflies extracts decisions and action items from meetings and tracks them across meetings, email and work apps (Fireflies.ai, n.d.). Log4brains stores ADRs as markdown in the repository, treats them as immutable except for status, and publishes them as a static site (Vaillant, n.d.). For dependencies, Aha! notifies a user who has enabled it when the status of a linked record changes (Groff, 2018), and Kendis lets users add watchers and deadlines to dependencies and alerts when a due date is missed (Kendis, n.d.). Both work on links someone has already created between work items; the pages describe neither decisions nor finding teams that are not yet linked. A review of 20 architecture-decision tools found that 12 lack support for synchronous and asynchronous communication, and that none was designed to support agile practices (Adil et al., 2023).

Questions, controversies, and new developments

How much coordination is too much?

Aligning with other teams in large-scale agile is reported to threaten team autonomy and reduce responsiveness (Moe et al., 2019), and team autonomy was limited by the need for organisational alignment; a community-based bottom-up structure is proposed as one way to balance control and autonomy (Moe et al., 2021). Against this, failing multiteam systems were found to over-engage in within-team alignment and under-engage in between-team behaviours (Campbell et al., 2022). Both too much and too little are reported as harmful.

What does a delay cost, and how long is it?

Measured numbers come from cross-site work. In a survey of 92 engineers, delays from needing information, discussion or a decision from someone averaged 2.4 days across sites against 0.9 days at the local site, with frequency not differing (Herbsleb & Mockus, 2003). For cross-team work in large-scale agile, interviewees at two fintech firms estimated dependency waits from several days to months, but these are estimates, not measurements, and concern support functions and suppliers more than peer-team decisions (Tkalich et al., 2025). The same study found that inter-team bottlenecks caused only moderate delays and most were team-specific, while the severe ones sat at interfaces with support functions and external suppliers (Tkalich et al., 2025). The 12-team program in which decisions were discussed informally and formalised afterwards did not report decision handling as a bottleneck, but its data were collected after the program ended and the study is explorative, so it cannot show decision speed or cost (Dingsøyr et al., 2018).

Late information causes rework in qualitative terms. A large-scale case study links requirements communication gaps to missed customer expectations, quality issues and wasted effort (Bjarnason et al., 2011), and a six-company study reports that weak communication of requirement changes to another group (testers) leads to quality problems, wasted effort and delays (Bjarnason et al., 2023). Both concern requirements and testing rather than multi-team discovery.

Does matching coordination to dependencies pay off?

In two industrial projects, moving from minimum to maximum structural congruence was associated with an 18.6 percent (project A) and 7.6 percent (project B) lower estimated probability that a file is failure-prone (Cataldo & Herbsleb, 2013). Congruence also shortened modification-request resolution time, but adding the measures raised explained variance by only 6 and 14 percent (adjusted R2), and the authors say the aim was to show a relationship, not to predict (Cataldo & Herbsleb, 2013). A study of 25 open-source projects, using a related but not identical congruence measure, found no statistical relationship between socio-technical congruence and bugs or churn (Mauerer et al., 2021). The measures differ and the settings differ (industrial and open source), so this is a conflict, not a strict failed replication.

Do records survive, and can they be extracted automatically?

Adoption of ADRs in open source is low: half of the GitHub repositories that use them hold only one to five (Buchgeher et al., 2023), and systematic use goes with two or more people recording over a longer period (Buchgeher et al., 2023). Many projects that start ADRs are reported to abandon them, leaving logs incomplete or outdated (Gupta et al., 2026). A 2026 study of 921 GitHub repositories found that about 63% of 5,800 ADRs were opened directly as accepted, skipping the deliberation that records are meant to capture (de Santana Junior et al., 2026). Practitioners in an industrial action study found ADRs useful but reported keeping documentation up to date as a concern (Ahmeti et al., 2023); introducing ADRs needed sustained effort and guideline refinement, and teams faced culture, tacit-knowledge, process and tooling difficulties (Ahmeti et al., 2023). Where records are stored strongly affected perceived usefulness, and a three-month study in a microservice company found they helped documentation culture and team cooperation (Ahmeti et al., 2024). One IBM team kept over 80 ADRs for nearly two years, saw one decision discussed again and accepted when requirements changed, and also wrote that a known performance risk “was in the ADR but we forgot about it” (Keeling & Runde, 2018). Mistakes are communicated mainly within project teams, seldom across teams or companies (Wiese et al., 2023). In contrast, one study covers about 1.5 million emails over 20 years containing decisions for 466 Python Enhancement Proposals (Sharma et al., 2021).

Design decisions are scattered across forums, mailing lists, pull requests, issues and commits, and transformer models are being tested to detect design discussions in them (Arkoh et al., 2026). Automatic decision detection in meeting recordings has been researched since at least 2007, because playback and keyword search are insufficient (Hsueh & Moore, 2008). Results on developer chat are modest. A classifier for information types in Gitter threads reached weighted F1 0.628 across nine categories, but the classes closest to decision talk scored only F1 0.318 (Pan et al., 2021). On IRC chat, rationale messages were detected with 0.76 precision and 0.79 recall, while fine-grained rationale elements reached only about 0.45 and 0.43; rationale appears in about 25% of messages (Alkadhi et al., 2018).

Awareness tools

Blincoe’s thesis states that awareness tools recommending coordination needs have not been widely adopted in practice, and attributes this to lack of timely support and inefficient recommendations (Blincoe, 2014). ProximityML, the thesis’s recommender, was evaluated offline and through six developer interviews in one open-source project; deployment was left as future work, so no field-use evidence exists for it (Blincoe, 2014).

Broader connections

Coordination across teams depends on what the parties already share, which is the subject of Common ground; the finding that shared team knowledge reduces the harm of distance is one instance. The problem of bounding and prioritising newly discovered questions, and arbitrating between workers, reappears in Multi-agent research systems, where a coordinator plays a role like that of a cross-team decision owner. How a person gets a decision made through a hierarchy, and what they can do to influence it, is covered in Manager–employee relationships.

Further reading

• Cataldo and Herbsleb (2013): a quantified study of coordination gaps in two industrial projects; read alongside Mauerer et al. (2021), which found no such link in 25 open-source projects.
• Dingsøyr et al. (2018): a four-year, 12-team program and the mechanisms it used, including informal decision handling.
• Moe et al. (2021): top-down and bottom-up alignment in two telecom cases, and the control versus autonomy tension.
• Herbsleb and Mockus (2003): measured delays from needing information or a decision from someone elsewhere.
• Tkalich et al. (2025): interviews on critical dependencies, with the finding that severe bottlenecks sat at interfaces with support functions and suppliers.
• Lastro and Schuster (2024): a thesis on cross-team decision-making in a large-scale agile firm.