Hvordan løser du arkitekturuenigheter på laget ditt?

Question

Accepted Answer

Smarte ingeniører vil være uenige om arkitektur, det er sunt. Jobben til TL er å gjøre uenigheten om til **en god beslutning og et engasjert lag**, ikke å vinne argumentet. De fleste tvister løser seg når alle blir enige om kriteriene.

## En prosess for å 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 diskuterer microservices vs. monolitt. Du omformulerer: "Hva optimaliserer vi for i løpet av neste år?" Svaret, å levere raskt med et lite lag, gjør monolitten til det åpenbare valget. Argumentet handlet egentlig om ustilte mål.

## Når skal du beslutte vs. utsette

For reversible beslutninger, velg raskt og gå videre, kostnaden ved å beslutte feil er liten. For enveies dører, bremse opp og samle data. Å matche grundighet med reversibilitet unngår både bikeshedding og tankeløse beslutninger.

## En felle

La ikke senioriteten din stenge ned debatt, eller la debatten løpe for alltid. Begge deler skader lag: det ene dyrker sinne, det andre lammer.

## Hvorfor det betyr noe

Uløste arkitekturkonflikter blir værende og splitter lag i leire.

En TL som legger til rette på en rettferdig måte, og så bestemmer, får både en solid design og et lag som eier den sammen, selv de som argumenterte for den andre siden.