EM-Metriken: Velocity, Codequalität, Mitarbeiterbindung, Einstellung

Das erste Mal, als ich mit einem story-points-Diagramm in einen QBR ging, ließ mich mein VP ungefähr neunzig Sekunden reden, bevor er sagte: "Camellia, wie hoch ist Ihre bedauerliche Fluktuation? Und Ihre Deployment-Häufigkeit? Vergessen Sie die Punkte."

Ich hatte keine dieser Zahlen. Ich hatte ein wunderschön eingefärbtes Balkendiagramm der Velocity nach Sprint und eine Folie mit dem Titel "Q3 Durchsatz +18%." Nichts davon überstand die Frage. Er war nicht unhöflich. Er war ehrlich. Die Executive-Ebene finanzierte Ergebnisse. Ich hatte Aktivitäten mitgebracht. Wir sprachen nicht dieselbe Sprache, und das folgende Budgetgespräch war ungefähr so herzlich, wie man es sich vorstellen kann.

Dieses Meeting veränderte, wie ich Dashboards führe. Diese Anleitung ist das Dashboard, das ich mir gewünscht hätte: sechs Metriken, reale Zahlenbereiche, benannte Diagnosen, eine QBR-Folie. Nichts mehr, weil mehr der Weg ist, wie Goodharts Gesetz Sie auffrißt.

Warum Ergebnisse den Durchsatz schlagen

Durchsatz-Metriken (story points, geschlossene Tickets, Codezeilen, protokollierte Stunden) messen Aktivität. Aktivität ist, was Ihr Team getan hat. Ergebnisse sind, was das Unternehmen bekommen hat. Die Executive-Ebene finanziert Ergebnisse: Liefergeschwindigkeit, Zuverlässigkeit, Team-Dauerhaftigkeit, Einstellungsdurchsatz. Wenn Sie die Arbeit Ihres Teams nicht in diese vier Bereiche übersetzen können, werden Sie aus Personalressourcen-Gesprächen herausgeschnitten, und Sie werden es nicht kommen sehen, bis die Angebotseinfrierung in Ihrem Posteingang landet.

Es gibt einen zweiten Grund. Durchsatz-Metriken sind leicht zu manipulieren, ohne dass jemand das beabsichtigt. Sagen Sie einem Team, dass Sie geschlossene Tickets messen, und innerhalb eines Quartals haben Sie kleinere Tickets. Sagen Sie ihnen, dass Sie story points messen, und innerhalb von zwei Quartalen haben Sie eine Inflation, die einen Zentralbankier erröten lassen würde. Ergebnis-Metriken sind schwerer zu manipulieren, weil sie an die Realität gebunden sind. Das deploy ist entweder passiert oder nicht, der Ingenieur ist entweder geblieben oder gegangen, das Angebot wurde entweder angenommen oder abgelehnt.

Also: sechs Metriken. Vier für Lieferung und Zuverlässigkeit, zwei für Team-Gesundheit. Das ist das Set.

Deployment-Häufigkeit

Wie oft erreicht der Code Ihres Teams die Produktion? Täglich, wöchentlich, monatlich oder seltener. Dies ist die erste DORA-Metrik und das sauberste Signal, ob Ihre Auslieferungspipeline tatsächlich eine Pipeline ist oder eine Reihe von verschlossenen Türen mit Handschlüsseln.

Zielstufe nach Team-Reife:

Die meisten Produktteams sollten bei "Hoch" sitzen. Wenn Sie bei "Mittel" sind und die Arbeit es rechtfertigt (regulierte Branche, lange QA-Zyklen), sagen Sie das auf der Folie. Wenn Sie bei "Niedrig" sind und ein SaaS-Team sind, ist das ein Befund, keine Zahl.

Durchlaufzeit für Änderungen

Zeit vom commit bis zur Produktion. Dies ist die zweite DORA-Metrik und diejenige, die Ihnen sagt, wo der Engpass wirklich liegt. Stunden, Tage oder Wochen.

Wenn Sie das messen und aufschlüsseln, finden Sie meist einen von drei Schuldigen: Code-Review (PR liegt zwei Tage offen und wartet auf einen Senior, der in Meetings ist), CI (Test-Suite dauert 47 Minuten und schlägt einmal in fünf Fällen fehl) oder Deploy-Schranke (manuelle Genehmigung, die im Kalender von jemandem lebt). Wählen Sie den längsten aus und beheben Sie ihn. Versuchen Sie nicht, alle drei auf einmal zu beheben.

Gesunde Bereiche nach Team-Typ:

• Produktteam, Web-App: unter 24 Stunden, idealerweise unter 8.
• Plattformteam, Infra: unter 48 Stunden.
• Mobile Team: 3-7 Tage, begrenzt durch App-Store-Review.

Wenn Ihre Durchlaufzeit zwei Wochen beträgt und Ihre Deployment-Häufigkeit täglich ist, stimmt mathematisch etwas nicht. Entweder deployen Sie meist triviale Änderungen, während große verrotten, oder Sie zählen falsch. Untersuchen Sie das, bevor Sie die Folie zeigen.

Änderungsfehlerrate

Prozentsatz der Deploys, die einen rollback, hotfix oder Produktionsvorfall verursachen. Die dritte DORA-Metrik. Zielbereich ist 0-15%, wobei gesunde Teams bei 5-10% liegen.

Zwei Dinge zu beobachten. Erstens: eine Änderungsfehlerrate von null ist ein Warnsignal, kein Grund zur Selbstbeglückwünschung. Das bedeutet normalerweise, dass Ihr Team zu viel testet, zu selten deployt oder Vorfälle nicht vollständig zählt. Zweitens: Diese Metrik hat einen natürlichen Bodensatz. Software ist schwer, Menschen liefern Fehler, und eine Rate von 2% ist Rauschen, kein Rückgangssignal. Jagen Sie nicht das letzte Prozentpunkt auf Kosten der Velocity.

Wenn die Änderungsfehlerrate über 15% steigt, lautet die Diagnose fast immer: unzureichende Testabdeckung auf kritischen Pfaden, ein Release-Prozess, der zu viel bündelt (sodass Fehler verflochten werden), oder neue Mitarbeiter, die in die Produktion ausliefern, bevor sie den Auswirkungsbereich verstehen. Benennen Sie, welcher. Mitteln Sie sie nicht weg.

MTTR

Mean Time to Restore. Wenn etwas in der Produktion ausfällt, wie lange bis es wieder funktioniert? Stunden, nicht Tage. Dies ist die vierte DORA-Metrik und diejenige, die am stärksten mit on-call-Hygiene verknüpft ist.

Eine gute MTTR liegt für ein SaaS-Produkt unter 4 Stunden. Unter 1 Stunde für Elite-Teams. Der Trick ist, dass MTTR nicht wirklich darum geht, wie schnell Sie einen Fix schreiben können. Es geht darum, wie schnell Sie erkennen, diagnostizieren und deployen können. Die meisten langsamen MTTRs, die ich debuggt habe, stammten aus einem von drei Bereichen: Alerting, das nicht auslöste (sodass das Team durch einen Kunden von dem Ausfall erfuhr), runbooks, die nicht existierten (sodass der on-call-Ingenieur von vorne anfangen musste), oder eine Deploy-Pipeline, die 90 Minuten braucht (sodass man selbst nach dem geschriebenen Fix wartet).

Wenn MTTR steigt, schauen Sie sich die on-call-Belastung an. Ausgebrannte on-call-Ingenieure sind langsame on-call-Ingenieure. Das ist die Metrik, bei der Deployment-Häufigkeit, Änderungsfehlerrate und Teamgesundheit sich berühren.

Bedauerliche Fluktuation über 12 Monate

Die erste der zwei Team-Gesundheitsmetriken und diejenige, die Ihr VP am meisten beschäftigt.

Bedauerliche Fluktuation zählt nur Personen, die Sie behalten wollten. Wenn ein Leistungsschwacher geht, ist das nicht bedauerlich. Wenn ein beständiger mittleres Level-Ingenieur, der nie aufgefallen ist, geht und Sie zucken mit den Schultern, ist das nicht bedauerlich. Wenn ein Senior IC, ein tech lead oder ein nachwachsender Junior geht, ist das bedauerlich. Seien Sie ehrlich mit sich selbst, wenn Sie es so kennzeichnen. Manager neigen dazu, rückwirkend zu entscheiden, dass alle, die gegangen sind, "nicht die Richtige Besetzung" waren, was dazu führt, dass Sie 0% bedauerliche Fluktuation haben und ein Team, das halb weg ist.

Branchen-Benchmarks für Tech, 2026:

• Gesund: 8-12% jährlich.
• Beobachtungszone: 13-15%.
• Alarm: über 15%.
• Fünf-Alarm-Feuer: über 20%.

Verfolgen Sie es auf einer rollierenden 12-Monats-Basis, nicht nach Kalenderquartal. Quartalszahlen sind bei kleinen Teams zu verrauscht. Wenn Sie acht Ingenieure haben und einen bedauerlichen Abgang in Q2, sind das 12,5%: auf rollierender Basis in Ordnung, auf einem Quartals-Diagramm erschreckend.

Angebotsannahmequote plus Einarbeitungszeit

Die zweite Team-Gesundheitsmetrik und diejenige, die Ihnen sagt, ob Ihr Team wachsen kann.

Zwei Teilmetriken, eine Folienzeile. Angebotsannahmequote: von den Angeboten, die Sie im letzten Quartal gemacht haben, wie viel Prozent wurden angenommen? Ziel: 70% oder höher. Unter 60% bedeutet, Ihre Angebote sind nicht wettbewerbsfähig (meist Vergütung, manchmal Titel, gelegentlich die Geschichte des Unternehmens).

Einarbeitungszeit: von Startdatum bis zum ersten nicht-trivialen PR, der in die Produktion gemergt wurde, wie viele Tage? Ziel: unter 30. Wenn Ihr durchschnittlicher Neueinsteiger 60 Tage braucht, um etwas Echtes zu liefern, ist Ihr Einarbeitungsprozess gebrochen oder Ihre Codebasis ist ein Labyrinth. So oder so ist das ein Befund.

Beide Zahlen zusammen erzählen die Einstellungsgeschichte. Hohe Annahmequote, schnelle Einarbeitung: Einstellungsmaschine funktioniert. Hohe Annahmequote, langsame Einarbeitung: Sie verkaufen gut, Sie arbeiten schlecht ein. Niedrige Annahmequote, schnelle Einarbeitung: wenn Personen doch beitreten, gedeihen sie, aber Sie können nicht abschließen. Niedrige Annahmequote, langsame Einarbeitung: die Maschine ist auf beiden Enden kaputt.

Engineering NPS

Vierteljährliche Puls-Umfrage, eine Frage: "Würden Sie dieses Team einem anderen Ingenieur empfehlen?" Null-bis-zehn-Skala. Ziehen Sie Detraktoren (0-6) von Promotoren (9-10) ab, ignorieren Sie Passive (7-8). Das Ergebnis liegt zwischen -100 und +100.

Gesunde Engineering-Teams erzielen 30-50. Über 50 ist ausgezeichnet. Unter 20 ist eine Warnung. Negativ ist ein Feuer, das bereits begonnen hat; Sie haben den Rauch nur noch nicht gesehen.

Führen Sie es jedes Quartal in derselben Woche durch. Anonym. Fügen Sie immer eine offene Follow-up-Frage hinzu: "Was würde Ihre Bewertung um einen Punkt erhöhen?" Lesen Sie jede Antwort. Die Zahl ist die Überschrift; die Kommentare sind die Diagnose.

Die Diagnose "hohe Velocity, aber hohe Fluktuation"

Hier ist das Muster, das die meisten EMs überrascht. Deployment-Häufigkeit ist hoch. Änderungsfehlerrate ist niedrig. Durchlaufzeit ist ausgezeichnet. MTTR ist solide. Nach den vier DORA-Metriken liefert das Team wie ein Champion.

Und die bedauerliche Fluktuation steigt. Der Engineering NPS sinkt. Personen, die Sie behalten wollten, gehen.

Das Team liefert sich aus dem Unternehmen heraus.

Ich habe das einmal erlebt. Wir hatten 60 Deploys im Monat, Änderungsfehlerrate von 4%, MTTR unter 90 Minuten, und ich verlor drei Ingenieure in einem Quartal, zwei davon Senior. Das Metrik-Dashboard log durch Auslassung. Die Wahrheit zeigte sich in Austrittsgesprächen: "Ich bin müde." "Ich bin seit 18 Monaten nicht gewachsen." "Mein Freund bei einem Konkurrenten verdient 30% mehr für dieselbe Arbeit."

Es gibt normalerweise drei Ursachen, und sie stapeln sich oft:

1. Burnout. Hohe Velocity ist für ein Quartal nachhaltig, manchmal zwei. Darüber hinaus leihen Sie gegen die Zukunft des Teams.
2. Vergütungslücke. Der Markt hat sich bewegt, Ihre Gehaltsbänder nicht, und Ihre Seniors wissen es, weil sie jeden Dienstag LinkedIn-Nachrichten bekommen.
3. Kein Wachstumspfad. Personen blieben, als sie lernten. Einmal fühlte sich die Codebasis klein an, suchten sie nach einer größeren.

Benennen Sie die Ursache auf der Folie. Mitteln Sie es nicht in ein generisches "Personen gehen, wir werden am Engagement arbeiten." Dieser Satz hat noch nie ein Team gerettet.

Schmuck-Kennzahlen, die Sie aufhören sollten zu berichten

Goodharts Gesetz: Wenn ein Maß zum Ziel wird, hört es auf, ein gutes Maß zu sein. Jede Metrik auf dieser Liste, einschließlich der sechs oben, ist anfällig. Aber diese vier sind anfällig genug, dass Sie sie komplett einstellen sollten:

• Erledigte story points. Inflation garantiert. Produziert kleinere Geschichten, die als größere dargestellt werden. Sagt Ihnen nichts darüber, was die Produktion erreicht hat.
• Geschlossene Tickets. Gleiches Problem, anderes Scoreboard. Ermutigt Tickets, sich zu multiplizieren.
• Codezeilen. Ein Maß für Tippen, nicht für Engineering. Bestraft Löschungen, die meist die besten PRs sind.
• Protokollierte Stunden. Misst Anwesenheit, nicht Output. Bestraft Eltern und belohnt performatives nächtliches Slack-Schreiben.

Tauschen Sie sie aus. story points und Tickets werden zu Deployment-Häufigkeit und Durchlaufzeit. Codezeilen werden zur Änderungsfehlerrate. Protokollierte Stunden werden zum Engineering NPS, denn wenn Ihr Team gesund ist und liefert, müssen Sie die Stunden nicht zählen.

Die QBR-Folie

Eine Folie, sechs Metrik-Zeilen, drei Spalten: aktuell, Ziel, Trend-Pfeil. Fügen Sie pro Zeile einen Diagnosesatz hinzu. Das ist das Format.

Beispiel-Layout:

Sechs Zeilen. Sechs Diagnosen. Keine story points. Kein im Anhang verstecktes Velocity-Diagramm. Wenn eine Zahl schlecht ist, sagen Sie es klar und benennen Sie, was Sie dagegen tun. VPs vertrauen EMs, die Probleme schneller benennen als der VP sie selbst entdeckt hätte. Sie misstrauen EMs, die verbergen.

Was Sie von Ihrem VP verlangen sollten

Schließen Sie den QBR mit einer Frage, nicht mit einem Siegesläufer. Fragen Sie, welche zwei der sechs Metriken für das Unternehmen in diesem Quartal am wichtigsten sind und welcher Zielbereich als Gewinn gelten würde.

Alle sechs gleichzeitig zu optimieren, ist der Weg, wie man nichts erreicht. Ein Team, das an Liefergeschwindigkeit arbeitet, arbeitet nicht gleichzeitig am Einstellungsdurchsatz, und ein Team, das an der Einstellung arbeitet, wird vorübergehend eine Verschlechterung der Durchlaufzeit erleben, während Seniors Kandidaten interviewen statt PRs zu reviewen. Wählen Sie zwei. Einigen Sie sich auf die Ziele. Stellen Sie die Frage nächstes Quartal erneut.

Wenn Ihr VP "alle sechs" sagt, schieben Sie sanft zurück. Sagen Sie: "Wenn ich in diesem Quartal zwei von ihnen unterdurchschnittlich investieren müsste, um zwei andere voll zu investieren, welche zwei sollte ich depriorisieren?" Diese Frage bekommt fast immer eine echte Antwort, weil sie einen Zielkonflikt ans Licht bringt.

Das ist die Version des QBR, mit der ich beim ersten Mal hätte hineingehen sollen. Sechs Metriken. Reale Zahlen. Benannte Diagnosen. Eine Folie. Das story-points-Diagramm bleibt in der Schublade, wo es hingehört.

Mehr erfahren

• The 1:1 Cadence That Actually Works
• Running an On-Call Rotation Without Burning the Team
• Performance Reviews for Engineers Without the Theater
• Hiring Senior Engineers in a Tight Market
• Companion JD: Staff Software Engineer