Auf Geisterjagd: Was Entwickler wirklich beitragen

„Ghost Engineers“ – jeder zehnte Entwickler leistet so gut wie keine nützliche Arbeit und vermittelt lediglich überzeugend den Eindruck, ständig beschäftigt zu sein. Die wahren Gründe für diese Untätigkeit – Nebenjobs, Burnout oder schlichtes Faulenzen – können der Führung sehr lange verborgen bleiben. (Stanford-Studie von 2024: Original-Thread)

Entwickler hören es nicht gern, wenn ihre Leistung zur Sprache kommt. Nach einem langen „goldenen Zeitalter“ für den Berufsstand entstand in der Branche ein Tabu rund um eine einfache Frage: Rechtfertigt das Ergebnis der Entwicklung die investierte Zeit und das investierte Geld? Doch Ghost Engineers frustrieren auch ihre Kolleginnen und Kollegen – und meistens bemerkt das Team das Problem vor dem Management.

Hier in Russland gilt „Petzen“ seit jeher als verpönt. Deshalb wissen oft viele von einem Problem, aber niemand möchte etwas sagen. Warum sollte man sich in den Ärger anderer hineinziehen lassen? Ans Licht kommt alles erst, wenn die Geduld längst aufgebraucht ist.

Aber vielleicht lassen wir sie einfach in Ruhe, diese Geister. Als würde dem Unternehmen das Geld schon fehlen.

Doch genau da liegt der Haken …

Wenn ich von geringer Leistung spreche, meine ich nicht, dass Alex sich abmüht und am Ende zehn Prozent weniger schafft als Ben. Ich meine etwas anderes: Bei jedem Stand-up muss sich das ganze Team die nächste rührselige Geschichte anhören – das andere Team hat ihn hängen lassen, das Ticket war unklar, die Sterne standen ungünstig. Aber morgen ist die Aufgabe ganz bestimmt fertig. Pfadfinderehrenwort.

Nur war dieses „morgen“ schon gestern und vorgestern – und ist inzwischen zur Tradition geworden.

Teams bemerken so etwas schnell. Wer die eigentliche Arbeit schultert, fragt sich völlig zu Recht: Warum soll ich mich aufreiben, wenn andere Märchen erzählen können und damit ohne Folgen davonkommen?

Das Problem zu bemerken reicht jedoch nicht. Solange Zahlen und Fakten fehlen, wird aus dem Gespräch rasch ein Streit: Das Team sagt „Er leistet zu wenig“, der Entwickler entgegnet „Man lässt mich meine Arbeit nicht machen“. Meist beginnt die Untersuchung erst, wenn die Geduld endgültig erschöpft ist und das Team die Führungskraft bittet, den Entwickler zu ersetzen.

Dann beginnt die lange Geschichte: Fakten zusammentragen, beide Seiten anhören, Feedback geben und Zeit einräumen, damit sich die Situation verbessern kann. Meiner Erfahrung nach endet sie meist damit, dass der Geist zu einem neuen – und ausgesprochen glücklichen – Arbeitgeber weiterzieht.

Das Problem besteht nicht nur darin, dass eine Person weniger leistet. Das Unternehmen zahlt doppelt: zuerst für Arbeit, die nie erledigt wird, und dann für die Zeit, die Kolleginnen, Kollegen und Führungskräfte mit Nachprüfen, Auffangen und Ursachenforschung verbringen. Am Ende fällt nicht mehr nur ein Entwickler zurück, sondern das ganze Team.

Kann eine Führungskraft das Problem früher erkennen – die Abweichung sehen, nach dem Kontext fragen und der Sache nachgehen, bevor dem Team die Geduld und dem Unternehmen Zeit und Geld ausgehen?

Mit genügend Erfahrung lassen sich solche Situationen oft schon vorab an einigen typischen Verhaltensmustern erkennen:

• Jeder Erfolg gehört mir, jeder Misserfolg ist deine Schuld.
• Ausreden für das Scheitern einer Aufgabe, bevor die Arbeit überhaupt begonnen hat.
• Fehlende Kompetenz wird durch übermäßiges Reden ausgeglichen.
• Mit der Zeit wird vor allem die Führungskraft zum „Schuldigen“ erklärt.
• Anders als bei jemandem, der wirklich Schwierigkeiten hat, bessert sich dieses Verhalten selbst nach direktem Feedback nicht.

Doch ein Verdacht braucht digitale Spuren.

Schauen wir uns die gängigsten Werkzeuge zur Messung von Entwicklungsleistung an – und ob sie dabei helfen können, Geister aufzuspüren.

Bevor ich sie vergleiche, sollte ich den offensichtlichen Interessenkonflikt benennen: Sie lesen den offiziellen DevGhost-Blog, und ich bin der Gründer des Produkts. Das hier ist die Perspektive eines Autors, keine unabhängige Studie.

Um die Softwareentwicklung selbst zu beurteilen – nicht das Unternehmen oder das Produkt als Ganzes –, nutze ich eine einfache Dreiteilung: Geschwindigkeit, Qualität und Umfang. DORA-Metriken sagen etwas über die Geschwindigkeit aus, Tests und Defekte über die Qualität. Beim Umfang wird es schwieriger. Hier ist das Terrain am wenigsten erschlossen – und genau hier verstecken sich die Geister, nach denen wir suchen.

DORA: Geschwindigkeit und Zuverlässigkeit von Releases

DORA zeigt, wie schnell und zuverlässig ein Team Änderungen in die Produktion bringt. Das Modell verwendet fünf Kennzahlen: die Zeit vom Commit bis zur Produktion, die Deployment-Häufigkeit, den Anteil fehlgeschlagener Deployments, die Zeit bis zur Wiederherstellung und den Anteil ungeplanter Nacharbeit.

Das ist ein guter Maßstab für den Delivery-Prozess, aber nicht für den individuellen Beitrag. Wenn eine Person die Arbeit von drei erledigt, während sich eine andere hinter dem Gesamtergebnis des Teams versteckt, verrät DORA das nicht.

Diese Kennzahlen eignen sich außerdem wunderbar als KPIs. In einem Unternehmen, für das ich gearbeitet habe, wurden sie seit 2018 kräftig gemolken – alle Dashboards leuchteten erfolgreich grün, und alle waren zufrieden. Das aktuelle DORA-Modell.

Tests und Defekte: Wie gut wurde die Arbeit erledigt?

Die Methoden sind etabliert und bewähren sich in der Praxis. Qualität wird durch Code-Reviews, Tests und statische Analyse kontrolliert; die Folgen werden über Defekte und Incidents verfolgt.

Über den Umfang sagen diese Signale jedoch nichts aus. Ein winziger, makelloser Patch lässt jeden Indikator grün werden – und der Geist bleibt unsichtbar.

Jira und Story Points: Wie viele Tickets wurden abgeschlossen?

Jira zeigt abgeschlossene Tickets und Story Points, doch die Schätzungen stammen vom Team selbst. Dieselbe Arbeit kann mit drei oder dreizehn Punkten bewertet, in fünf Tickets aufgeteilt oder in einem einzigen gebündelt werden.

Story Points sind für die Planung nützlich, als Maß für den individuellen Beitrag aber unzuverlässig. Sobald Punkte zum Ziel werden, optimieren Menschen auf Punkte.

Auch sie sind bequeme KPIs. Daten werden eingetragen und Tickets verschoben, nur damit die Quality Gates passiert werden. Jede Menge sinnlose Handarbeit.

Commits und Codezeilen: Fakten ohne Kontext

Git hängt nicht von den Schätzungen eines Teams ab, deshalb liegt es nahe, Commits und Zeilen zu zählen. Doch fünf Commits können einen winzigen Patch darstellen, während ein einzelner Squash-Commit für eine ganze Arbeitswoche stehen kann.

Formatierung, generierter Code, Kopieren und Verschieben blähen die Zeilenzahl auf, während ein schwieriger Fix vielleicht nur zehn Zeilen umfasst.

Swarmia, LinearB und Waydev: Das gesamte Entwicklungssystem an einem Ort

Swarmia, LinearB und Waydev führen Git, Issue-Tracker und CI/CD zusammen. Führungskräfte sehen DORA-Metriken, Review-Warteschlangen, Durchlaufzeiten für Änderungen und Ergebnisse von Befragungen.

Sie liefern ein nützliches Bild des Entwicklungssystems – und zeigen oft, dass das Problem im Prozess und nicht bei einer Person liegt. Den Arbeitsumfang einzelner Entwickler auf einer vergleichbaren Skala zu messen, ist jedoch nicht die zentrale Frage, die diese Plattformen beantworten wollen. Swarmia, LinearB, Waydev.

GitClear: Was nach dem Code-Rauschen übrig bleibt

GitClear unterscheidet hinzugefügten, verschobenen und kopierten Code, schließt generierte Dateien aus und berücksichtigt, ob neuer Code später umgeschrieben oder gelöscht wurde.

Daraus entsteht Diff Delta – GitClears eigene Einheit für sinnvolle Änderungen, die in der Codebasis erhalten bleiben. Kopierter oder schnell wieder verworfener Code wiegt weniger als eine kompakte Änderung, die in Produktion dauerhaft funktioniert. So funktioniert Diff Delta.

Diff Delta beantwortet nicht die Frage, wie viel Arbeit nötig war. Es zeigt, wie viel sinnvolle Veränderung nach Rauschen und Nacharbeit übrig geblieben ist. GitClear ist besonders stark bei der Messung der Haltbarkeit und Qualität von Code sowie bei der Analyse der Auswirkungen von KI.

Jetzt wird es interessanter. Der Dienst veröffentlicht Benchmarks, doch Diff Delta bleibt eine eigene Einheit: Eine Zahl wie 10.000 sagt ohne den passenden Vergleich und ein Verständnis der Methodik wenig aus. Ein klarer Bezugspunkt wie „100 % sind normal“ fehlt. Diff-Delta-Benchmarks.

BlueOptima: Dieselbe Frage im Unternehmensmaßstab

BlueOptima kenne ich aus eigener Erfahrung. 2019 begann ich, mit der Plattform zu arbeiten. Diese Erfahrung hat mich dazu inspiriert, mein eigenes Produkt zu entwickeln.

Der Coding-Effort-Algorithmus analysiert jede Änderung am Quellcode anhand statischer Kennzahlen und berücksichtigt dabei Größe, Komplexität und Beziehung zum übrigen Code. Das Ergebnis wird anschließend in Stunden ausgedrückt.

So lassen sich Entwickler aus verschiedenen Teams und Technologie-Stacks miteinander vergleichen – auch mit einem globalen Benchmark. Für mich war es der erste überzeugende Versuch, nicht die Frage „Wie viele Zeilen hat dieser Entwickler geschrieben?“ zu beantworten, sondern „Wie viel substanzielle Arbeit steckt in diesen Änderungen?“ Die Methodik von BlueOptima, globaler Benchmark.

In meinem Fall war der Zugang zu diesen Enterprise-Funktionen mit einer recht aufwendigen Einführung verbunden: Ein Agent musste in einer abgeschotteten Netzwerkumgebung installiert werden, der Preis war hoch, und die Ergebnisse brauchten fachkundige Interpretation.

Für ein Unternehmen mit Tausenden Entwicklern kann das gerechtfertigt sein. Für ein Startup oder ein kleines Team vermutlich nicht. Diese Lücke war später einer der Gründe, warum DevGhost entstand.

Derselbe Maßstab – ohne Ausschreibung

Als ich DevGhost entwickelte, wollte ich nicht noch eine All-in-one-Plattform bauen, die mit jeder erdenklichen Engineering-Metrik vollgepackt ist.

Ich wollte dieselbe Antwort, die BlueOptima lieferte – wie viel substanzielle Arbeit hinter den Änderungen steckt –, aber in einer Form, die ein Startup-Gründer oder ein kleines Team ohne Ausschreibung, langwierige Einführung oder Beraterstab nutzen kann.

Die Logik ist einfach: DevGhost analysiert die Änderungen selbst – was hinzugefügt, gelöscht und umstrukturiert wurde und wie schwierig es war, das Ergebnis zu erstellen und zu prüfen. Formatierung, Codeverschiebungen, massenhafte automatische Ersetzungen und generierter Code werden von substanzieller Arbeit getrennt.

Das Ergebnis ist eine Aufwandsschätzung in äquivalenten Stunden: So lange würde ein Entwickler auf mittlerem Niveau, der die Codebasis kennt und ohne KI arbeitet, benötigen, um denselben Code zu schreiben. Es ist weder die tatsächlich an der Tastatur verbrachte Zeit noch eine Bewertung der Codequalität oder des Geschäftswerts. Es ist ein gemeinsamer Maßstab, um Änderungen zu vergleichen. Mehr über die DevGhost-Methodik.

Ghost% vergleicht diese Schätzung mit der erwarteten Leistung eines Entwicklers auf mittlerem Niveau und berücksichtigt dabei, welcher Anteil seiner Arbeitszeit tatsächlich für Entwicklung aufgewendet wird. Ein Ergebnis von 100 % bedeutet, dass die Person der Norm entspricht. Ein niedrigeres Ergebnis ist ein Anlass, genauer hinzusehen; ein höheres sollte man untersuchen und vielleicht zur Best Practice machen.

Der Benchmark geht bewusst von Arbeit ohne KI aus. DevGhost versucht nicht festzustellen, wer ein bestimmtes Stück Code geschrieben hat – ein Mensch, Copilot oder ein autonomer Agent. Bewertet werden die fertigen Änderungen: Wie viel Aufwand hätte ein Entwickler auf mittlerem Niveau gebraucht, um sie ohne KI zu erstellen und zu prüfen?

Dadurch verschwindet der Effekt von KI nicht in der Kennzahl, sondern wird sichtbar. Wenn ein Entwickler in einem Zeitraum Arbeit erstellt und prüft, die früher das Zwei- oder Dreifache an Aufwand erfordert hätte, bildet Ghost% das ab. Formatierung, Massengenerierung und anderes Code-Rauschen sollten nicht denselben Effekt haben.

Wer kontrolliert die Kontrolleure?

Die naheliegendste Frage lautet: Warum sollte irgendjemand einer maschinell erzeugten Schätzung vertrauen? Die kurze Antwort: Niemand sollte ihr blind vertrauen.

Die Schwierigkeit einer Arbeit einzuschätzen ist per Definition subjektiv. Wir haben das getestet, indem wir mehrere erfahrene Entwickler dieselben Änderungen schätzen ließen – und erhielten deutlich unterschiedliche Zahlen. Jeder arbeitet in einem anderen Tempo, bringt andere Erfahrungen mit und hat eine eigene Vorstellung davon, was schwierig ist.

Auch DevGhost kann falschliegen. Sein Vorteil ist nicht der Zugang zu irgendeiner absoluten Wahrheit. Der Vorteil besteht darin, dass jede Änderung am selben Maßstab gemessen wird – ohne Bevorzugung, Müdigkeit oder eine vorgefasste Meinung über ihren Autor.

Deshalb ist Ghost% ein Signal, kein Urteil. Ein niedriger Wert kann auf einen schwachen Beitrag hindeuten, aber ebenso durch Teamlead-Aufgaben, Architekturarbeit, Mentoring, Incidents oder Blocker erklärt werden.

Die Zahl zeigt, wo eine Frage gestellt werden sollte. Die Antwort muss die Führungskraft weiterhin selbst finden – nun jedoch mit einer unabhängigen zweiten Einschätzung statt allein mit Intuition.

„Ich weiß doch ohnehin, wie jeder in meinem Team arbeitet“

Einer der DevGhost-Kunden leitet die Entwicklung eines schnell wachsenden KI-Unternehmens. Anfangs stand er der Idee, Entwicklungsleistung überhaupt zu messen, skeptisch gegenüber. Seine Haltung war einfach: Eine gute technische Führungskraft weiß auch ohne Dashboard, wie jeder arbeitet.

Wir analysierten die Historie eines Repositorys, das er gut kannte. Bei drei Entwicklern hatte es bereits Bedenken gegeben: Ihre Tickets kamen nur langsam voran, aber sie arbeiteten an einem separaten Service, weshalb ein Vergleich mit dem Rest des Teams schwierig war. DevGhost zeigte bei allen drei über ungefähr sechs Monate hinweg durchgehend niedrige Werte.

Später, als die Entwickler nach und nach kündigten, stellte sich heraus, dass sie während dieser ganzen Zeit nebenher an eigenen Produkten gearbeitet hatten. DevGhost konnte den Grund nicht kennen. Es machte lediglich etwas sichtbar, das Commit-Zahlen, Pull Requests und tägliche Gespräche in Slack nicht gezeigt hatten: Ihr Arbeitsumfang lag deutlich unter dem Erwartungswert.

Die Analyse wurde jedoch nicht zu einer Kündigungsliste. Bei zwei anderen Entwicklern ermöglichte ein niedriger Wert konkretes Feedback, eine Untersuchung der Ursachen und eine bessere Leistung. Beide blieben im Team.

Auch die Entwickler, die er für stark hielt, erschienen genau dort, wo er sie erwartet hatte. Und nun konnte er nicht nur sehen, wer überdurchschnittlich viel leistete, sondern auch, wie konstant.

Ein einzelner Fall beweist natürlich nicht, dass die Methode genau ist. Den Kunden überraschte, wie eng das Gesamtbild mit dem übereinstimmte, was zuvor nur intuitiv bekannt gewesen war – und in manchen Fällen erst im Rückblick offensichtlich wurde.

Was, wenn ein Entwickler die Leistung von drei Personen erbringt?

Die Jagd nach Geistern ist der Teil dieser Geschichte, der am meisten Aufmerksamkeit erzeugt. Doch das obere Ende des Diagramms kann noch nützlicher sein.

Wenn ein Entwickler dauerhaft ein Mehrfaches des durchschnittlichen Ergebnisses liefert, sollte man genau herausfinden, wie er das schafft.

Heute lautet die Frage nicht mehr, ob ein Entwickler KI nutzt – für viele ist sie längst ein normaler Teil der Arbeit. Entscheidend ist, wie effektiv jemand Agenten in zusätzliche Lieferkapazität verwandelt.

Die eine Person bleibt bei Autovervollständigung stehen. Eine andere weiß, wie sie Agenten den richtigen Kontext gibt, klare Regeln formuliert, mehrere Aufgaben parallel steuert und die Ergebnisse sorgfältig prüft. Derselbe Zugang zu KI kann deshalb völlig unterschiedliche Produktivitätsgewinne bringen.

Ein hoher Ghost%-Wert hilft dabei, Entwickler zu finden, die mit diesem Zusammenspiel von Mensch und Agent bereits starke Ergebnisse erzielen – und zu verstehen, welche Praktiken der Rest des Teams übernehmen könnte.

Wenn der hohe Wert durch die Qualität der Arbeit und die Einschätzung der Führungskraft bestätigt wird, sollte dieser Entwickler wertgeschätzt, gehalten und für eine Beförderung in Betracht gezogen werden. Seine Arbeitsweisen sollte das Team untersuchen und weitergeben.

Den Maßstab nicht zur Waffe machen

Jede Kennzahl erleidet dasselbe Schicksal: Früher oder später versucht jemand, daraus einen KPI zu machen. Ghost% eignet sich dafür nicht.

Macht man Ghost% zum Team-KPI, beginnen Menschen, ihre Arbeit daraufhin zu optimieren. Veröffentlicht man eine Rangliste, verschwindet das Vertrauen. Verwandelt man den Wert in einen Kündigungsknopf, sind Fehler unvermeidlich.

Ich würde vier Regeln festlegen:

• Keine Schlüsse aus einer einzelnen Messung oder einem kurzen Zeitraum ziehen.
• Die Rolle der Person, ihren Entwicklungsanteil und die Arbeit außerhalb des Codes berücksichtigen.
• Das Ergebnis dem Entwickler zeigen und ihm Gelegenheit geben, den Kontext zu erklären.
• Ghost% nicht als alleinige Grundlage für eine Personalentscheidung verwenden.

Bleibt ein niedriger Wert bestehen, sollte die Führungskraft zunächst die Ursachen untersuchen. Vielleicht hat die Person tatsächlich Schwierigkeiten, die erwartete Leistung zu erbringen. Vielleicht arbeitet sie aber auch an der Architektur, kümmert sich um die Incidents anderer oder wird durch Teamprozesse blockiert.

Bestätigt sich das Problem, braucht es einen konkreten Verbesserungsplan und nach einem vereinbarten Zeitraum eine erneute Bewertung.

Wer Kennzahlen ablehnt, schafft die Bewertung von Menschen nicht ab. Er lässt nur Bauchgefühl, Geschichten aus Stand-ups und persönliche Vorlieben der Führungskraft übrig.

Geschwindigkeit, Qualität und Umfang brauchen unterschiedliche Werkzeuge. DORA zeigt, wie Änderungen in Produktion gelangen. Tests und Defekte zeigen die Qualität. DevGhost ergänzt eine Schätzung des Arbeitsaufwands hinter den Codeänderungen.

Keine dieser Kennzahlen sollte Entscheidungen für die Führungskraft treffen.

Der Wert einer Zahl besteht nicht darin, ein Urteil zu fällen. Er liegt darin, dass ein schwieriges Gespräch früher beginnt – und sich auf Fakten stützt.

Wie beurteilen Sie den Arbeitsumfang von Entwicklern, und wo ziehen Sie die Grenze zwischen sinnvoller Transparenz und Überwachung?