Como você projeta a estrutura da organização e do time?

Question

Accepted Answer

O design organizacional é sobre **desenhar limites de time para que o trabalho que muda junto viva junto** — minimizando dependências entre times para as coisas que se movem rápido. A estrutura deve seguir a estratégia e o sistema, não o contrário.

## Princípios

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

## Pensamento orientado a fluxo

Favoreça times de longa duração, orientados a fluxo, que possuem um fluxo de trabalho, apoiados por times de plataforma que reduzem a carga cognitiva dos outros. Reorganize quando a estrutura começar a lutar contra o trabalho — não por capricho.

## Armadilhas

- **Silos funcionais** (um "time de QA," um "time de frontend") que forçam cada recurso a passar por muitas transições.
- **Ignorar a Lei de Conway** e ficar surpreso que a arquitetura espelha o organograma.
- **Reorganizar constantemente**, o que reseta confiança e responsabilidade a cada vez.
- **Propriedade vaga**, onde tudo é "compartilhado" e portanto possuído por ninguém.

## Por que isso importa

A estrutura determina silenciosamente a velocidade.

Limites ruins criam reuniões de coordenação intermináveis e responsabilidade turva; os bons permitem que os times se movam de forma independente.

Por causa da Lei de Conway, design organizacional *é* design de arquitetura.

Acerte errado os limites do time e nenhuma quantidade de heroísmo de engenharia tornará o sistema limpo.