Wie gestalten Sie die Organisations- und Teamstruktur?

Question

Accepted Answer

Organisationsdesign bedeutet, **Teamgrenzen zu ziehen, sodass die Arbeit, die sich zusammen ändert, zusammen lebt** — Minimierung von teamübergreifenden Abhängigkeiten für die Dinge, die sich schnell bewegen. Die Struktur sollte der Strategie und dem System folgen, nicht umgekehrt.

## Warum es wichtig ist

```text
1. TEAMS OWN OUTCOMES, not layers (a team owns a product/domain end to end)
2. MINIMIZE DEPENDENCIES — autonomous teams ship faster
3. CONWAY'S LAW — your architecture will mirror your org; design both together
4. CLEAR OWNERSHIP — every critical area has ONE owning team
5. RIGHT SIZE — ~5–9 people; two-pizza teams
6. COGNITIVE LOAD — don't give one team more domains than it can hold
```

## Stream-aligned denken

Bevorzugen Sie langlebige, stream-aligned Teams, die einen Workflow besitzen und von Platform Teams unterstützt werden, die die kognitive Last anderer reduzieren. Reorganisieren Sie, wenn die Struktur anfängt, gegen die Arbeit zu kämpfen — nicht aus einer Laune heraus.

## Fallstricke

- **Funktionale Silos** (ein "QA-Team," ein "Frontend-Team"), die jede Funktion durch viele Übergaben zwingen.
- **Conways Gesetz ignorieren** und überrascht sein, dass die Architektur das Organigramm widerspiegelt.
- **Ständige Reorganisationen**, die jedes Mal Vertrauen und Eigenverantwortung zurücksetzen.
- **Verschwommenes Eigentum**, wo alles "geteilt" ist und daher niemand eigenverantwortlich ist.

## Warum es wichtig ist

Struktur bestimmt die Geschwindigkeit im Stillen.

Schlechte Grenzen erzeugen endlose Koordinationstreffen und verschwommene Verantwortung; gute Grenzen ermöglichen es Teams, unabhängig zu arbeiten.

Wegen Conways Gesetz ist Organisationsdesign *ist* Architekturdesign.

Wenn Sie die Teamgrenzen falsch setzen, werden auch noch so viele technische Leistungen das System nicht sauber machen.