2026-05-02
Der Begriff Key-Performance-Indicator (KPI) bzw. Leistungskennzahl bezeichnet in der Betriebswirtschaftslehre Kennzahlen, anhand derer der Fortschritt oder der Erfüllungsgrad hinsichtlich wichtiger Zielsetzungen oder kritischer Erfolgsfaktoren innerhalb einer Organisation gemessen und/oder ermittelt werden kann (siehe auch betriebswirtschaftliche Kennzahl).
Nach dem Beweis, dass ich auch ein bisschen Clickbait kann, direkt einmal zurückrudern: Natürlich sind Metriken und Kennzahlen wichtig, im Unternehmen (zum Beispiel die Auslastung der Mitarbeitenden ist schon relevant für den Start oder die Auswertung von Projekten und ohne Umsatz geht es denn auch nicht), aber auch privat, natürlich möchte ich wissen, ob mein Training als Läufer effektiv und am Ende sogar effizient ist.
Aber, so wenig wie der Weg immer das Ziel ist, so wenig ist das Ziel immer alles. Das gilt für mich sowohl im Sport als auch im Arbeitsalltag. Mein Freund Greg hat mich mit seinem Text “Don’t force me to follow your philosophy” (“Zwinge mir nicht Deine Philosophie auf”) aktuell auf diese Gedanken gebracht. In Gregs Beitrag geht es um die Leaderboard-Funktionalität von Garmin Connect, einer Trainingsplattform die eng mit den Sportuhren und Geräten des gleichnamigen Herstellers verknüpft ist. Im Vergleich zu anderen Plattformen, die zu jeder möglichen und unmöglichen Gelegenheit daran erinnern, doch bitte seinen Streak fortzusetzen oder an der nächsten gesponsorten Herausforderung teilzunehmen, ist Garmin verhältnismäßig unauffällig hinsichtlich Challenges, aber vom Leaderboard gibt es kein Entkommen. Irgendwo in Olathe wird es wohl mal einen Produktmanager gegeben haben, zu dessen KPIs die Nutzung des Feature “Leaderboard” gehörte… Und wir sind Teil des ganzen, ob wir wollen oder nicht.
Zu meiner Schande muss ich gestehen, dass ich eine schwache Stelle für Gamifizierung dieser Art habe und an vielen dieser Herausforderungen teilgenommen habe. Während mein Garmin-Account weitestgehend privat ist, war ich auf Strava sehr öffentlich sehr aktiv. Anfang des Jahres 2026 habe ich die Reißleine gezogen und den Account weitestgehend still gelegt und dort nur noch wenige Rennen veröffentlicht. Warum? Weil ich mich so sehr auf die Performance-Indikatoren “Badges”, “PRs” und “Likes” fokussiert habe, dass ich sicherlich nicht mehr effektiv trainiert habe. Effektiveres Training erreiche ich auch nicht, wenn mir die Plattform an jeder Stelle die wildesten Bezeichnungen für Intervall-Trainings und mehr um die Ohren wirft.
Ja, ich möchte die Freiheit haben, einfach nur Laufen zu gehen… Oder eine Runde schwimmen oder radeln. Ich muss daraus keine Challenge machen. Ich muss davon kein Kurzvideo veröffentlichen und ich brauche zu meinem großen Glück auch keine Kollaborationen, um mir ein Paar Laufschuhe leisten zu können. Obendrein: Was für mich funktioniert, muss noch lange nicht für andere funktionieren, und ich muss niemanden zu seinem Glück überreden, dass Fritten mit Erdnußsauce, Mayo und frischen Zwiebeln (“Patatje Oorlog” oder “Friet Oorlog”, wie die Niederländer sagen), die perfekte Sportlernahrung sind.
Am Ende stehen für mich die Kennzahlen glücklich sein, fit bleiben und vielleicht das eine oder andere Rennen nicht ganz schlecht abzuschließen (und bevor jemand fragt: Ja, ich nutze locker strukturierte Trainingsprogramme, aber überwiegend einfach Klassiker wie ab und zu lange bzw. kurze Intervalle, Rumpfstabilität und Krafttraining, ob es zu schnell oder zu langsam war, ist in der Regel fühlbar, eine Sportuhr und ein paar nette Auswertungen schaden natürlich nicht).
Was hat das ganze mit Softwareentwicklung zu tun? In meiner gesamten Karriere bin ich nie in einer Position oder Rolle gewesen, in der Lines-of-Code (LoC) oder die absolute Anzahl Features pro Zeiteinheit die entscheidende Kennzahl gewesen wären. Darüber bin ich ausgesprochen froh, denn eigentlich ist bekannt, dass auch hier nicht auf den eigentlichen Inhalt, sondern auf die Kennzahl optimiert wird, bewusst oder unbewusst. Wird eine möglichst hohe Testabdeckung gefordert, so ist das trivial herzustellen, ohne ernsthaft die wichtigen Testfälle zu implementieren. Spielt nur die Anzahl der Features eine Rolle und nicht die Qualität “Fehlerfreiheit” dann kommt am Ende halt so etwas wie Googles Friedhof vergessener Produkte, Windows 11 oder macOS 26 dabei heraus.
Die großen Spieler der Branche versuchen leider uns allen gerade weiß zu machen, dass Output und Durchsatz alles ist, was zählt. Hauptsache neue “Apps” in möglichst hoher Taktung, generiert von LLMs und Transformatoren. Verständnis: Nebensächlich. Fehlerfreiheit: Ebenso. Wer danach gefragt hat? Wen interessiert denn das, wenn wie mit der Schrotflinte versucht wird, die nächste, große App zu generieren, die Milliarden Geldeinheiten Gewinn verspricht. Am Ende ist es witzig: Auf der einen Seite wird Spezifikationsgetriebene Entwicklung als das neue, große Dingen propagiert (Nein, ist es nicht), auf der anderen Seite scheint diesen Spezifikationen auch nur noch in der Echokammer des inneren Monologes oder mit einem Chatbot geschrieben zu werden.
So wenig wie ich einen Marathon ohne Training und strukturierte Vorbereitung laufen möchte, so wenig könnte ich mich zu einem Training mit hohen Volumen ohne Ziel motivieren. Im Vorfeld definiere ich, wohin ich möchte, lerne auf dem Weg, und passe mich an. Und dann kommt der Tag, an dem geliefert wird.
Ich kann keine gute Software liefern, ohne Zeit für Diskussionen, Planung und Training zu haben. Mein Training, nicht dass der Machine. Genauso wie es für den eigenen Körper Empathie braucht, braucht es auch für diese Arbeit Empathie: für die Anforderungen der Zielgruppe, für die Zielplattform und vieles mehr. Die meisten Dinge, die einen langfristigen Erfolg ausmachen, werden der Quantität und dem schnellen Gewinn geopfert.
Um den Bogen zu schließen: Wichtiger als absolute KPIs sind Metriken, und die auch nur dann, wenn sie korrekt interpretiert werden. Meine vertikale Laufbewegung in absoluten Zahlen ist hoch, in Verhältnis zur Schrittlänge aber in Ordnung. Da muss ich nicht optimieren. Meine Schrittzahl hat hingegen Potenzial: weniger Belastung, mehr Tempo.
Testabdeckung von 50% ist vielleicht zu wenig. Deckt sie hingegen Code mit hoher zyklomatische Komplexität vollständig ab, kann das ausreichend sein.
Abschließend möchte ich noch den Hinweis auf “Goodharts Gesetz” ergänzen und mich bei Eberhard bedanken:
“Jede beobachtete statistische Regelmäßigkeit wird tendenziell zusammenbrechen, sobald zu Kontrollzwecken Druck auf sie ausgeübt wird.“
Bei Goodhart ging es ursächlich um Fragestellungen zur Geldmengenregulierung. Bereits 1975 beschrieb er, wie Investoren versuchen, derart zu investieren, dass sie von Marktregulierungen profitieren. Die jeweiligen Subjekte der Regulierung verlieren damit ihre Funktion als Indikator für ökonomische Trends, da sie erst durch die entsprechenden Kontrollmechanismen als Optimierungsziel interessant wurden.
Vielleicht tun wir gut daran, mit Wissen um Dinge zu erhalten und menschliche sowie mechanische Empathy zu Entwickeln, um mit Metriken anstelle für absolute Indikatoren zu optimieren.