Hvordan løser du arkitektur uenigheder i dit team?

Question

Accepted Answer

Smarte ingeniører vil være uenige om arkitektur, det er sundt. TL's job er at gøre uenighed til en **god beslutning og et engageret team**, ikke at vinde argumentet. De fleste tvister løser sig, når alle er enige om kriterierne.

## En proces til at løse det

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

## Et konkret eksempel

To ingeniører argumenterer microservices vs. monolith. Du omformulerer: "Hvad optimerer vi for det kommende år?" Svaret, at levere hurtigt med et lille team, gør monolithen til det åbenlyse valg. Argumentet handlede egentlig om uudsagte mål.

## Hvornår skal man beslutte vs. udskyde

For reversible beslutninger, vælg hurtigt og fortsæt, omkostningen ved at beslutte forkert er lille. For envejsdørpolitik, sænk farten og indsaml data. Matchning af overvejelse til reversibilitet undgår både spild af tid og uovervejet beslutninger.

## En fælde

Lad ikke din senioritet lukke debatten, eller lad debatten løbe evigt. Begge deler ødelægger teams: den ene avler modvilje, den anden avler lammelse.

## Hvorfor det betyder noget

Uløste arkitektur stridigheder gærer og splittet teams i lejre.

En TL der faciliterer retfærdigt, og så beslutter, får både et solidt design og et team der ejer det sammen, selv dem der argumenterede på den anden side.