Connect with us

Die Plateau-Falle

Vordenker

Die Plateau-Falle

mm

Ich habe kürzlich über AI-Erschöpfung geschrieben und argumentiert, dass das, was Ingenieure erleben, keine chronische Erkrankung, sondern Trainingsverletzung ist. Durchhalten, anpassen, stärker werden.

Das klingt alles gut und vernünftig, aber es gibt mehr zu dieser Geschichte, und es wird schnell offensichtlicher. Das eigentliche Risiko, dem Ingenieursteams gegenüberstehen, ist nicht das Burnout. Es ist das Plateau.

Die neue Spaltung

Fast jeder Senior-Ingenieur verwendet jetzt KI. Copilot, Claude, Cursor, Codex, nennen Sie es, wie Sie wollen. Dieser Teil ist geklärt. Wenn Sie eine Ingenieurorganisation leiten, sehen Sie wahrscheinlich breite Adoptionszahlen und fühlen sich gut dabei.

Sie sollten sich nicht gut fühlen.

Die Adoptionszahl ist bedeutungslos. Was zählt, ist die Spaltung, die darunter stattfindet. Ihr Team teilt sich stillschweigend in zwei Gruppen. Es gibt die Ingenieure, die einen Produktivitätsschub erhalten und sich einrichten, und Ingenieure, die jede Woche weitermachen. Neue Workflows, neue Agentenkonfigurationen, neue Wege, um Probleme für KI zu lösen.

Beide Gruppen erscheinen in Ihren Dashboards als “KI-Adoptierer”. Aber eine ist in einem progressiven Trainingsprogramm. Die andere stoppte bei dem ersten Gewicht, das sich bequem anfühlte.

Vor sechs Monaten war die Lücke zwischen diesen beiden Gruppen kaum sichtbar. Jetzt ist sie offensichtlich für jeden, der aufpasst. In weiteren sechs Monaten wird sie strukturell sein.

Was das Plateau eigentlich aussieht

Der plateauförmige Ingenieur tut nichts falsch im herkömmlichen Sinne. Er ist kompetent. Er liefert. Er verwendet seinen Agenten für einfache Aufgaben und räumt nach ihm auf. Er erhielt vielleicht eine 20-30-prozentige Produktivitätssteigerung und gab auf.

Das Problem ist, dass der Ingenieur neben ihm nicht aufhörte. Dieser Ingenieur führt jetzt Multi-Agent-Workflows aus, verbessert Verifizierungsschleifen, zerlegt ganze Funktionen in KI-ausführbare Teile, überprüft auf architektonischer Ebene anstelle von zeilenweise und liefert mit 2-3-mal seiner vorherigen Geschwindigkeit. Nicht, weil er talentierter ist. Weil er weiter trainierte, während jeder andere eine Rast einlegte, die zu einem Vierteljahr-Ruhe wurde.

Dies geht nicht um KI-Enthusiasmus oder um ein frühes Adoptieren. Die frühe Adoptionsphase ist vorbei. Dies geht um kontinuierliche Anpassung versus einmalige Anpassung. Und der komponierte Unterschied zwischen diesen beiden Ansätzen wird unmöglich zu ignorieren.

Der Wettbewerbsdruck ist real und beschleunigt sich

Wenn Ihre Teams die Luxus hatten, sich auf ihre eigene Zeitleiste anzupassen, wäre das Plateau-Problem ein Leistungsmanagement-Problem. Ärgerlich, aber machbar.

Aber wenn Sie sich die breitere Situation in der Softwareindustrie ansehen, haben Sie wahrscheinlich diese Luxus nicht.

Die Softwareindustrie wurde im Großen und Ganzen geschaffen, um Menschen bei digitaler Arbeit zu helfen: Unterstützungsagenten sehen eingehende Fälle, verfolgen Antworten an Kunden, verwalten Workflows. Jetzt verdrängen KI-Agenten den gesamten Workflow und damit die zugrunde liegenden SaaS-Plattformen. Darüber hinaus fragen Ihre Kunden mit der zunehmenden Fähigkeit von KI: “Brauchen wir das noch kaufen oder können wir es jetzt selbst bauen?” KI hat begonnen, die Barriere zwischen “kaufen” und “bauen” für eine wachsende Anzahl von Anwendungsfällen zu verringern. Die Klebrigkeit, die früher Ihre Einnahmen schützte, schwächt sich jeden Quartal ab.

Ihre plateauförmigen Ingenieure arbeiten mit einem Tempo, das für ein Wettbewerbsumfeld kalibriert ist, das nicht mehr existiert.

Das Zitat, das alles für mich neu definierte

Ich habe es mehr als einmal gehört, von Produktmanagern, die ihre Ärmel aufgerollt und Features vibe-codiert haben, von Ingenieurleitern, die fehlgeschlagene Architekturen neu entworfen haben, in verschiedenen Unternehmen, in verschiedenen Kontexten:

“Es war einfacher für mich, dies mit meinen Agenten zu iterieren, als mit diesem Ingenieur.”

Das erste Mal dachte ich, es sei Hyperbel. Das dritte Mal erkannte ich, dass es ein führender Indikator war.

So sehe ich es: Es gibt Ingenieure, die in dieser neuen Welt gedeihen und “Multiplikatoren” von KI-Fähigkeiten sein werden. Um das zu tun, müssen sie in zwei Bereichen stark sein, beide können mit ausreichender intrinsischer Motivation und intellektueller Neugier selbst entwickelt werden:

  • Sie operieren “auf der gleichen Welle” wie ihre Stakeholder (PMs, Ingenieurleiter usw.). Sie verstehen, was gut aussieht, sodass Sie ihnen nichts überexplizieren müssen. Wenn sie die gleiche Anzahl von Missverständnissen produzieren wie Ihr Codieragent, wird der Agent immer diesen Kampf gewinnen. Er ist sofort verfügbar, 24/7 und unermüdlich.
  • Sie verbessern kontinuierlich ihre KI-Setups, sodass Sie, wenn Sie ihnen etwas übergeben, wissen, dass es nicht nur gut (siehe oben), sondern auch schnell genug gemacht wird, um mit dem neuen Marktempo Schritt zu halten.

Warum dies ein Führungsproblem und kein individuelles Problem ist

Es ist verlockend, dies als individuelle Verantwortung des Ingenieurs zu betrachten. “Bleiben Sie dran oder werden Sie zurückgelassen.” Aber wenn Sie eine Ingenieurorganisation leiten, lässt diese Betrachtung Sie aus der Verantwortung.

Ihre plateauförmigen Ingenieure haben nicht in einem Vakuum plateauförmig werden. Sie haben plateauförmig werden, weil nichts in ihrer Umgebung sie über die anfängliche Anpassung hinausgetrieben hat. Sie haben einen vernünftig aussehenden Produktivitätsgewinn erzielt, niemand hat sie dazu herausgefordert, weiter zu gehen, und die Trägheit hat den Rest getan.

Die Ingenieure, die weitermachten? Die meisten von ihnen sind selbst motiviert. Sie würden weitermachen, egal was. Aber Sie können eine Ingenieurorganisation nicht ausschließlich mit selbst motivierten Pionieren besetzen. Die Frage für Führungskräfte ist: Wie bewegen Sie das Mittelfeld?

Dies ist ein Change-Management-Problem, und eines meiner Lieblingsframeworks dafür stammt aus dem Buch Switch der Heath-Brüder. Die Kurzversion: Sie müssen den Menschen eine klare Richtung geben, ihnen vermitteln, warum es wichtig ist, und die Umgebung so umgestalten, dass das neue Verhalten der Weg des geringsten Widerstands ist. Angewendet auf Ingenieursteams sieht das so aus:

Finden Sie Ihre hellen Flecken und machen Sie sie sichtbar. Identifizieren Sie die Ingenieure, die am weitesten in ihren KI-Workflows vorangekommen sind, und lassen Sie sie regelmäßig vor dem Team demonstrieren. Nicht Trainings-Sitzungen. Live-Durchgänge von echter Arbeit. Wenn das Mittelfeld Ihres Teams den Unterschied zwischen seinem Workflow und dem des Top-Adapters sieht, entsteht ein produktives Unbehagen, das keine Anweisung erreichen kann.

  • Verkleinern Sie die Veränderung. “KI adoptieren” ist zu abstrakt, um darauf zu handeln. In diesem Sprint nageln Sie das e2e-agente Testing, im nächsten Sprint rollen Sie es über die gesamte Organisation aus, und so weiter. Konkrete, machbare Schritte schlagen ehrgeizige Transformationsprogramme jederzeit, und kleine Siege zählen.
  • Umgestalten Sie die Standards. Kodifizieren Sie den Verifizierungsprozess in KI-Fähigkeiten und stellen Sie sicher, dass diese über Ihr Team und alle ihre Agenten verfügbar sind. Definieren Sie Ihre Workflows und verwenden Sie die Tooling, die dies unterstützt. Machen Sie die neue Arbeitsweise den Weg des geringsten Widerstands, sodass die Leute darauf zusteuern, anstatt dagegen ankämpfen zu müssen.

Das Fenster schließt sich

Hier ist der Teil, der dies dringend und nicht nur wichtig macht.

Im Moment ist die Anpassungslücke ein Leistungsunterschied. Ihre plateauförmigen Ingenieure sind langsamer als Ihre angepassten, aber sie sind immer noch produktiv. Sie tragen immer noch bei. Sie können sie noch tragen.

Dieses Fenster schließt sich. Wenn KI-Fähigkeiten beschleunigen und Wettbewerbsdruck sich verdichtet, steigt der Mindest-Tempo von Ingenieursarbeit. Der “ausreichend gute” Ingenieur von heute ist nicht garantiert ausreichend gut für das nächste Quartal. Nicht, weil er schlechter wird, sondern weil der Boden nach oben bewegt wurde.

Die Organisationen, die herausfinden, wie sie ihre gesamten Teams auf die Anpassungskurve bewegen, nicht nur die frühen Adoptierer, werden einen komponierten strukturellen Vorteil haben. Diejenigen, die dies nicht tun, werden sich in einem Tempo des Wettbewerbs wiederfinden, das nicht mehr existiert.

Jeder Ingenieurleiter, mit dem ich spreche, versteht dies intellektuell. Nur wenige haben ihre Teams in Reaktion darauf geändert. Die Lücke zwischen Verständnis und Handlung ist ihre eigene Art von Plateau.

Es gibt keinen bequemen Tempo

Im Artikel über AI-Erschöpfung argumentierte ich, dass Schmerz der Beweis dafür ist, dass das Training wirkt. Das ist immer noch wahr. Aber die folgende Wahrheit ist härter: Das Gewicht wird immer weiter erhöht.

In einem normalen Fitnessstudio können Sie ein bequemes Gewicht wählen und es für immer beibehalten. Niemand fügt Ihrem Barren ohne Aufforderung Gewichte hinzu. In der aktuellen Software-Landschaft bewegt sich die Latte. Bleiben Sie stehen und das Gewicht wird Sie schließlich festnageln.

Es gibt keinen bequemen Raum in der Softwareindustrie im Moment. Nicht für einzelne Ingenieure, nicht für die Teams, in denen sie arbeiten, nicht für die Unternehmen, die diese Teams bauen. Die einzige sichere Position ist kontinuierliche Bewegung. Und die einzige Frage, die für Ingenieurleiter zählt, ist, ob Ihr gesamtes Team sich bewegt oder nur die, die sich ohnehin bewegt hätten.

Andrew Filev ist Gründer/CEO von Zencoder. Er revolutionierte das collaborative Work Management, indem er Wrike (20k+ Kunden, für 2,25 Mrd. $ verkauft) gründete, in Forbes & The NY Times vorgestellt wurde und seine Leidenschaft für KI & Innovation die Zukunft der Arbeit weiterhin prägt.