Der Engpass wandert vom Tippen zum Entscheiden

In vielen Tech-Organisationen macht sich gerade eine bequeme Annahme breit: Wenn KI eigenständig Code erzeugen, Legacy-Systeme erklären, Tests schreiben und Dokumentationen verfassen kann, wird technische Führung weniger wichtig.

Ich halte das exakte Gegenteil für richtig.

KI verkleinert die Führungsaufgabe nicht. Sie legt die Messlatte deutlich höher.

Solange die reine Implementierung der größte Engpass ist, kann sich fehlendes Urteilsvermögen eine Weile verstecken. Schlechte Architekturentscheidungen brauchen Zeit, bis sie in fertigen Code gegossen sind – das lässt Raum, um Probleme noch abzufangen. Wird die Umsetzung plötzlich drastisch beschleunigt, wird schwaches Urteilsvermögen viel schneller und gnadenloser sichtbar. Teams können mehr produzieren, doch damit rückt die eigentlich schwere Frage in den Mittelpunkt: Was genau sollten wir bauen, woher wissen wir, dass es gut ist, und wer trägt die Verantwortung für diese Entscheidung?

Der Engpass wandert vom Tippen zum Entscheiden.

Engineering-Führung wird umso wichtiger, je mehr die reine Umsetzung zur Commodity wird.

Schnellerer Code in derselben Delivery-Pipeline

Die meisten Tech-Organisationen greifen in der Diskussion um die KI-Einführung zu kurz: Sie fragen primär, wie viel schneller Entwickler damit Code schreiben können.

Diese Frage ist legitim, aber unvollständig. Sie unterstellt, dass der Rest des Entwicklungsprozesses unverändert bleiben kann.

Ein Team, das seinen Code doppelt so schnell generiert, aber weiterhin durch unklare Anforderungen, langsame Reviews, fragile Staging-Umgebungen, überlastete Product Owner und zähe Release-Freigaben ausgebremst wird, hat den Gesamtprozess nicht beschleunigt. Es hat den Stau lediglich an eine andere Stelle verschoben. Womöglich hat es sogar neue Fehlerquellen ins System geholt: plausibel klingende, aber sachlich falsche Erklärungen; Tests, die lediglich den geschriebenen Code statt der eigentlichen Business-Anforderung bestätigen; und Sicherheitslücken, die sich in souverän formulierten KI-Ausgaben verstecken.

Beim Bau einer iOS-App, die ich überwiegend mit KI entwickelt habe, wurde dieser Effekt überdeutlich. Der größte Gewinn war nicht das schnellere Tippen. Er bestand darin, von einer vagen Idee rasend schnell zu strukturierten, priorisierten und umsetzbaren Arbeitspaketen zu kommen. Sobald die konzeptionelle Arbeit glasklar war, verlief die eigentliche Umsetzung extrem unspektakulär.

KI verändert den Zuschnitt des gesamten Delivery-Prozesses, nicht nur das reine Entwicklungstempo.

Genau diese Verschiebung muss das Management aktiv gestalten. Die Frage lautet nicht länger nur: „Wie helfen wir unseren Leuten, schneller zu coden?“ Sie lautet: Wie verändert KI die Anforderungsanalyse, das Systemdesign, das Testing, Code-Reviews, Incident Management und das Onboarding? Und wie gestalten wir diese Workflows neu, ohne Abstriche bei der Code-Verantwortung (Accountability) zu machen?

Fokus auf das Lernen richten

Teams lernen durch Rituale. In Stand-ups, Plannings, Code-Reviews und Retrospektiven verändert sich ganz praktisch, „wie wir arbeiten“.

Bleibt die KI-Nutzung jedoch in den privaten Chatverläufen der einzelnen Entwickler versteckt, lernt die Organisation im Schneckentempo — dieselbe Streuung, die aus einem Werkzeugkasten einen Tool-Wildwuchs macht. Ein Entwickler entdeckt einen genialen Weg, um Server-Logs zu parsen. Eine Kollegin findet einen effizienteren Ansatz für die Testgenerierung. Ein Dritter durchdringt dank KI endlich ein verstaubtes Legacy-Modul. Jeder verbessert sich lokal, aber das Team als Ganzes baut keine systematische Fähigkeit auf.

Engineering-Führungskräfte müssen dieses Wissen ans Licht holen.

Ich empfehle, bei den täglichen Gewohnheiten anzusetzen, statt das nächste abstrakte Schulungs-Deck auszurollen:

1. Den echten System-Engpass identifizieren: Analysieren Sie einmal im Monat die gesamte Delivery-Pipeline. Wenn KI bei der Code-Erzeugung hilft, verschiebt sich der Engpass vielleicht in die Konzeptionsphase, das PR-Review, die Testumgebungen oder in den Support. Finden Sie den neuen Stau, statt nur lokales Tempo zu feiern.
2. Die Anforderungsanalyse härter prüfen: Die Discovery-Phase muss künftig mehr Druck aushalten. Wenn die Umsetzung billiger wird, werden Fehlentscheidungen im Produktdesign teurer. Die falschen Features schneller zu bauen, stiftet auch weiterhin keinen Mehrwert.
3. Den Workflow ins Rampenlicht stellen, nicht nur das Ergebnis: Wenn jemand einen starken KI-Workflow findet, machen Sie den Weg dorthin transparent. Welcher Kontext wurde mitgegeben? Welche manuellen Prüfungen liefen danach? Welche Prompt-Bausteine lassen sich für das Team standardisieren?
4. KI zum Teil der bestehenden Austauschformate machen: Integrieren Sie KI aktiv in 1, Pair Programming, Code-Reviews und die persönliche Weiterentwicklung. Fragen Sie offen, welche Tätigkeiten die Entwickler an die KI delegieren, welche Fähigkeiten sie bewusst selbst trainieren wollen und wo den Tools noch zu blind vertraut wird.
5. Retrospektiven auf KI-Erfahrungen ausrichten: Fragen Sie nach größeren Releases oder Outages gezielt: Wo hat die KI uns beschleunigt? Wo hat sie uns in die Irre geführt? Welche Prüfschritte sollten künftig fester Bestandteil unserer Definition of Done werden?

Das ist kein Selbstzweck. Es geht darum, privates Silo-Wissen in echtes organisationales Lernen zu überführen, bevor jedes Scrum-Team das Rad auf seine eigene, halbgare Weise neu erfindet.

Psychologische Sicherheit ist ein Must Have

Die reine Werkzeug-Debatte übersieht oft die menschliche Komponente der KI-Transformation.

Einige Entwickler sind euphorisch, andere tief skeptisch. Manche haben Sorge, dass ihre Expertise abgewertet wird, wenn sie sich auf KI stützen. Andere fürchten, als Dinosaurier zu gelten, wenn sie es nicht tun. Junioren vertrauen KI-Ausgaben womöglich zu stark, weil ihnen noch die Erfahrung zur Bewertung fehlt. Senioren ignorieren die Tools, weil sie primär die Architekturrisiken sehen.

Hier gibt die Führung den Ton an.

Eine gesunde Botschaft lautet: „Wir lernen gemeinsam, KI verantwortungsvoll einzusetzen, um unsere Arbeit zu verbessern. Wir erwarten mutige Experimente, klare Belege, kritische Prüfungen und geteiltes Wissen.“

Das macht zwei Aussagen in Meetings gleichermaßen legitim: „Ich habe diesen Block mit KI generiert und ihn validiert“ sowie „KI war für dieses spezifische Refactoring absolut unbrauchbar.“

In der KI-Transformation sorgt psychologische Sicherheit dafür, dass die Realität den Hype schlägt.

Verordnet das Management die KI-Einführung top-down, entsteht ein massiver Druck, um jeden Preis „Erfolge“ vorzuweisen. Ohne psychologische Sicherheit verschwenden Entwickler dann Stunden im Kampf mit einem Tool, nur damit das Projekt auf dem Papier innovativ aussieht. Fehlschläge werden vertuscht, um nicht als Bremser zu gelten. Andere erzwingen den KI-Einsatz an Stellen, wo er Prozesse verlangsamt, schlicht weil das Management Nutzungsquoten sehen will.

Das ist keine Transformation, das ist schlechtes Management.

Teams brauchen die ausdrückliche Erlaubnis, ehrlich zu benennen, wo KI glänzt, wo sie scheitert und wo klassisches Handwerk weiterhin überlegen ist. Andernfalls bekommt das Management zwar wunderbar grüne Dashboard-Metriken, verliert aber jeden Bezug zur operativen Wirklichkeit.

Von isolierten Hacks zur gemeinsamen Capability

Auf einen einzigen Satz reduziert lautet die Führungsaufgabe heute: Verstreutes, individuelles Experimentieren in eine skalierbare Unternehmensfähigkeit überführen. Wo diese Übersetzung praktisch stattfindet — oder eben nicht —, steht in den weiteren Teilen der Serie über KI im Unternehmen.

Die KI-Einführung beginnt immer als persönliches Experiment. Etwas bessere Architekturentwürfe, schnellere Prototypen, zügigeres Onboarding im Code. Diese kleinen Siege zählen, aber sie addieren sich nicht von allein zu einem Wettbewerbsvorteil.

Wenn jeder Entwickler nur für sich lernt, erntet die Organisation lediglich fragmentierte Verbesserungen und redundante Fehler. Ein Lernkreislauf, der echten Mehrwert skaliert, entsteht nicht von allein – er muss aktiv gesteuert werden:

• Nützliche Workflows, die an der Basis entstehen, frühzeitig erkennen.
• Diese an echter Arbeit messen, nicht an reiner Tech-Begeisterung.
• Erfolgreiche Muster in standardisierte Bausteine gießen und klare Owner benennen.
• Diese Best Practices gezielt in die passenden Teams tragen.
• Und konsequent abschalten, was den Pflegeaufwand nicht wert ist.

Genau dieser Kreislauf ist Führungsarbeit. Er verlangt ein scharfes Urteil darüber, an welche Stellen der Delivery-Pipeline KI gehört, wo harte Quality Gates unverhandelbar sind, wo Teams kreativen Freiraum brauchen und wo Standardisierung wichtiger ist als persönliche Vorlieben.

Und er erfordert Disziplin. Nicht jeder clevere kleine Hack muss ein Team-Standard werden. Nicht jede Mini-Automatisierung verdient Maintenance. Nicht jede persönliche Abkürzung taugt als offizieller Prozess.

Die Organisationen, die am stärksten von KI in der Softwareentwicklung profitieren werden, sind nicht diejenigen, die die meisten Experimente starten. Es sind diejenigen, die am schnellsten aus der Praxis lernen und diese Erkenntnisse radikal in ihre Art zu arbeiten zurückfließen lassen.

KI beschleunigt das Schreiben von Code, aber erst die Führungskraft formt die Umgebung, in der dieser Code auch wertvoll wird.

Die KI-Transformation macht Engineering-Führung nicht überflüssig. Sie macht sie wichtiger denn je.