Womit haben technische Führungskräfte zu kämpfen, was Anbieter nicht lösen?

Wenn du einen technischen Leiter fragst, ob KI sein Team effizienter gemacht hat, wirst du meist eine kurze Pause vor der Antwort erleben. Nicht, weil sie es nicht glauben. Sondern weil ihnen niemand jemals erklärt hat, was „effizient“ eigentlich bedeuten soll, oder ihnen eine Zahl genannt hat, an der sie das messen könnten.

Jonas Kröger, Senior Director of Customer Solutions bei Upsun, verbringt seine Zeit damit, mit den Leuten zu sprechen, die diese Entscheidungen treffen, und die Lücke, auf die er immer wieder stößt, ist keine Lücke bei den Tools. Es ist vielmehr so, dass die meisten Versprechen, die den technischen Führungskräften derzeit gemacht werden, eigentlich gar nicht überprüft werden können.

Die Kennzahl, die niemand hat

„Es gibt Führungskräfte, die sich Sorgen um die Kosten machen, ja, aber auch um das Versprechen von Effizienzsteigerungen im Vergleich zur Realität“, sagte Kröger. „Die meisten Teams, mit denen wir heute sprechen, messen ihre Effizienz nicht. Wie kann man also eine Effizienzsteigerung versprechen, wenn man nichts hat, um sie zu belegen?“

Das ist kein Vorwurf an diese Teams. Es trifft einfach auf die meisten Entwicklungsabteilungen zu, ob KI oder nicht: Zykluszeit, Bearbeitungsdauer von Reviews, Störungsrate – nur wenige dieser Kennzahlen wurden konsequent erfasst, bevor die Agenten auftauchten. Das bedeutet, dass die „Vorher“-Hälfte jeder Behauptung „X % effizienter“ in der Regel fehlt. Niemand lügt. Es gibt einfach nichts, womit man vergleichen könnte.

Mehr Output ist nicht dasselbe wie mehr Effizienz

Selbst wenn Teams eine Zahl vorweisen können, ist es oft die falsche. Kröger erklärte, warum das Pull-Request-Volumen – eine Kennzahl, auf die viele Teams als Erstes zurückgreifen – nicht stichhaltig ist.

„Ist der Output in Ordnung? Wir haben mehr PRs. Ist das effizienter? Ich bin mir nicht sicher“, sagte er. „Häufiger mehr features zu veröffentlichen, bedeutet nicht unbedingt, dass man effizienter ist. Es sind einfach mehr der falschen Dinge. Es könnte also tatsächlich weniger effizient sein, weil plötzlich die Anzahl der Supportanfragen oder Vorfälle steigt.“

Mehr Code, der schneller ausgeliefert wird, ist nicht automatisch ein Fortschritt. Wenn es der falsche Code ist oder Code, den niemand richtig durchdenken konnte, verlagert das Volumen die Kosten einfach weiter nach hinten – in Support-Tickets und Störungsmeldungen –, wo es schwieriger ist, die Ursache zurückzuverfolgen.

Eine alte Antwort auf eine neue Frage

Die Lösung, auf die Kröger hinweist, ist kein neues KI-spezifisches Dashboard. Es ist ein altes, das die meisten Teams bereits kennen und selten konsequent nutzen.

„Die gesamten DORA-Kennzahlen gibt es schon eine Weile, um Softwareteams zu messen“, sagte er, „und vielleicht muss der Zusammenhang zu diesen Dingen deutlicher gemacht werden.“ 

DORA (Deployment-Häufigkeit, Durchlaufzeit, Ausfallrate bei Änderungen und Wiederherstellungszeit) wurde entwickelt, um genau diese Frage für die Softwarebereitstellung im Allgemeinen zu beantworten. Die meisten Anbieter-Präsentationen überspringen das Thema einfach und suchen nach einer Metrik, die nach KI klingt. Krögers Ansatz ist eher das Gegenteil: Man sollte die neue Aktivität mit einem Rahmenwerk verknüpfen, hinter dem bereits jahrelange gemeinsame Bedeutung steht, anstatt ein neues zu erfinden, auf das sich noch niemand geeinigt hat.

Die Diskussion um die Kosten, die noch lange nicht beendet ist

Die Ausgaben sind der andere Bereich, in dem sich die Kluft zwischen Versprechen und Beweisen zeigt. „Wie kann ich die Ausgaben kontrollieren?“, wird mit Sicherheit ein Einwand sein, sagte Kröger, „denn gerade jetzt, wenn man seinen API-Schlüssel eingibt und keine Möglichkeit hat, die Ausgaben zu begrenzen, zu kontrollieren oder den Überblick zu behalten, wird das ein Thema sein.“

Und hinter der Kostenfrage verbirgt sich eine noch undurchsichtigere: Bringt ein höherer Aufwand tatsächlich bessere Ergebnisse? „Sie sind ratlos“, sagte Kröger über die meisten Unternehmen, die versuchen, diese Frage zu beantworten. „Sie wissen es nicht. Und wer weiß es schon?“ Diese Unsicherheit ist ein wichtiger Grund dafür, warum große Unternehmen trotzdem weiter Geld ausgeben, meinte er, da die Angst, den Anschluss zu verlieren, schwerer wiegt als der fehlende Nachweis, dass sich die Ausgaben lohnen.

Was Führungskräfte tatsächlich fordern

Das heißt aber nicht, dass Führungskräfte im Engineering zögern, KI einzuführen. Krögers Einschätzung ist eher das Gegenteil: Diejenigen, die am weitesten fortgeschritten sind, fragen nicht, ob sie agentenbasierte Workflows nutzen sollen; sie stehen vor der Herausforderung, das, was bereits funktioniert, über ein einzelnes Team hinaus zu skalieren – und niemand bietet ihnen Hilfe bei diesem Teil an.

Kröger stützt sich bei seiner Argumentation nicht auf Produktdifferenzierung. Differenzierung entsteht seiner Ansicht nach nicht durch den Agenten oder das zugrunde liegende Modell, da diese Ebene überall relativ ähnlich aussieht. Stattdessen entsteht sie durch die damit verbundenen Unterstützungsmaßnahmen und Services: zu verstehen, wo ein Team tatsächlich feststeckt, und die Einarbeitungs- und Workflow-Unterstützung aufzubauen, die es wieder in Gang bringt. 

Das ist ebenso sehr ein Serviceproblem wie ein Produktproblem, und genau dieser Teil wird übersprungen, wenn ein Pitch mit den Funktionen beginnt, anstatt mit der Frage, wie ein Team wissen soll, ob es funktioniert hat.

Genau in dieser Lücke – zwischen selbstbewussten Produktversprechen und der wenig glamourösen Arbeit, diese zu beweisen und zu skalieren – versucht Upsun Dispatch™, die Führungskräfte im Engineering abzuholen: Kostentransparenz vom ersten Tag an, „Human-in-the-Loop“ als Standard statt als nachträglicher Einfall und ein fokussierter, ehrlicher Ausgangspunkt statt des Versprechens, alles auf einmal zu lösen.

• Neu hier? Lies die Einführung zu Upsun Dispatch.
• Möchtest du beim Aufbau mithelfen? Bewirb dich für die Gründungskohorte der Design-Partner.