Warum wir die Produktivität von Entwicklern nicht messen (und was wir stattdessen messen)

Die Rebellion ist da

Im Januar 2024 verhängte die französische Datenschutzbehörde eine Geldstrafe von 32 Millionen Euro gegen Amazon wegen „übermäßig aufdringlicher" Mitarbeiterüberwachung¹. Das Unternehmen hatte Tastenanschläge, Scanner-Aktivitäten und jeden Moment der „Inaktivität" in seinen Lagerhäusern verfolgt.

Amazon ist nicht allein. Eine aktuelle Studie ergab, dass 50 % der überwachten Arbeitnehmer lieber kündigen würden, als ständige Überwachung zu ertragen². Währenddessen sind „Mouse Jigglers" – Geräte, die Aktivität simulieren, um Überwachungssoftware zu täuschen – jetzt Amazon-Bestseller. Die Ironie schreibt sich von selbst.

Das passiert nicht nur in Lagerhäusern. Es passiert im Engineering.

Ein wachsendes Ökosystem von „Entwicklerproduktivitäts"-Tools verspricht Engineering-Führungskräften zu helfen, zu verstehen, was ihre Teams tun. Sie verfolgen Codezeilen, Commits pro Tag, Stunden an der Tastatur und zunehmend – mit KI – sogar den Inhalt dessen, was Entwickler schreiben.

Hier ist die unbequeme Wahrheit: diese Tools sind Überwachung, verkleidet als Management. Und sie machen Engineering-Teams schlechter, nicht besser.

Das Problem: Warum Produktivitätsmetriken toxisch sind

Schauen wir uns an, was diese Tools tatsächlich messen:

Codezeilen

Wie das Sprichwort sagt: Programmierproduktivität an Codezeilen zu messen ist wie Flugzeugfortschritt am Gewicht zu messen. Bill Gates soll es unverblümt ausgedrückt haben: „Programmierfortschritt an Codezeilen zu messen ist wie Flugzeugbaufortschritt am Gewicht zu messen."

Eine Stack-Overflow-Diskussion brachte es perfekt auf den Punkt: „Entwickleroutput an Codezeilen zu messen ist wie die Effektivität eines Kraftwerks an dem Abfall zu messen, den es produziert."

Mehr Zeilen bedeuten oft schlechteren Code. Refactoring, das 500 Zeilen auf 50 reduziert, ist Fortschritt. Automatisierung, die einen manuellen Prozess eliminiert, ist Fortschritt. Eine gut gestaltete Abstraktion, die zukünftige Arbeit verhindert, ist Fortschritt. Nichts davon zeigt sich positiv in LOC-Metriken.

Commits pro Tag

Trivial einfach zu manipulieren. Wollen Sie Ihre Commit-Anzahl steigern? Teilen Sie eine einzelne logische Änderung in fünfzehn winzige Commits auf. Fügen Sie Whitespace-Änderungen hinzu. Committen Sie Ihre Mittagspause.

Wichtiger noch: Commits messen Aktivität, nicht Wirkung. Ein Entwickler, der eine Woche damit verbringt, eine Architektur zu entwerfen, die dem Team Monate Arbeit erspart, wird weniger Commits haben als jemand, der hektisch Features ausliefert, die technische Schulden erzeugen.

Arbeitsstunden

Diese ist besonders heimtückisch. Forschung zeigt konsistent, dass Arbeiten über 50 Stunden pro Woche hinaus tatsächlich die Gesamtleistung reduziert³. Entwickler, die lange bleiben, erreichen weniger, nicht mehr, weil Erschöpfung zu Bugs, schlechten Entscheidungen und Code führt, der Nacharbeit erfordert.

Eine Studie ergab, dass Entwickler, die übermäßige Stunden arbeiten, buchstäblich negative Arbeit produzierten – sie schufen mehr Probleme, als sie lösten.

Dennoch bleibt „Online-Stunden" ein Eckpfeiler von Überwachungstools.

Das Goodhart-Problem

Der britische Ökonom Charles Goodhart beobachtete, dass „wenn eine Kennzahl zum Ziel wird, sie aufhört, eine gute Kennzahl zu sein."⁴

Jede oben genannte Metrik ist trivial manipulierbar:

• Wollen Sie mehr Commits? Teilen Sie Änderungen in Fragmente auf.
• Wollen Sie mehr Zeilen? Schreiben Sie ausführlichen Code.
• Wollen Sie mehr Stunden? Lassen Sie Ihren Laptop offen.
• Wollen Sie mehr PRs? Reichen Sie kleinere, häufigere Änderungen ein.

In dem Moment, in dem Sie anfangen, diese Dinge zu messen, messen Sie nicht mehr das, was Sie messen wollten. Sie messen, wie gut Menschen Ihre Metriken manipulieren.

Das KI-Paradoxon: Warum es schlimmer wird

Wenn Sie dachten, traditionelle Metriken seien kaputt, wird KI alles noch schlimmer machen.

Die Produktivitätsillusion

Der DORA-Bericht 2024 (DevOps Research and Assessment) – die umfassendste jährliche Studie zur Software-Delivery-Performance – fand etwas Überraschendes: Teams, die KI-Coding-Assistenten verwenden, zeigten einen Rückgang des Durchsatzes um 1,5 % und einen Rückgang der Stabilität um 7,2 %⁵.

Moment, was?

Eine Studie von METR aus 2025 ging weiter. Sie fand heraus, dass erfahrene Entwickler, die KI-Assistenten verwenden, bei realen Aufgaben tatsächlich 19 % langsamer waren. Aber hier ist der Clou: Dieselben Entwickler glaubten, sie seien 20 % schneller⁶.

KI erzeugt eine Wahrnehmungs-Realitäts-Lücke. Entwickler fühlen sich produktiver, während sie tatsächlich weniger erreichen.

Individuelle Geschwindigkeit, organisatorische Verlangsamung

KI verstärkt die individuelle Produktivität bei bestimmten Aufgaben – Boilerplate generieren, Tests schreiben, Code erklären. Aber diese individuelle Beschleunigung führt oft zu organisatorischer Verlangsamung.

Eine Analyse von Engineering-Daten ergab, dass KI-unterstützte Teams 21 % mehr Aufgaben erledigten, aber ihre Code-Reviews 91 % länger dauerten und sie 9 % mehr Bugs einführten⁷.

Mehr Output + längere Reviews + mehr Bugs = langsamere Lieferung.

Was ist der Unterschied zwischen Produktivität und Effektivität?

Entwicklerproduktivität misst Aktivität: Commits, Codezeilen, Stunden an der Tastatur. Entwicklereffektivität misst Ergebnisse: ob Arbeit ausgeliefert wurde, ob sie Bestand hatte und ob sie dem Team geholfen hat. Hier weichen wir vom Überwachungskapitalismus-Ansatz für Engineering-Metriken ab.

„Entwicklerproduktivität" ist ein kaputtes Konzept. Aber Entwicklereffektivität ist messbar – wenn Sie sich auf Ergebnisse konzentrieren, nicht auf Aktivität.

Unsere fünf Grundprinzipien leiten alles, was wir bauen:

1. Ergebnisorientiert: Gelieferten Wert messen, nicht Aktivität
2. KI-neutral: Tool-Nutzung nicht verfolgen, aus Ergebnissen ableiten
3. Entwickler-zuerst: Individuelle Profile standardmäßig privat
4. Coaching statt Bewertung: Trends und Anleitung, keine Rankings
5. Anti-Manipulation: Mehrdimensionale Bewertung widersteht Manipulation

Was das in der Praxis bedeutet

Wir messen keine Commits, Codezeilen oder Arbeitsstunden. Wir messen:

• Wurde die Arbeit ausgeliefert? (Lieferung)
• Floss sie nachhaltig? (Flow)
• Hatte sie Bestand? (Qualität)
• Half sie dem Team? (Zusammenarbeit)

Ein Entwickler, der mit KI exzellente Ergebnisse erzielt = effektiv. Ein Entwickler, der ohne KI exzellente Ergebnisse erzielt = effektiv. Hohe Aktivität + niedrige Ergebnisse = Besorgnis, unabhängig vom Tooling.

Die 6 Dimensionen der Effektivität

Wir messen Effektivität über sechs Dimensionen. Jede Dimension hat mehrere Komponenten, die absichtlich Spannung zueinander erzeugen.

Jede Dimension erzählt einen Teil der Geschichte. Die Magie liegt darin, wie sie interagieren.

Das Anti-Gaming-Design (Die Geheimzutat)

Das macht dieses System anders: Die Optimierung einer einzelnen Dimension schadet typischerweise mindestens einer anderen.

Der Batch-Size-Sweet-Spot

Betrachten Sie PR-Größen. Wir belohnen nicht „mehr PRs" oder „größere PRs". Wir belohnen optimale Größen:

• 100-400 Zeilen: Optimal. Score von 100.
• Unter 50 Zeilen: Über-fragmentiert. Score sinkt.
• Über 800 Zeilen: Zu groß für effektives Review. Score sinkt.

Sie können das nicht durch kleinere ODER größere PRs austricksen. Es gibt einen optimalen Bereich, und Abweichungen in beide Richtungen schaden Ihnen.

Bug-Fix-Verhältnis

Ähnlich bei Qualität messen wir nicht nur Bugs. Wir messen den Netto-Beitrag:

• Mehr Bugs behoben als verursacht: Bonuspunkte.
• Mehr verursacht als behoben: Penalty.

Sie können das nicht durch Code-Vermeidung austricksen (keine Bugs, aber auch keine Fixes). Das System belohnt netto-positiven Beitrag zur Qualität.

Privacy als Architektur, nicht als Richtlinie

Viele Tools behaupten, „privacy-fokussiert" zu sein, während sie dennoch Überwachung ermöglichen. Sie fügen eine Checkbox in den Einstellungen hinzu. Sie versprechen, dass Manager keine individuellen Daten ansehen werden. Sie erstellen Richtlinien.

Richtlinien können geändert werden. Einstellungen können umgeschaltet werden. Versprechen können gebrochen werden.

Unser Ansatz ist anders. Privacy ist in die Architektur eingebaut:

1. Individuelle Profile sind isoliert — Es gibt keinen Endpoint, um „alle Entwickler-Scores" abzurufen
2. Keine Leaderboards existieren — Das Konzept ist nicht gebaut
3. Manager sehen Aggregate — Team-Level-Muster, keine individuellen Rankings
4. Coaching-Insights sind begrenzt — Nur für den Entwickler sichtbar (und optional für ihren direkten Manager)
5. Export-Limitierungen — Individuelle Daten können nur vom Individuum exportiert werden

Das geht nicht nur um Respekt für Entwickler (obwohl es das ist). Es geht darum, genaue Daten zu erhalten. In dem Moment, in dem Leute wissen, dass sie gerankt werden, greift Goodharts Gesetz. In dem Moment, in dem Überwachung beginnt, werden die Daten unzuverlässig.

Vertrauen ermöglicht Genauigkeit. Überwachung zerstört beides.

Die Vision: Von Aktivität zu Ergebnissen

Die Branche steht an einem Wendepunkt.

Der alte Ansatz — Überwachungsmetriken, Activity-Tracking, Produktivitätstheater — bricht zusammen. KI beschleunigt den Zusammenbruch. Die Zahlen sind größer, aber sie bedeuten weniger.

Der neue Ansatz konzentriert sich auf das, was zählt:

• Von „wie viel Code" → „hilft es Nutzern?"
• Von Überwachung → Vertrauen
• Von Vanity-Metriken → Business-Impact
• Von Produktivitätstheater → tatsächliche Verbesserung

Die Teams, die das herausfinden, werden einen massiven Vorteil haben. Sie werden bessere Entwickler halten (die keine Überwachung tolerieren). Sie werden bessere Entscheidungen treffen (basierend auf aussagekräftigen Daten). Sie werden sich tatsächlich verbessern (statt Metriken auszutricksen).

Der Traum des CTO

Was Engineering-Leader tatsächlich wollen:

1. Beweis, dass Engineering sich verbessert — Nicht nur Momentaufnahmen, sondern Trajektorien
2. Vertretbare Metriken — Etwas, das sie dem Board zeigen können, das nicht leicht abgetan werden kann
3. Kein Gaming — Metriken, die Manipulation widerstehen
4. Vertrauenserhalt — Messung, die die Team-Kultur nicht zerstört
5. KI-bereite Messung — Metriken, die funktionieren, unabhängig davon, welche Tools Leute verwenden

Traditionelle Produktivitätsmetriken erfüllen alle fünf Anforderungen nicht. Sie sind Momentaufnahmen, leicht zu manipulieren, vertrauenszerstörend und durch KI völlig kaputt.

Effektivitätsmetriken — fokussiert auf Ergebnisse, für Anti-Gaming konzipiert, auf Vertrauen aufgebaut — liefern alle fünf.

Was das für Ihr Team bedeutet

Wenn Sie ein Engineering-Leader sind, der „Developer-Productivity"-Tools in Betracht zieht, stellen Sie diese Fragen:

1. Was genau messen wir? Wenn die Antwort Aktivität ist (Commits, LOC, Stunden), laufen Sie.
2. Kann es ausgetrickst werden? Wenn die Optimierung der Metrik einfacher ist als gute Arbeit zu leisten, ist die Metrik nutzlos.
3. Was passiert mit den Daten? Wenn Individuen verglichen und gerankt werden können, wird Vertrauen erodieren.
4. Wie geht es mit KI um? Wenn es versucht, Tool-Nutzung zu tracken, ist es bereits obsolet.
5. Hilft es Entwicklern, sich zu verbessern? Wenn es nur Messung ohne Coaching ist, ist es Überwachung mit Extra-Schritten.

Wenn Sie ein Entwickler sind, der diesen Tools ausgesetzt ist, wissen Sie, dass Sie nicht verrückt sind. Die Metriken sind bedeutungslos. Die Überwachung schadet tatsächlich. Die besten Teams — die, für die Sie wahrscheinlich arbeiten möchten — lehnen diesen Ansatz ab.

Schließen Sie sich der Rebellion an

Wir bauen etwas anderes.

Keine Überwachung. Kein Produktivitätstheater. Keine Vanity-Metriken, die in Board-Präsentationen gut aussehen, aber schlechtes Verhalten fördern.

Wir bauen den Beweis, dass Ihr Team tatsächlich besser wird.

Es beginnt damit, das zu messen, was zählt: Ergebnisse, nicht Aktivität. Trends, nicht Momentaufnahmen. Effektivität, nicht Produktivität.

Wenn Sie Metriken satt haben, die die falschen Dinge messen, Überwachung, die Vertrauen zerstört, und Tools, die obsolet werden, sobald jemand einen KI-Assistenten öffnet — wir sollten reden.

Quellen