Technische Führung: Trenne die Praxis von dem Problem, das sie lösen soll

Ammar Najjar · Veröffentlicht am 28. September 2026 · 3 Min. Lesezeitleadership

KI-generiertes Bild

Mir ist kürzlich aufgefallen, wie schnell sich eine technische Diskussion auf eine bestimmte Praxis konzentrieren kann, obwohl ursprünglich ein ganz anderes Problem dahinterstand. In einem Teamgespräch ging es darum, ob wir Test-driven Development einführen sollten. Die Diskussion hätte leicht in den üblichen Austausch über TDD übergehen können: Vorteile, zusätzlicher Aufwand und die Frage, ob diese Arbeitsweise zum Team passt.

Ich habe versucht, die Diskussion zunächst eine Ebene zurückzusetzen. Welches Problem wollen wir eigentlich angehen? Woran würden wir erkennen, dass wir tatsächlich Fortschritt gemacht haben?

Eine Ebene zurück

Sobald diese Fragen klar waren, hörte TDD auf, das Thema zu sein, zu dem jeder eine Position entwickeln musste, und wurde zu einer möglichen Vorgehensweise unter mehreren. Das Team konnte über das gewünschte Ergebnis nachdenken, ohne zuerst eine bestimmte Engineering-Praxis verteidigen oder ablehnen zu müssen. Auch ein eher stilles Teammitglied brachte eine andere Perspektive ein. Am Ende entschied sich das Team zu diesem Zeitpunkt gegen TDD und für einen kleineren Schritt, bei dem die erwarteten Tests klarer beschrieben werden sollten.

KI-generiertes Bild

Für mich war interessant, dass die Diskussion trotzdem zu einer konkreten Handlung führte, obwohl der ursprüngliche Vorschlag verworfen wurde. Früher hätte ich das möglicherweise als gescheiterten Vorschlag gesehen. Heute betrachte ich es anders. Wenn das eigentliche Problem klarer wird und das Team einen Ansatz auswählt, den es selbst tragen kann, hat die Diskussion ihren Zweck erfüllt.

Das Problem behalten, die Lösung verändern

Dieses Muster begegnet mir häufig im Engineering. Wir sprechen über eine Testmethode, ein Architekturpattern, bessere Observability, eine andere Branching-Strategie oder ein neues Tool. Solche Ideen entstehen meist, weil jemand bereits eine Verbindung zu einem realen Problem erkannt hat. Sobald die vorgeschlagene Lösung jedoch zum Mittelpunkt wird, verschwindet diese ursprüngliche Begründung leicht aus dem Gespräch.

Als Technical Leader kann man helfen, sie wieder sichtbar zu machen. Drei Fragen finde ich dabei besonders hilfreich: Welches Problem beobachten wir? Woran würden wir erkennen, dass es sich verbessert hat? Welche Rahmenbedingungen sollten den ersten Versuch bestimmen? Das ist die Diskursebene eines Zugs, den ich in Autonomie mit einem zeitlichen Rahmen beschreibe: erst das Problem, das Ergebnis und die Rahmenbedingungen explizit machen, und der vorgeschlagene Ansatz wird eine Option, die man dagegen abwägt, statt das Thema der Diskussion. Mir ist dabei die Reihenfolge wichtig. Haltet zuerst Problem, gewünschtes Ergebnis und Rahmenbedingungen fest, und messt erst dann die vorgeschlagene Praxis gemeinsam mit kleineren oder ganz anderen Möglichkeiten am selben Ergebnis. Toyotas Problemlösungsmethode folgt derselben Reihenfolge: beobachten, Problem verstehen, Hypothese bilden, erst dann experimentieren (The Toyota Way). Die Praxis ist eine Hypothese unter mehreren, nicht das Ziel der Diskussion.

Das nimmt auch Druck von der Person, die den Vorschlag eingebracht hat. Die Idee muss sich nicht durchsetzen, damit das dahinterliegende Anliegen ernst genommen wird: Das Team kann das Problem behalten und die Lösung verändern.

Probiert im nächsten Gespräch über eine neue Praxis oder ein Tool aus, die ersten Minuten noch keine Bewertung vorzunehmen. Haltet zuerst Problem, gewünschtes Ergebnis und relevante Rahmenbedingungen fest und kommt anschließend zur eigentlichen Idee zurück.

Die Frage, die ich heute stelle

Wenn ein Team eine vorgeschlagene Engineering-Praxis ablehnt, wie stellt ihr sicher, dass das zugrunde liegende Problem nicht gleich mit verschwindet?

Wenn du schon einmal ausprobiert hast, ein Gespräch zuerst auf das Problem zurückzuführen: Was hast du dabei beobachtet? Schreib es gerne in die Kommentare oder melde dich direkt.

Ich lese jede Antwort.