Die Plateau-Falle

Ich habe neulich schrieb über KI-MüdigkeitEr argumentiert, dass es sich bei dem, was Ingenieure erleben, nicht um eine chronische Erkrankung, sondern um Trainingskater handelt. Sie sollen durchhalten, sich anpassen und gestärkt daraus hervorgehen.

Das klingt alles gut und schön, aber die Geschichte hat noch mehr zu bieten, und das wird immer deutlicher. Die eigentliche Gefahr für Entwicklerteams ist derzeit nicht Burnout, sondern Stagnation.

Die neue Spaltung

Fast jeder leitende Ingenieur nutzt heutzutage KI. Copilot, Claude, Cursor, Codex – die Liste ist lang. Das ist längst etabliert. Wenn Sie eine Entwicklungsabteilung leiten, sehen Sie wahrscheinlich eine breite Akzeptanz und sind damit zufrieden.

Sie sollten nicht.

Die reine Nutzungsrate ist bedeutungslos. Entscheidend ist die Spaltung, die sich im Verborgenen vollzieht. Ihr Team teilt sich stillschweigend in zwei Gruppen. Da sind die Entwickler, die einen Produktivitätsschub verzeichnen konnten und sich eingerichtet haben, und die anderen, die Woche für Woche weiter an sich arbeiten. Neue Arbeitsabläufe, neue Agentenkonfigurationen, neue Methoden zur Problemstrukturierung für die KI-Bearbeitung.

Beide Gruppen werden in Ihren Dashboards als „KI-Anwender“ angezeigt. Die eine Gruppe absolviert jedoch ein progressives Trainingsprogramm, die andere hat bei dem ersten Gewicht aufgehört, das sich angenehm anfühlte.

Vor sechs Monaten war der Unterschied zwischen diesen beiden Gruppen kaum sichtbar. Jetzt ist er für jeden, der genauer hinsieht, offensichtlich. In weiteren sechs Monaten wird er strukturell spürbar sein.

Wie ein Plateau tatsächlich aussieht

Der Ingenieur, dessen Leistung stagniert, macht im herkömmlichen Sinne nichts falsch. Er ist kompetent. Er liefert ab. Er beauftragt seinen Agenten mit einfachen Aufgaben und kümmert sich um die anschließende Reinigung. Er konnte seine Produktivität vielleicht um 20–30 % steigern und hat die Sache damit für erledigt erklärt.

Das Problem ist, dass der Ingenieur neben ihnen nicht aufgehört hat. Er setzt jetzt Multiagenten-Workflows ein, optimiert Verifizierungsschleifen, zerlegt ganze Funktionen in KI-ausführbare Einheiten, prüft auf Architekturebene statt Zeile für Zeile und liefert zwei- bis dreimal so schnell aus wie zuvor. Nicht etwa, weil er talentierter wäre, sondern weil er sich weitergebildet hat, während alle anderen einen Ruhetag einlegten, der sich zu einem ganzen Quartal ausdehnte.

Hier geht es nicht um KI-Begeisterung oder darum, zu den Erstanwendern zu gehören. Die Phase der frühen Einführung ist vorbei. Es geht um kontinuierliche Anpassung statt einmaliger Maßnahmen. Und der kumulative Unterschied zwischen diesen beiden Ansätzen lässt sich nicht mehr ignorieren.

Der Wettbewerbsdruck ist real und nimmt zu.

Wenn Ihre Teams die Möglichkeit hätten, sich in ihrem eigenen Tempo anzupassen, wäre das Problem der Leistungsstagnation ein Thema des Leistungsmanagements. Ärgerlich, aber beherrschbar.

Betrachtet man jedoch die Gesamtsituation in der Softwarebranche, stehen die Chancen gut, dass man sich diesen Luxus nicht leisten kann.

Die Softwarebranche wurde größtenteils geschaffen, um Menschen bei digitalen Aufgaben zu unterstützen: Supportmitarbeitern bei der Bearbeitung eingehender Anfragen, der Nachverfolgung von Kundenantworten und der Workflow-Verwaltung zu helfen. Mittlerweile verdrängen KI-Systeme den gesamten Workflow und revolutionieren damit die zugrundeliegenden SaaS-Plattformen. Da KI täglich leistungsfähiger wird, stellen sich Ihre Kunden zunehmend die Frage: „Müssen wir das noch kaufen oder können wir es jetzt selbst entwickeln?“ KI verringert die Trennlinie zwischen Kauf und Eigenentwicklung für immer mehr Anwendungsfälle. Die Kundenbindung, die einst Ihre Umsätze sicherte, schwächt sich von Quartal zu Quartal ab.

Ihre Ingenieure stagnieren und arbeiten in einem Tempo, das auf ein wettbewerbsorientiertes Umfeld ausgelegt ist, das es nicht mehr gibt.

Das Zitat, das für mich alles veränderte

Ich habe es nun schon mehr als einmal gehört, von Produktmanagern, die die Ärmel hochkrempelten und intuitiv Funktionen programmierten, von technischen Führungskräften, die fehlerhafte Architekturen neu gestalteten, in verschiedenen Unternehmen, in verschiedenen Kontexten:

„Es war für mich einfacher, dies mit meinen Agenten zu besprechen als mit dem Ingenieur.“

Als ich es das erste Mal hörte, hielt ich es für eine Übertreibung. Beim dritten Mal begriff ich, dass es ein Frühindikator war.

Meiner Ansicht nach gibt es Ingenieure, die in dieser neuen Welt erfolgreich sein und die Fähigkeiten der KI „multiplizieren“ werden. Dafür müssen sie in zwei Bereichen stark sein, die beide mit genügend intrinsischer Motivation und intellektueller Neugierde selbst entwickelt werden können:

• Sie arbeiten auf derselben Wellenlänge wie ihre Stakeholder (Projektmanager, Entwicklungsleiter usw.). Sie verstehen, was gut aussieht, daher müssen Sie ihnen nichts übermäßig erklären. Denn wenn sie genauso viele Missverständnisse verursachen wie Ihr Coding-Agent, wird der Agent immer die Oberhand behalten. Er ist sofort, rund um die Uhr und unermüdlich verfügbar.
• Sie verbessern ständig ihre KI-Systeme, sodass Sie, wenn Sie ihnen etwas anvertrauen, sicher sein können, dass es nicht nur gut (siehe oben) erledigt wird, sondern auch schnell genug, um mit dem neuen Markttempo Schritt zu halten.

Warum dies ein Führungsproblem und kein individuelles Problem ist

Man ist leicht versucht, dies als Verantwortung des einzelnen Ingenieurs darzustellen: „Wer nicht mithält, bleibt auf der Strecke.“ Doch wer eine Entwicklungsabteilung leitet, entzieht sich mit dieser Sichtweise der Verantwortung.

Die Leistungsplateaus Ihrer Ingenieure entstanden nicht im luftleeren Raum. Sie stagnierten, weil sie durch nichts in ihrem Umfeld über die anfängliche Anpassung hinausgetrieben wurden. Sie erzielten einen zufriedenstellenden Produktivitätszuwachs, niemand forderte sie zu weiteren Leistungen heraus, und die Trägheit tat ihr Übriges.

Die Ingenieure, die immer weiter nach vorne trieben? Die meisten von ihnen sind hochmotiviert. Sie würden ohnehin weitermachen. Aber man kann eine Entwicklungsabteilung nicht ausschließlich mit solchen hochmotivierten Pionieren besetzen. Die Frage für die Führungskräfte lautet: Wie motiviert man die Mitarbeiter im mittleren Management?

Dies ist ein Problem des Veränderungsmanagements, und eines meiner Lieblingsmodelle dafür stammt aus dem Buch der Heath-Brüder. SchalterKurz gesagt: Man muss den Mitarbeitern eine klare Richtung vorgeben, ihnen den Sinn dahinter vermitteln und das Umfeld so gestalten, dass das neue Verhalten den Weg des geringsten Widerstands darstellt. Auf Entwicklerteams angewendet, sieht das folgendermaßen aus:

Finde deine Stärken und mach sie sichtbar. Identifizieren Sie die Ingenieure, die ihre KI-Workflows am weitesten vorangetrieben haben, und lassen Sie sie dem Team regelmäßig Demos präsentieren. Keine Schulungen, sondern Live-Demonstrationen realer Arbeitsabläufe. Wenn die Mitarbeiter im mittleren Team den Unterschied zwischen ihrem Workflow und dem der Top-Ingenieure sehen, entsteht ein produktiver Anreiz, den keine Vorgabe ersetzen kann.

• Verkleinere das Wechselgeld. „KI einführen“ ist zu abstrakt, um es in die Praxis umzusetzen. In diesem Sprint sollten wir die End-to-End-Tests mit Agenten abschließen, im nächsten Sprint die KI unternehmensweit einführen usw. Konkrete, überschaubare Schritte sind ambitionierten Transformationsprogrammen stets überlegen, und auch kleine Erfolge zählen.
• Die Standardeinstellungen ändern. Kodifizieren Sie den Verifizierungsprozess in KI-gestützten Fähigkeiten und stellen Sie sicher, dass diese im gesamten Team und von allen Mitarbeitern eingesetzt werden. Definieren Sie Ihre Arbeitsabläufe und nutzen Sie die dafür passenden Tools. Gestalten Sie die neue Arbeitsweise so, dass sie sich intuitiv und ohne großen Widerstand durchsetzt.

Das Fenster schließt sich

Hier kommt der Punkt, der die Sache dringlich und nicht nur wichtig macht.

Aktuell schlägt sich die Anpassungslücke in einem Leistungsunterschied nieder. Ihre Ingenieure, deren Leistung stagniert, sind zwar langsamer als die angepassten, aber dennoch produktiv. Sie leisten weiterhin einen Beitrag. Sie können sie mitnehmen.

Dieses Zeitfenster schließt sich. Mit der rasanten Entwicklung von KI-Systemen und dem zunehmenden Wettbewerbsdruck steigen die Anforderungen an das Arbeitstempo im Ingenieurwesen. Ein Ingenieur, der heute als „gut genug“ gilt, wird im nächsten Quartal nicht mehr automatisch gut genug sein. Nicht etwa, weil er schlechter geworden ist, sondern weil die Anforderungen gestiegen sind.

Organisationen, die es schaffen, ihre gesamten Teams – und nicht nur die Vorreiter – im Anpassungsprozess weiterzuentwickeln, werden einen sich verstärkenden strukturellen Vorteil erlangen. Diejenigen, denen dies nicht gelingt, werden feststellen, dass ihr Personal auf ein Wettbewerbstempo ausgerichtet ist, das es so nicht mehr gibt.

Jeder Ingenieurchef, mit dem ich spreche, versteht das theoretisch. Nur wenige haben daraufhin ihre Teamführung verändert. Die Kluft zwischen Verständnis und Handeln bildet eine Art Plateau.

Es gibt kein angenehmes Tempo.

In meinem Artikel über KI-Ermüdung argumentierte ich, dass Muskelkater der Beweis dafür ist, dass das Training wirkt. Das stimmt nach wie vor. Doch die darauffolgende Wahrheit ist schwieriger: Die Belastung steigt ständig.

In einem normalen Fitnessstudio kann man sich ein angenehmes Gewicht aussuchen und es dauerhaft beibehalten. Niemand packt ungefragt zusätzliche Gewichte auf die Hantelstange. In der heutigen Softwarelandschaft hingegen, mit jeder neuen Version, jeder neuen Agentenfunktion, jedem neuen Workflow, den jemand entdeckt und teilt, ändert sich das Gewicht ständig. Wer auf der Stelle tritt, wird irgendwann von den neuen Möglichkeiten überwältigt.

In der Softwarebranche gibt es derzeit keinen sicheren Hafen. Weder für einzelne Entwickler, noch für ihre Teams, noch für die Unternehmen, die diese Teams aufbauen. Die einzige sichere Position ist ständige Bewegung. Und die einzige Frage, die für Führungskräfte im Engineering zählt, ist, ob sich das gesamte Team bewegt oder nur diejenigen, die sich ohnehin bewegt hätten.