---
name: cross-team-coordination
description: Keep work moving across team boundaries with explicit interfaces, owners, and shared checkpoints. Use when a project spans teams and progress stalls at handoffs.
---

# Cross-team coordination

Work crossing a team boundary queues by default, because each team
prioritises its own commitments. Coordination is making the shared work
visible enough that it does not sit invisibly in somebody's backlog.

## Method

1. **Agree the interface early.** What each team delivers to the other,
   in what form, and when, which lets teams work in parallel rather than
   in sequence (see api-change-management).
2. **Name a single owner per team.** One accountable person on each
   side, since coordination through whole teams means coordination
   through nobody.
3. **Make the dependency visible in both plans.** Work that exists in
   one team's plan and not the other's is the classic missed handoff
   (see agent-dependency-manager).
4. **Meet on a shared cadence with a decision output.** Regular short
   syncs that produce decisions, not status updates that could have been
   written.
5. **Escalate early and to the right level.** A dependency at risk needs
   the person who can reprioritise, and waiting until it is late removes
   their options (see agent-escalation-ladder).
6. **Write decisions where both teams can see them.** Decisions in one
   team's channel are invisible to the other and get relitigated.
7. **Design out the coupling where you can.** Contract-first interfaces
   and stubs let teams proceed independently, which beats coordinating
   better (see organizational-design).

## Boundaries

Coordination manages dependencies; it cannot fix an organisational
structure that creates too many (see organizational-design).
Coordination overhead grows with the number of teams, so fewer teams on
a project is usually faster. Competing priorities between teams need
resolution above them.