Hur utformar du organisations- och teamstruktur?

Question

Accepted Answer

Organisationsutformning handlar om **att dra teamgränser så att arbete som förändras tillsammans finns tillsammans** — minimera beroenden mellan team för saker som förändras snabbt. Strukturen bör följa strategi och system, inte tvärtom.

## Principer

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

## Flödesorienterad tänkande

Favoritisera långlivade, flödesorienterade team som äger ett arbetsflöde, stödda av plattformteam som minskar andras kognitiv belastning. Reorganisera när strukturen börjar kämpa mot arbetet — inte på en nyck.

## Fallgropar

- **Funktionella silos** (ett "QA-team," ett "frontend-team") som tvingar varje funktion att gå genom många övergångar.
- **Ignorera Conways lag** och bli överraskad att arkitekturen speglar organisationsschemat.
- **Ständig omorganisering**, vilket återställer förtroende och ägarskap varje gång.
- **Diffus ägarskap**, där allt är "delat" och därför ägs av ingen.

## Varför det är viktigt

Strukturen bestämmer tyst hastighet.

Dåliga gränser skapar oändliga koordineringsmöten och suddig ansvar; bra sådana låter team röra sig oberoende.

På grund av Conways lag är organisationsutformning *också* arkitekturdesign.

Om du får teamgränserna fel, kommer ingen mängd ingenjörsheroism att göra systemet rent.