Hoe los je architectuurdiscrepanties op in je team?

Question

Accepted Answer

Slimme engineers zullen het oneens zijn over architectuur, dat is gezond. De taak van de TL is om meningsverschillen om te zetten in **een goede beslissing en een team dat eraan committed is**, niet om het argument te winnen. De meeste geschillen verdwijnen zodra iedereen het eens is over de criteria.

## Een proces om het op te lossen

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

## Een concreet voorbeeld

Twee engineers discussiëren over microservices versus monoliet. Je formuleert het opnieuw: "Waar optimaliseren we voor in het komende jaar?" Het antwoord, snel uitbrengen met een klein team, maakt de monoliet de voor de hand liggende keuze. Het argument ging echt over onuitgesproken doelstellingen.

## Wanneer je beslist versus uitstelt

Voor omkeerbare beslissingen: kies snel en ga verder, de kosten van een verkeerde beslissing zijn klein. Voor één-richtingskeuzes: ga langzamer en verzamel gegevens. Het aanpassen van de mate van deliberatie aan omkeerzbaarheid voorkomt zowel bikeshedding als roekeloze keuzes.

## Een valkuil

Laat je anciënniteit het debat niet de mond snoeren, en laat debat niet eeuwig voortduren. Beide zijn slecht voor teams: het eerste kweeekt rancune, het tweede verlamming.

## Waarom het belangrijk is

Onopgeloste architectuurdiscussies etteren en verdelen teams in kampen.

Een TL die eerlijk faciliteert en vervolgens beslist, krijgt zowel een goed ontwerp als een team dat het samen draagt, zelfs degenen die de andere kant hebben verdedigd.