Die sieben Todsünden der Engineering-Metriken

Die Metriken-Landschaft ist toxisch

Jede Engineering-Organisation hat metrikinduzierte Dysfunktion erlebt. Ein Team optimiert auf Velocity und liefert Bugs. Ein Unternehmen misst Codezeilen und erhält aufgeblähte Codebasen. Ein Manager trackt Stunden und erhält erschöpfte Entwickler, die vorgeben zu arbeiten.

Das sind keine Einzelfälle. Sie sind das natürliche Ergebnis schlecht konzipierter Messsysteme.

Dieser Beitrag katalogisiert die sieben toxischsten Muster, die wir bei Hunderten von Engineering-Teams beobachtet haben. Jedes beginnt mit guten Absichten – Führungskräfte versuchen, Verantwortlichkeit, Sichtbarkeit oder Verbesserung zu schaffen. Jedes endet in Dysfunktion.

Betrachten Sie dies als Feldführer. Lernen Sie, die Muster zu erkennen. Verstehen Sie, warum sie scheitern. Kennen Sie die Gegenmittel.

Sünde Nr. 1: Vanity-Metriken

Das Muster: Zahlen messen, die steigen, aber nicht mit Geschäftsergebnissen korrelieren.

Beispiele:

• Commits pro Tag
• Geschriebene Codezeilen
• Abgeschlossene Story Points
• Gemergte PRs
• Protokollierte Stunden

Warum es passiert:

Vanity-Metriken sind einfach zu messen. Sie kommen direkt aus Ihren Tools – GitHub, Jira, Ihrem Zeiterfassungssystem. Sie erzeugen befriedigende Grafiken, die nach oben und rechts gehen. Sie fühlen sich konkret und objektiv an.

Führungskräfte unter Druck, „etwas zu zeigen", greifen zu diesen Metriken, weil sie verfügbar sind, nicht weil sie bedeutungsvoll sind.

Der Schaden:

Vanity-Metriken schaffen perverse Anreize. Wenn Sie Commits pro Tag messen, erhalten Sie Entwickler, die Änderungen in winzige Commits aufteilen. Wenn Sie Codezeilen messen, erhalten Sie ausführliche, aufgeblähte Codebasen. Wenn Sie Story Points messen, erhalten Sie Punkte-Inflation.

Schlimmer noch, Vanity-Metriken erzeugen eine Illusion von Sichtbarkeit. Führungskräfte denken, sie verstehen, was passiert, weil die Zahlen gut aussehen. Sie erkennen nicht, dass die Zahlen von der tatsächlichen Wertlieferung abgekoppelt sind.

Das Gegenmittel:

Fragen Sie bei jeder Metrik: „Wenn sich diese Zahl verdoppelt, verdoppelt sich dann der Geschäftswert?" Wenn die Antwort nein ist – oder sogar unsicher – ist es eine Vanity-Metrik.

Ersetzen Sie Vanity-Metriken durch Ergebnismetriken: Lead Time zum Kunden, Defekt-Escape-Rate, Zeit zur Wiederherstellung nach Vorfällen. Diese sind schwerer zu messen, aber sie zählen tatsächlich.

Sünde Nr. 2: Surveillance Creep

Das Muster: Mit Team-Level-Metriken beginnen und schrittweise zur Überwachung auf individueller Ebene ausweiten.

Die Progression:

1. Start: „Wir wollen nur Team-Velocity für die Planung."
2. Sechs Monate: „Können wir Velocity pro Person sehen, um Engpässe zu identifizieren?"
3. Ein Jahr: „Können wir individuelle Commit-Aktivität tracken?"
4. Achtzehn Monate: „Können wir die in der IDE verbrachte Zeit überwachen?"

Warum es passiert:

Es ist eine rutschige Piste. Jeder Schritt erscheint isoliert betrachtet vernünftig. „Wir überwachen nicht – wir fügen nur Sichtbarkeit hinzu." Aber Sichtbarkeit akkumuliert zu Überwachung.

Oft getrieben von einigen wenigen schlechten Akteuren: eine Führungskraft, die ihrem Team nicht vertraut, oder ein Vorfall, der Druck erzeugt, „genauer zu überwachen".

Der Schaden:

Überwachung zerstört psychologische Sicherheit. Wenn Entwickler wissen, dass sie beobachtet werden, optimieren sie darauf, produktiv auszusehen, anstatt produktiv zu sein. Sie vermeiden die schwierigen Probleme, die tiefes Nachdenken erfordern (was wie Inaktivität aussieht). Sie manipulieren jede Metrik.

Überwachung vertreibt auch Top-Talente. Die besten Engineers – die Optionen haben – gehen zu Teams, die ihnen vertrauen. Sie bleiben mit Entwicklern zurück, die Überwachung tolerieren, was kein großartiger Filter ist.

Forschung zeigt konsistent, dass überwachte Mitarbeiter weniger produktiv, weniger kreativ und weniger loyal sind als vertrauenswürdige Mitarbeiter¹.

Das Gegenmittel:

Ziehen Sie eine klare Linie bei Team-Level-Metriken. Individuelle Aktivitätsdaten sollten nur für die Person selbst sichtbar sein – eine Linie, die besser als Architektur als als Richtlinie hält. Wenn Sie der Arbeit einer Person nicht vertrauen können, ohne sie zu überwachen, haben Sie ein Vertrauensproblem – kein Sichtbarkeitsproblem.

Sünde Nr. 3: Goodhart-Gaming

Das Muster: Die Metrik optimieren statt des Ergebnisses, das sie repräsentieren sollte.

Benannt nach: dem britischen Ökonomen Charles Goodhart, der beobachtete: „Wenn eine Messgröße zum Ziel wird, hört sie auf, eine gute Messgröße zu sein."

Beispiele:

Warum es passiert:

Menschen sind Optimierungsmaschinen. Wenn Sie Belohnungen (explizit oder implizit) an eine Zahl koppeln, werden Menschen Wege finden, diese Zahl gut aussehen zu lassen. Das ist nicht böswillig – es ist rationales Verhalten im Anreizsystem, das Sie geschaffen haben.

Der Schaden:

Gaming trennt Metriken von der Realität. Die Zahl verbessert sich, während die zugrunde liegende Situation gleich bleibt – oder sich verschlechtert. Währenddessen treffen Führungskräfte Entscheidungen basierend auf der sich verbessernden Zahl, blind für das Gaming darunter.

Irgendwann wird die Diskrepanz offensichtlich (Kunden beschweren sich, Vorfälle häufen sich, Talente gehen), aber bis dahin ist erheblicher Schaden entstanden.

Das Gegenmittel:

Verwenden Sie mehrere Metriken, die sich gegenseitig unter Spannung setzen. Velocity allein kann durch das Liefern von Müll manipuliert werden. Velocity + Qualität bedeutet, dass das Liefern von Müll Ihrem Score schadet. Deshalb messen wir sechs Dimensionen, nicht eine.

Außerdem: Koppeln Sie niemals Vergütung oder Leistungsbeurteilung direkt an Metriken. In dem Moment, in dem Sie das tun, intensiviert sich das Gaming.

Sünde Nr. 4: Kontextblindheit

Das Muster: Teams vergleichen, ohne Codebase-Alter, Komplexität oder technische Schulden zu berücksichtigen.

Beispiele:

• „Team A liefert 20 % mehr Story Points als Team B – was ist mit Team B los?"
• „Unsere Cycle Time ist 40 % langsamer als der Branchen-Benchmark – wir müssen uns verbessern."
• „Dieser Entwickler hat halb so viele Commits wie seine Kollegen – ist er unterdurchschnittlich?"

Warum es passiert:

Vergleich ist intuitiv. Menschen benchmarken natürlich gegen Peers. Führungskräfte wollen „High Performer" und „Underperformer" identifizieren. Anbieter verkaufen „Branchen-Benchmarks", die Vergleiche einfach machen.

Der Schaden:

Kontext zählt mehr als Vergleich. Die Codebase von Team B ist 10 Jahre alt mit massiven technischen Schulden – natürlich liefern sie weniger Punkte. Ihre Cycle Time ist länger, weil Sie rigorose Sicherheitsüberprüfungen haben – die Ihr Benchmark nicht erfordert. Dieser Entwickler hat weniger Commits, weil er drei Juniors mentoriert.

Kontextblinder Vergleich erzeugt unfairen Druck, zerstört Moral und führt zu schlechten Entscheidungen. Teams in schwierigen Situationen werden für Dinge bestraft, die außerhalb ihrer Kontrolle liegen.

Das Gegenmittel:

Vergleichen Sie jedes Team mit seiner eigenen Geschichte, nicht mit anderen Teams. Die Frage ist nicht „Warum ist Team B langsamer als Team A?" Sie lautet „Wird Team B schneller als im letzten Quartal?"

Wenn Sie Teams vergleichen müssen, normalisieren Sie für Kontext: Codebase-Alter, Teamerfahrung, technische Schuldenlast, Domain-Komplexität. Noch besser: Vergleichen Sie einfach nicht. Es führt selten zu guten Ergebnissen.

Sünde Nr. 5: Momentaufnahmen-Sucht

Das Muster: Sich auf die Zahlen dieses Sprints versteifen statt auf Sprint-übergreifende Trends zu achten.

Symptome:

• „Die Velocity ist in diesem Sprint um 15 % gesunken – was ist schiefgelaufen?"
• „Die Bug-Anzahl ist hochgeschnellt – wir brauchen einen Handlungspunkt."
• „Die Cycle Time ist gestiegen – lasst uns mehr Standups einführen."

Warum es passiert:

Momentaufnahmen sind sichtbar und alarmierend. Eine rote Zahl verlangt Aufmerksamkeit. Trends erfordern Geduld und historischen Kontext. In Hochdruck-Umgebungen gewinnen Momentaufnahmen.

Der Schaden:

Varianz ist normal. Jeder Zwei-Wochen-Zeitraum hat natürliche Schwankungen: Feiertage, Krankheitstage, schwierige Probleme, einfache Probleme. Auf jede Momentaufnahmen-Schwankung zu reagieren erzeugt Peitschenhieb-Effekte – ständige Prozessänderungen, die nie lange genug bestehen bleiben, um sie zu bewerten.

Schlimmer noch: Momentaufnahmen-Sucht macht Teams Angst davor, notwendige Arbeit zu leisten, die kurzfristige Zahlen verschlechtert: technische Schulden abbauen, komplexe Systeme refaktorisieren, Juniors betreuen. All das reduziert vorübergehend „Produktivitäts"-Metriken.

Das Gegenmittel:

Trainieren Sie sich selbst zu fragen: „Ist das ein Trend oder ein Ausreißer?" Schauen Sie sich die letzten 6 Sprints an, nicht nur diesen einen. Richten Sie Anomalie-Erkennung ein, die nur bei statistisch signifikanten Abweichungen alarmiert – nicht bei jedem Zucken.

Noch besser: Nehmen Sie Prozessänderungen nur auf Basis von Sprint-übergreifenden Trends vor. Wenn eine Zahl drei Sprints hintereinander schlecht ist, untersuchen Sie es. Wenn sie für einen Sprint schlecht ist, warten Sie ab.

Sünde Nr. 6: Ranglisten-Toxizität

Das Muster: Einzelpersonen auf Weisen ranken, die Zusammenarbeit und psychologische Sicherheit zerstören.

Beispiele:

• „Hier sind die Top-5-Mitwirkenden dieses Monats."
• „Individuelle Velocity-Scores für das Quartal."
• „Code-Review-Abschluss-Rangliste."

Warum es passiert:

Führungskräfte denken, Wettbewerb motiviert. Ranglisten sind sichtbar und einfach. Top-Performer fühlen sich anerkannt.

Der Schaden:

Ranglisten zerstören Zusammenarbeit. Wenn mein Ranking von meiner individuellen Leistung abhängt, warum sollte ich Zeit damit verbringen, dir zu helfen? Warum sollte ich Juniors betreuen? Warum sollte ich die unscheinbare Infrastruktur-Arbeit machen, die nicht auf der Rangliste erscheint?

Ranglisten erzeugen auch Angst. Selbst Top-Performer fühlen Druck, ihre Position zu halten. Mittlere Performer fühlen sich bloßgestellt und demoralisiert. Untere Performer ziehen sich entweder zurück oder gehen.

Die Forschung zur psychologischen Sicherheit ist eindeutig: Teams, in denen sich Einzelpersonen beurteilt fühlen, schneiden schlechter ab als Teams, in denen sich Einzelpersonen sicher fühlen².

Das Gegenmittel:

Veröffentlichen Sie niemals individuelle Rankings. Punkt. Wenn Sie Top-Performer anerkennen möchten, tun Sie es privat und konzentrieren Sie sich auf Verhaltensweisen, nicht auf Metriken.

Anerkennung auf Team-Ebene ist in Ordnung. „Dieses Team hat seine Cycle Time in diesem Quartal um 30 % verbessert" feiert, ohne toxischen Wettbewerb zu erzeugen.

Sünde Nr. 7: Tool-Tunnelblick

Das Muster: KI-Tool-Nutzung statt Ergebnisse messen.

Beispiele:

• „Wir tracken die KI-Adoptionsrate – 60 % der Entwickler haben diesen Monat Copilot genutzt."
• „KI-generierter Code-Anteil: 35 % und steigend."
• „Durch KI eingesparte Zeit: geschätzt 400 Stunden."

Warum es passiert:

Organisationen investieren in KI-Tools und wollen den ROI nachweisen. Nutzung zu tracken ist einfach – das Tool liefert sie. Tatsächliche Produktivitätsverbesserung zu beweisen ist schwer.

Der Schaden:

Tool-Nutzung korreliert nicht mit Ergebnissen. Studien zeigen, dass KI-unterstützte Entwickler manchmal mehr Bugs, langsamere Lieferung und Code produzieren, der mehr Review erfordert³. Hohe Adoptionsrate + schlechtere Ergebnisse = verschwendetes Geld.

Schlimmer noch: Das Tracken von KI-Nutzung erzeugt Druck, KI zu nutzen, wenn es nicht hilfreich ist. Entwickler zwingen KI in Workflows, wo sie Reibung hinzufügt, nur um auf dem Adoptions-Dashboard zu erscheinen.

Und grundsätzlich: In dem Moment, in dem Sie tracken, wie Entwickler ihre Arbeit erledigen, messen Sie Aktivität, nicht Ergebnisse. Sie sind zurück bei Überwachung.

Das Gegenmittel:

Seien Sie KI-neutral. Tracken Sie nicht Tool-Nutzung – tracken Sie Ergebnisse. Wenn ein Entwickler großartige Ergebnisse mit KI erzielt, großartig. Wenn er großartige Ergebnisse ohne KI erzielt, auch großartig. Wenn er trotz hoher KI-Nutzung schlechte Ergebnisse hat, das ist das eigentliche Signal.

Die Frage ist nicht „Nutzen die Leute KI?", sondern „Sind die Leute effektiv?"

Woran erkennen Sie, ob Ihre Metriken toxisch sind?

Führen Sie eine schnelle Diagnose durch. Stellen Sie für jede Ihrer aktuellen Engineering-Metriken fünf Fragen: Korreliert sie mit Geschäftswert, kann sie manipuliert werden, rankt sie Einzelpersonen, reagieren Sie auf Momentaufnahmen oder Trends, und berücksichtigt sie Kontext?

Wenn Sie drei oder mehr Mal „schlecht" geantwortet haben: Ihre Metriken richten wahrscheinlich mehr Schaden als Nutzen an.

Der Weg nach vorn

Toxische Metriken zu beheben erfordert Mut. Sie müssen:

1. Bequeme Metriken ausmustern, die sich objektiv anfühlen, aber die falschen Dinge messen.
2. Druck widerstehen von Stakeholdern, die „einfache Zahlen" wollen.
3. Mehrdeutigkeit akzeptieren in Bereichen, wo präzise Messung nicht möglich ist.
4. In bessere Messung investieren, die mehr Nachdenken erfordert, aber besseres Signal liefert.

Die Belohnung ist eine Engineering-Organisation, die sich tatsächlich verbessert – nicht eine, die besser darin wird, Dashboards zu manipulieren.

Wir haben Simyl Flow um Metriken herum gebaut, die diese sieben Sünden vermeiden. Ergebnisorientiert, mehrdimensional, trendbasiert, kontextbewusst, privatsphäre-wahrend und KI-neutral by Design.

Quellen