- Je senioriger ein Engineer, PM oder Designer ist, desto eher sollte er mindestens einen zentralen Metrik-Graphen besitzen, für den er verantwortlich ist – und das ist einer der schnellsten Wege, in der Arbeit gut zu werden
- Die wichtigen Probleme, mit denen man sich auf Senior-Level befassen sollte, lassen sich meist als Graph darstellen; verlangt ist, direkt Verantwortung für Metriken zu übernehmen, die langfristige Veränderungen zeigen, etwa Seitenzahl, Performance, Kosten, Umsatz oder Churn
- Ein Graph zeigt im Gegensatz zu einem Satz wie „um 15 % reduziert“ Größenordnung, Trend, Volatilität und Zeitpunkt auf einmal und ist das stärkste Kommunikationsmittel, um Impact zu erklären und überprüfbares Vertrauen zu gewinnen
- Eine Schleife, die Graphen mit Zielsetzung und Review verbindet, vereinfacht Performance-Tracking und Feedback radikal und kann zu einem Unterschied führen, der High Performance und Arbeitslosigkeit voneinander trennt
- Ein guter Graph sollte zu den wenigen wichtigen Dingen gehören, auf die andere oft Bezug nehmen; einen einzelnen Graphen für Qualität, Support, Umsatz oder Retention bis zum Ende zu verantworten und in Bewegung zu bringen, ist eine Kernrolle von Seniors
Wichtige Probleme bearbeiten
- Auf Senior-Stufe ist es unverzichtbar, „große und wichtige Probleme“ zu verantworten, und diese Probleme lassen sich meist als Graphen darstellen, die Veränderungen über die Zeit zeigen
- Beispiele: weniger Seiten, bessere Performance, geringere Kosten, steigender Umsatz, sinkender Churn
- Über einen Zeitraum von mindestens einem Quartal sollte sich das Ergebnis der eigenen Arbeit als sichtbare Kurve zeigen
- Nicht jede Arbeit muss direkt mit einem Graphen verbunden sein, aber wenn man nicht einmal für einen einzigen Graphen verantwortlich ist, erfüllt man seine Senior-Rolle nicht richtig
Impact klar vermitteln
- Ein häufiges Problem bei Seniors ist die Beschwerde, dass ihre Leistung nicht verstanden wird; das sollte meist als Kommunikationsversagen gesehen werden
- Schickt man nur einen Satz wie „Ich habe die Seitenzahl um 15 % reduziert“, entstehen sofort viele Zusatzfragen zu Ausgangspunkt, Zeitraum, Trend und Zufallseffekt
- Ein Graph zeigt bei solchen Fragen Skalierung, historische Entwicklung, Volatilität und Zeitpunkt der Veränderung auf einen Blick
- Außerdem kann man einen Link zur Datenquelle mitliefern, sodass das Gegenüber die Wahrhaftigkeit des Graphen leicht selbst prüfen kann
- Wenn man Impact nur in vagem Text ausdrückt, ist es schwer, scharfes Feedback dazu zu bekommen, ob die aktuelle Arbeit die richtige ist und ob der Effekt die Investition rechtfertigt
- Drückt man ihn dagegen als Graph aus, erhält man Anerkennung für den eigenen Beitrag und zugleich klares Feedback zu Richtung und Prioritäten
- Ein Graph ist ein Mittel, den Wert der Arbeit und ihren Effekt im Verhältnis zur eingesetzten Zeit klar sichtbar zu machen
Alle Elemente zu einem Ganzen verbinden
- Wie im früheren Beitrag On Achieving Goals beschrieben, lässt sich der Prozess, Dinge zu erreichen, als einfache Schleife aus „Ziele setzen → überprüfen“ zusammenfassen
- Gute Ziele setzen, klare Verantwortliche benennen und über regelmäßige Check-ins Status und nötige Anpassungen prüfen – diese einfache Struktur ist das Wesen von Zielerreichung
- Die meisten gescheiterten Ziele gehen auf schlechte Zielsetzung zurück, etwa wertlose Ziele, falsche Prioritäten oder fehlende Verantwortliche, sowie auf den Zusammenbruch grundlegender Prozesse wie zu wenige oder schlecht geführte Check-ins
- Präzise Ziele und konsequente Reviews sind die Grundinfrastruktur dafür, dass Organisationen echte Veränderungen bewirken; ohne sie lässt sich kein Ziel dauerhaft erreichen
- Dieser Beitrag fügt dazu die zusätzliche Regel hinzu: Kombiniere das mit einem Graphen
- Das heißt: Ziele setzen und anschließend eine Schleife etablieren, in der ein einzelner Graph, der dieses Ziel repräsentiert, regelmäßig überprüft wird
- Diese Kombination kann ein so starkes Werkzeug sein, dass sie High Performer von Arbeitslosigkeit trennt
Zusammenfassung
- Graphen sind für Seniors die zentrale Einheit, um Fortschritt zu verfolgen, Ergebnisse zu zeigen und Feedback zu erhalten
- Für einen einzelnen Graphen Verantwortung zu übernehmen und ihn voranzutreiben, ist die praktische Einheit von Ownership
- Wenn du aktuell keinen Graphen verantwortest, such dir sofort einen und übernimm Ownership dafür
Appendix: Tipps & Tricks zum Besitz eines Graphen
- Wenn du einen Graphen hast, den andere oft zitieren, bist du auf dem richtigen Weg
- Menschen sind meist faul; wenn es einen hilfreichen und präzisen Graphen gibt, neigen sie dazu, ihn einfach zu übernehmen, statt ihn neu zu erstellen
- Solche Graphen wirken sich ganz natürlich auch positiv auf die eigene Karriere aus
- Ein Graph muss nicht von Anfang an perfekt sein; ihn über Feedback schrittweise zu verbessern, ist der eigentliche Besitz
- Ein Anti-Pattern, das man vermeiden sollte, ist „zu viele Graphen zu besitzen“
- Manche sammeln unzählige Graphen und behaupten, sie zu „besitzen“, nur um sie in dem Moment zu nutzen, der zur eigenen Story passt
- Ein guter Zustand ist dagegen, nur eine extrem kleine Zahl wirklich wichtiger Graphen tiefgehend zu verantworten
- Wie in „You have too many metrics” gesagt: Metriken und Graphen sollten wenige, aber tödlich nützliche sein
- Für Engineers sind Qualitätsprobleme ein guter Startpunkt, wenn sie einen Graphen finden wollen
- Seitenzahl, Incidents, Bugs, Performance lassen sich alle gut in Graphen abbilden und sind Bereiche, die darauf warten, dass jemand Verantwortung übernimmt
- Aus Sicht von PMs und Designern sind Support-Tickets, Umsatz, Win-Rate gegen Wettbewerber und die Attach Rate zusätzlicher Produkte, die Retention beeinflussen, gute Kandidaten
- Es ist nicht nötig, eine Metrik ausschließlich aus eigener Kraft bewegen zu können
- Schon allein dadurch, eine wichtige Metrik konstant zu beobachten und Menschen hartnäckig auf eine gemeinsame Richtung auszurichten, kann man die eigene Karriere stark voranbringen
8 Kommentare
Meine Gewichtskurve zeigt nach oben.
Die Entwicklung meines Gehalts liegt seit fünf Jahren bei 0 %.
Es ist zwar schwer zu verallgemeinern, aber als bestes Werkzeug, um zunächst die Führungsebene zu überzeugen, ist es auf jeden Fall geeignet.
Normalerweise fand ich es immer sinnlos, Erfolge in Prozenten herauszustellen, und dieser Artikel scheint meinen Gedanken zu vervollständigen.
Nicht „zum Umsatzanstieg von 5 Prozent beigetragen“, sondern man sollte sagen, um wie viel der Umsatz in welchem Zeitraum gestiegen ist und wie viel steiler dieser Anstieg im Vergleich zur Zeit vor dem eigenen Beitrag geworden ist.
Ich hielt die Fähigkeit, Leistungen oder Ziele in Zahlen auszudrücken, für wichtig, aber dieser Artikel sagt, dass man sie sogar in Form von Grafiken darstellen sollte. Das ist ein Punkt, der im Hinblick auf Verständnis und Vertrauenswürdigkeit beim Gegenüber nachvollziehbar ist.
Dann ist dieser Graph vermutlich mit hoher Wahrscheinlichkeit anfällig für Verzerrungen.
Goodharts Gesetz: "Sobald eine Messgröße zum Ziel wird, taugt sie nicht länger als gute Messgröße."
Als Zitat, das Goodharts Gesetz widerlegt,
kam mir der Ausspruch in den Sinn, der Peter Drucker zugeschrieben wird: "Was man nicht messen kann, kann man nicht managen (If you can't measure it, you can't manage it)."
Als ich weiter nachforschte, stellte ich fest, dass selbst das Drucker Institute sagt, Drucker habe so etwas nie gesagt.
Stattdessen habe ich eher eine gegenteilige Aussage gefunden.
Zu glauben, dass man etwas, das man nicht messen kann, nicht managen kann, ist falsch – das ist ein kostspieliger Mythos. (It is wrong to suppose that if you can't measure it, you can't manage it—a costly myth) - Edward Deming
Trotzdem glaube ich, dass es sinnvolle Messgrößen gibt. Besonders effektiv wäre es wohl, wenn es jemanden gäbe, der für zwei gegensätzliche Kennzahlen gleichzeitig verantwortlich ist. Aus SRE-Sicht kann man sich zwar darüber freuen, die Zahl der Störungen gesenkt zu haben, aber wenn man dafür bei jedem Schritt übervorsichtig ist, verzögern sich Deployments und die Feature-Entwicklung wird langsamer. Und aus Dev-Sicht kann man sich zwar darüber freuen, viele Features entwickelt zu haben, aber dafür könnte auch die Zahl der Störungen entsprechend steigen.
Kennzahlen wie p99-Latenz, Erfolgsquote bei Antworten, Kosten pro Anfrage, MTTR oder die Anzahl der Störungen halte ich ebenfalls für gute Metriken, die sich nur schwer missbrauchen lassen. (Natürlich können auch sie missbraucht werden, aber ich glaube, dass das Nachverfolgen und Verwalten am Ende mehr Nutzen als Schaden bringt ...)