Technische Führung: Aus einer Meinungsverschiedenheit eine testbare Entscheidung machen

Ammar Najjar · Veröffentlicht am 1. Oktober 2026 · 5 Min. Lesezeitleadership

Vor Kurzem war ich in einer technischen Diskussion, die sich zunehmend um denselben Punkt drehte. Wir überlegten, wie wir einen Teil einer Frontend-Anwendung strukturieren sollten, und hatten zwei Ansätze, für die es jeweils gute Argumente gab. Der eine versprach eine klarere Trennung und eine konsistentere Struktur. Beim anderen stand die Sorge im Raum, dass wir diese Struktur mit zusätzlicher Indirektion bezahlen und spätere Änderungen dadurch schwerer nachvollziehbar machen würden.

Wir nahmen uns Zeit, beide Positionen durchzugehen, Annahmen zu hinterfragen und mögliche Konsequenzen zu betrachten. Dieser Teil der Diskussion war hilfreich, weil dadurch klarer wurde, woher die unterschiedlichen Einschätzungen kamen. Irgendwann bemerkte ich jedoch, dass wir hauptsächlich Varianten bereits bekannter Argumente wiederholten. Es war keine neue Einschränkung aufgetaucht, die eine der Optionen ausgeschlossen hätte, und keine Seite hatte genügend konkrete Anhaltspunkte dafür, dass die jeweiligen Bedenken tatsächlich eintreten würden.

An diesem Punkt war es unwahrscheinlich, dass uns eine weitere Diskussionsrunde neue Erkenntnisse bringen würde. Was uns fehlte, waren konkrete Erkenntnisse in Bezug auf das Problem, das wir lösen wollten.

KI-generiertes Bild

Von Positionen zu konkreten Erkenntnissen

Ich schlug vor, die Entscheidung nicht weiter in der Diskussion erzwingen zu wollen. Stattdessen wollten wir herausfinden, was wir sehen oder lernen müssten, um sie mit größerer Sicherheit treffen zu können. Die Frage war damit nicht mehr, wer das überzeugendere Argument hatte. Wir konzentrierten uns darauf, was noch unklar war und wie wir einen Teil dieser Unsicherheit konkret untersuchen konnten.

Das knüpft direkt an meinen Artikel darüber an, eine Praktik vom eigentlichen Problem zu trennen. Wenn Problem, gewünschtes Ergebnis und Rahmenbedingungen klar sind, helfen sie auch dabei zu bestimmen, welche Erkenntnisse für die Entscheidung relevant sind. Geht es beispielsweise um Wartbarkeit, könnten wir untersuchen, wie leicht sich eine Implementierung verstehen und verändern lässt, welchen Testaufwand sie verursacht oder wie sich Fehler auswirken. Bei einem anderen Problem wären entsprechend andere Kriterien relevant.

Der nächste Schritt bestand darin, das Experiment bewusst klein zu halten. Wir brauchten keine Implementierung, die beweist, dass einer der Ansätze überall funktioniert. Sie musste lediglich groß genug sein, um die Unsicherheiten zu untersuchen, die uns an der Entscheidung hinderten.

Die Kriterien vor dem Experiment festlegen

Aus solchen Situationen habe ich gelernt, dass die Kriterien vor dem Experiment feststehen sollten. Bevor wir einen Spike starten, möchte ich mit dem Team klären, was wir daraus lernen wollen.

Andernfalls ist es leicht, zunächst etwas zu bauen und erst danach festzulegen, welche Aspekte des Ergebnisses relevant sind. Beide Seiten können dasselbe Experiment dann durch die Annahmen interpretieren, die sie bereits vorher hatten. Deshalb versuche ich, die Kriterien vor Beginn der Arbeit explizit zu machen: Was wollen wir untersuchen, und welche Beobachtungen würden dafür sprechen, eine der Optionen zu bevorzugen?

Bei einer Frontend-Entscheidung dieser Art könnte das bedeuten, einen repräsentativen Teil der Anwendung mit beiden Ansätzen umzusetzen und die Ergebnisse anschließend gemeinsam zu betrachten. Dann können wir anhand des tatsächlich entstandenen Codes diskutieren, wie gut eine Änderung nachvollziehbar ist, welchen Testaufwand sie erfordert und an welchen Stellen zusätzliche Komplexität entsteht. Die Kriterien ergeben sich aus dem ursprünglichen Problem und nicht aus einer allgemeinen Checkliste.

Hier passt auch mein Artikel darüber, Autonomie mit einem zeitlichen Rahmen zu verbinden. Ein Experiment braucht einen klaren Rahmen und einen festgelegten Zeitpunkt für die gemeinsame Auswertung. Innerhalb dieses Rahmens entscheidet das Team, wie es die Alternativen untersucht. Gleichzeitig wissen alle, wann das Experiment endet und welche Frage es beantworten soll.

Das Ergebnis gemeinsam betrachten

Für mich ist die anschließende gemeinsame Auswertung entscheidend. Das Team kommt mit etwas Konkretem zur ursprünglichen Entscheidung zurück. Wir können dieselbe Implementierung betrachten, dieselben Trade-offs diskutieren und unsere Beobachtungen mit den Kriterien vergleichen, auf die wir uns geeinigt hatten, bevor wir das Ergebnis kannten.

Die Entscheidung kann weiterhin Abwägung erfordern. Technische Entscheidungen lassen sich selten auf eine einzelne Kennzahl reduzieren, und ein Experiment kann neue Trade-offs sichtbar machen, anstatt eine eindeutige Antwort zu liefern. Trotzdem hat das Team anschließend eine bessere Grundlage für die Entscheidung. Jemand, der eine Option klar bevorzugt hat, kann mit der endgültigen Entscheidung weiterhin nicht einverstanden sein. Die Grundlage dieser Entscheidung ist jedoch für alle sichtbar und gemeinsam nachvollziehbar. Das ist die Team-Version des Wechsels, den ich in Thinking, Fast and Slow beschreibe: Wenn die Urteilsbildung intuitiv wirkt und das Team bereits eine Präferenz hat, hilft es, den Prozess zu verlangsamen und die Uneinigkeit testbar zu machen, statt dem stärkeren Argument nachzugeben.

Die Frage, die ich heute stelle

Diese Erfahrung hat mir einen hilfreichen Hinweis für Diskussionen gegeben, die anfangen, sich im Kreis zu drehen. Wenn die Annahmen verstanden sind, die nachvollziehbaren Argumente auf dem Tisch liegen und eine weitere Runde wahrscheinlich keine neuen Erkenntnisse bringt, frage ich:

Was ist das kleinste Experiment oder der kleinste konkrete Nachweis, der uns bei dieser Entscheidung weiterhelfen würde?

Mich interessiert, wie andere mit solchen Situationen umgehen. Wenn nach der Klärung der Annahmen zwei nachvollziehbare technische Positionen bestehen bleiben, welches kleine Experiment hat eurem Team geholfen, zu einer Entscheidung zu kommen? Schreib es gerne in die Kommentare oder melde dich direkt.

Ich lese jede Antwort.