Hvordan utformer du organisasjons- og teamstruktur?

Question

Accepted Answer

Organisasjonsutforming handler om **å tegne teamgrenser slik at arbeidet som endres sammen lever sammen** — minimalisere tverrteam-avhengigheter for ting som beveger seg raskt. Strukturen bør følge strategi og systemet, ikke omvendt.

## Prinsipper

```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 tenking

Favoriser langvarige, stream-aligned team som eier en arbeidsflyt, støttet av platformteam som reduserer andres kognitiv belastning. Omorganiser når strukturen begynner å kjempe mot arbeidet — ikke på et innfall.

## Fallgruver

- **Funksjonelle siloer** (et "QA-team," et "frontend-team") som tvinger hver funksjon over mange handover.
- **Ignorere Conways lov** og bli overrasket over at arkitekturen gjenspeiler organisasjonsskjemaet.
- **Konstant omorganisering**, som tilbakestiller tillit og eierskap hver gang.
- **Uklar eierskap**, hvor alt er "delt" og derfor eies av ingen.

## Hvorfor det er viktig

Strukturen bestemmer farten i det stille.

Dårlige grenser skaper endeløse koordineringsmøter og uklar ansvarlighet; gode grenser lar team bevege seg uavhengig.

På grunn av Conways lov er organisasjonsutforming *arkitekturdesign*.

Få teamgrensene feil og ingen mengde ingeniørkompetanse vil gjøre systemet rent.