Como você resolve desacordos arquiteturais em seu time?

Question

Accepted Answer

Engenheiros inteligentes vão discordar sobre arquitetura, isso é saudável. O trabalho do TL é transformar desacordo em **uma boa decisão e um time comprometido**, não ganhar a discussão. A maioria das disputas se dissolve uma vez que todos concordam com os critérios.

## Um processo para resolver

```text
1. AGREE on the criteria first — what are we optimizing for?
   (scale, simplicity, time-to-ship, team familiarity)
2. Let each side make its STRONGEST case — steelman, don't strawman
3. Look for DATA — spike it, benchmark it, prototype it
4. If still tied — the TL decides, and explains why
5. DISAGREE AND COMMIT — once decided, everyone rows together
```

## Um exemplo concreto

Dois engenheiros discutem microsserviços vs. monolito. Você reformula: "O que estamos otimizando no próximo ano?" A resposta, entregar rápido com um time pequeno, torna o monolito a escolha óbvia. A discussão era realmente sobre objetivos não explícitos.

## Quando decidir vs. adiar

Para decisões reversíveis, escolha uma rapidamente e avance, o custo de decidir errado é pequeno. Para portas de mão única, vá devagar e colete dados. Alinhar deliberação com reversibilidade evita tanto bikeshedding quanto decisões precipitadas.

## Uma armadilha

Não deixe sua senioridade encerrar o debate, ou deixe o debate durar para sempre. Ambos matam times: um gera ressentimento, o outro causa paralisia.

## Por que isso importa

Brigasmde arquitetura não resolvidas fermentam e dividem times em acampamentos.

Um TL que facilita com justiça, então decide, consegue tanto um design sólido quanto um time que o possui junto, até aqueles que discutiram pelo outro lado.