Skip to content
    RU
    Architecture & organization designChapter 13

    Orchestration and Choreography for Teams

    Two coordination models for engineering work: centralized control and autonomous response to explicit shared rules.

    Original guideworking20 minevergreen · reviewed Aug 13, 2026
    Tech Lead
    Engineering Manager
    Chapter outline

    Brief

    The essential idea

    Borrowing from distributed systems, orchestration uses a central coordinator that issues commands, tracks status, and selects the next step; choreography lets participants respond autonomously to events under shared contracts. Orchestration provides a clear end-to-end view and accountability but can create a coordination bottleneck, while choreography scales ownership but depends on observable state and strong policies.

    Unique initiatives with deadlines, budgets, and critical paths often need more orchestration; repeatable product flow is usually better served by choreography and management by exception. Scrum can drift toward ritualized orchestration, whereas Kanban's visible flow, WIP limits, explicit policies, and feedback loops can support choreography when the rules are simple and reinforced by automation.

    Decision lens

    Key takeaways

    Orchestration centralizes sequencing and decisions; choreography distributes action through shared events and policies.

    A coordinator can simplify local reasoning but becomes a bottleneck when every team waits for instructions.

    Choreography improves organizational scale and ownership but requires transparent contracts and system state.

    Projects and high-risk one-off initiatives often justify orchestration; repeatable product processes benefit from choreography.

    WIP limits, definitions of ready and done, SLAs, and transition policies should be explicit and machine-checkable where possible.

    A leader's job is to design and improve the flow system, not manually conduct every step.

    Workplace experiment

    Apply it at work

    1. 1

      Map the current value flow from request to release and mark every point where work waits for a coordinator.

    2. 2

      Define WIP limits, transition policies, response SLAs, and definitions of ready and done for the main flow.

    3. 3

      Move one recurring enforcement task into a bot, CI check, or event-driven notification.

    4. 4

      Track lead time, throughput, and aging rather than individual utilization.

    5. 5

      Change one policy at a time, measure the effect, and use the result to choose the next experiment.

    Choose one action, define the observable effect, and keep the first test small enough to reverse.

    Evidence

    Sources and further reading

    Additional sources

    Channel, aggregator, and commentary links confirm the work; they are not the primary source.

    Local knowledge map

    A small, typed neighborhood instead of the full-catalog graph.

    Contrasting ideaConway's Law
    Previous chapterPlatform TeamsNext chapterThe Boundaries of Reuse