Come progetti la struttura organizzativa e dei team?

Question

Accepted Answer

La progettazione organizzativa riguarda **tracciare i confini dei team in modo che il lavoro che cambia insieme stia insieme** — riducendo al minimo le dipendenze cross-team per le cose che si muovono velocemente. La struttura dovrebbe seguire la strategia e il sistema, non il contrario.

## Principi

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

## Pensiero stream-aligned

Favorisci team durature e stream-aligned che possiedono un flusso di lavoro, supportati da platform team che riducono il carico cognitivo degli altri. Riorganizza quando la struttura inizia a lottare contro il lavoro — non su un capriccio.

## Insidie

- **Silo funzionali** (un "team QA", un "team frontend") che forzano ogni feature ad attraversare molti handoff.
- **Ignorare la Legge di Conway** e restare sorpresi che l'architettura rispecchi l'organigramma.
- **Riorganizzare costantemente**, il che azzera la fiducia e la proprietà ogni volta.
- **Proprietà vaga**, dove tutto è "condiviso" e quindi di proprietà di nessuno.

## Perché è importante

La struttura determina silenziosamente la velocità.

Confini scadenti creano riunioni di coordinamento senza fine e responsabilità annebbiata; quelli buoni permettono ai team di muoversi indipendentemente.

A causa della Legge di Conway, la progettazione organizzativa *è* progettazione dell'architettura.

Sbaglia i confini dei team e nessuna quantità di eroismo ingegneristico renderà il sistema pulito.