Hoe ontwerp je een organisatie- en teamstructuur?

Question

Accepted Answer

Organisatieontwerp gaat over **teamgrenzen trekken zodat werk dat samen verandert ook samen leeft** — cross-team afhankelijkheden minimaliseren voor dingen die snel veranderen. De structuur moet strategie en het systeem volgen, niet andersom.

## Principes

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

Gun de voorkeur aan langdurige, stream-aligned teams die eigenaar zijn van een workflow, ondersteund door platform teams die de cognitieve belasting van anderen verminderen. Herorganiseer wanneer de structuur tegen het werk ingaat — niet op een gril.

## Valkuilen

- **Functionele silo's** (een "QA team," een "frontend team") die elk feature over veel overdrachten dwingen.
- **Conway's Law negeren** en verbaasd zijn dat de architectuur de org chart weerspiegelt.
- **Constant herorganiseren**, wat vertrouwen en eigenaarschap elke keer reset.
- **Vage eigenaarschap**, waar alles "gedeeld" is en daarom niemand eigenaar is.

## Waarom het belangrijk is

Structuur bepaalt stilletjes snelheid.

Slechte grenzen creëren eindeloze coördinatievergaderingen en onduidelijke verantwoordelijkheid; goede grenzen stellen teams in staat onafhankelijk te werken.

Vanwege Conway's Law is organisatieontwerp *architectuurontwerp*.

Als je de teamgrenzen verkeerd bepaalt, zal geen enkel ingenieurstechnik het systeem schoon maken.