Hvordan designer du organisations- og teamstruktur?

Question

Accepted Answer

Organisationsdesign handler om **at tegne teamgrænser, så det arbejde, der ændres sammen, lever sammen** — minimering af tværteams-afhængigheder for de ting, der bevæger sig hurtigt. Strukturen bør følge strategi og systemet, ikke omvendt.

## Principper

```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 tænkning

Gunst for langvarige, stream-aligned teams, der ejer en arbejdsstrøm, understøttet af platformteams, der reducerer andres kognitiv belastning. Reorganiser, når strukturen begynder at kæmpe mod arbejdet — ikke på et indfald.

## Faldgruber

- **Funktionelle siloer** (et "QA-team," et "frontend-team"), der tvinger hver funktion til at krydse mange overdragelser.
- **At ignorere Conways lov** og blive overrasket over, at arkitekturen afspejler organiseringsskemaet.
- **Konstant reorganisering**, som nulstiller tillid og ejerskab hver gang.
- **Uklart ejerskab**, hvor alt er "delt" og derfor ejet af ingen.

## Hvorfor det betyder noget

Struktur bestemmer stilfærdighedens hastighed.

Dårlige grænser skaber endeløse koordinationsmøder og sløret ansvar; gode grænser lader teams bevæge sig uafhængigt.

På grund af Conways lov er organisationsdesign *er* arkitekturdesign.

Få teamgrænserne forkert, og ingen mængde ingeniørhandlinger gør systemet rent.