Zwei Senior Engineers sind sich bei einer Architekturentscheidung heftig uneinig und die Arbeit steht. Was machst du?

Mach die Uneinigkeit explizit und zeitlich begrenzt. Lass beide Positionen mit Trade-offs und den zugrunde liegenden Annahmen aufschreiben, dann identifiziere, welche Annahmen sich mit einem Spike oder Benchmark billig testen lassen. Setz ein Entscheidungsdatum. Klärt die Evidenz es nicht, entscheidest du, erklärst die Begründung offen und hältst die Wahl, wo möglich, umkehrbar, damit Irren billig bleibt.

Das Erste, was ich mache, ist ein Datum drauf zu setzen, denn unbegrenzte Architekturdebatte ist teuer und das wissen beide. Dann bitte ich jeden um eine Seite: der Ansatz, die Trade-offs und vor allem die Annahmen, auf denen er beruht. In neun von zehn Fällen geht es gar nicht ums Design, sondern um eine versteckte Annahme zu Last, zu Teamfähigkeiten oder dazu, wohin das Produkt in einem Jahr geht. Beim letzten Mal lief es darauf hinaus, ob wir binnen achtzehn Monaten Multi-Region brauchen würden, und das ist eine Produktfrage, keine Engineering-Frage, also habe ich den Product Lead dazugeholt und es war in zwanzig Minuten geklärt. Wenn es wirklich technisch ist, frage ich nach dem billigsten Experiment, und wir stecken zwei Tage in einen Benchmark statt zwei Wochen in Meinungen. Steht es zur Deadline immer noch unentschieden, entscheide ich, schreibe auf warum, und sage klar, dass es knapp war und was uns dazu bringen würde, das neu zu bewerten. Danach sorge ich dafür, dass die Person, deren Ansatz nicht gewonnen hat, etwas Substanzielles im Bau verantwortet.