---
title: "Multi-Team Coordination"
description: "Dependency management between cloud teams: how platform teams, application teams and the business coordinate multiple workstreams in parallel — without bottlenecks and escalation cascades."
sidebar:
order: 9
label: "Multi-Team Coordination"
source_url: "https://framework.stackit.cloud/adoption/adapting-operating-models/multi-team-coordination/"
source_file: "docs/adoption/adapting-operating-models/multi-team-coordination.mdx"
---
## The coordination problem in cloud projects
Technically, a cloud migration is plannable. Organisationally, it rarely is. As soon as multiple teams work on the same platform in parallel, dependencies emerge that nobody fully sees at the start.
A common pattern: the application team waits for the platform team's landing zone. The platform team waits for the security team's IAM decision. The security team waits for the regulatory sign-off from compliance. Everyone is waiting — and the go-live date approaches.
This chapter describes how dependencies become visible early and how teams can work in parallel despite dependencies.
## The topology problem: why classical project structures fail
In classical IT projects, there is a project manager who knows and steers all dependencies. In cloud transformations, work is distributed across teams with different cadences, different priorities, and different incentive structures.
A platform team works in two-week sprints. A compliance team works in quarterly cycles. An application team works according to a product roadmap. These three rhythms systematically produce misalignment.
**The solution is not stronger central control — it is better visibility and clearer interfaces.**
## Four coordination mechanisms
### 1. Define team topology and interaction modes
Before teams work together, it should be clear: what is the relationship between them?
**Platform Team → application teams:** The Platform Team provides services (Kubernetes clusters, networking, IAM templates). Application teams consume these services. Interaction should run as much as possible through self-service interfaces (service catalogue, Terraform modules, documentation) — not through tickets.
**CCoE → all teams:** The CCoE sets standards, reviews architecture decisions, and supports on escalations. It is not an approval committee — it is an enabler with veto rights on critical security and compliance questions.
**Application teams with each other:** Shared-service dependencies (e.g. a central database used by multiple teams) are the most common coordination bottleneck. These should be explicitly treated as a "platform service" and operated by the responsible team as an internal product with an SLA.
### 2. Dependency board
A simple but effective instrument: a board (physical or digital) that visualises all cross-team dependencies.
| Dependency | Delivering team | Receiving team | Planned by | Status |
| ------------------------ | --------------- | ------------------ | ---------- | ----------- |
| Landing Zone Prod | Platform | App Team Billing | Week 14 | in progress |
| IAM role concept | Security | Platform | Week 12 | blocked |
| Data protection approval | Compliance | App Team CRM | Week 16 | pending |
| CI/CD Pipeline Template | Platform | App Team Logistics | Week 13 | ready |
The dependency board is updated weekly. Blockages become visible immediately — before they become a bottleneck.
### 3. Regular sync formats
15 minutes daily. What was done yesterday? What is planned today? What is blocking? Blockages
with cross-team dependencies are escalated immediately — not as a ticket, but as direct contact.
45 minutes. Platform Team presents: what is newly available? What is coming in the next two
weeks? Which changes have breaking-change potential? All application teams are represented.
30 minutes. Review of the dependency board. Which dependencies are open, which are escalating?
Decisions on shifts are made here, not via email.
Management, CIO, tech leads. Status of the overall migration, strategic course adjustments,
resource decisions. No detailed discussions — only decisions.
### 4. Inner Source principle for platform components
When all teams use the same STACKIT infrastructure, a shared code-base effect emerges: Terraform modules, Helm charts, and CI/CD templates are developed twice.
Inner Source means: platform components are shared internally like open-source projects. Every team can contribute. The Platform Team maintains and reviews. Result: no duplicates, faster iteration, shared quality awareness.
In practice: an internal git repository with Terraform modules for STACKIT resources, versioned and documented. Application teams use, improve, and share back.
## When coordination escalates
Sometimes processes are not enough. Then clear escalation paths are needed.
**Escalation trigger:** A cross-team dependency has been blocked for two weeks and has put a go-live date at risk.
**Escalation path:**
1. Direct conversation between the affected team leads: 24-hour deadline for resolution
2. If no result: involvement of the CCoE as neutral mediator
3. If no result: steering committee makes the decision — with all consequences
**What should never happen:** Resolving blockages through email ping-pong without a defined escalation point. Time pressure does not solve structural dependency problems.
## Implementation steps
1. **Document team topology** — Who works with whom? In what mode (collaboration, X-as-a-Service, facilitating)? In writing, as the basis for all other coordination formats.
2. **Set up the dependency board** — Start simply: a table in Confluence or Jira is sufficient. Important: a weekly review date in the calendar.
3. **Establish sync formats** — Create platform sync and dependency review as recurring appointments. Create agenda templates.
4. **Communicate the escalation path** — All teams know who to escalate to and when. Not as a threat, but as a safety net.
5. **Create an Inner Source repository** — Start with the Terraform module that most teams need. Document how contributions are made.