Hur löser du arkitekturmöjligheter på ditt team?

Question

Accepted Answer

Smarta ingenjörer kommer att vara oense om arkitektur, det är hälsosamt. TL:s jobb är att förvandla oenighet till **ett bra beslut och ett engagerat team**, inte att vinna argumentet. De flesta tvister löses när alla är överens om kriterierna.

## En process för att lösa 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
```

## Ett konkret exempel

Två ingenjörer debatterar mikrotjänster vs. monolith. Du omformar: "Vad optimerar vi för under nästa år?" Svaret, snabb leverans med ett litet team, gör monolithen till det uppenbara valet. Argumentet handlade egentligen om outtalade mål.

## När man ska besluta vs. skjuta upp

För reversibla beslut, välj ett snabbt och gå vidare, kostnaden för att besluta fel är liten. För envägsdörrar, bromsa in och samla data. Att matcha övervägande till reversibilitet undviker både bikeshedding och tanklösa samtal.

## En fallgrop

Låt inte din anciennitet stänga av debatt, eller låt debatten pågå för alltid. Båda dödar team: en avlar missnöje, den andra framkallar förlamning.

## Varför det är viktigt

Olösta arkitekturkonflikter försvinner och delar team i läger.

En TL som underlättar rättvist, sedan beslutar, får både en sunt design och ett team som äger det tillsammans, även de som argumenterade för den andra sidan.