Incentive Redesign

Systemproblem

In der Systemtheorie gilt das eherne Gesetz: "Das System verhält sich exakt so, wie es belohnt wird." (The Folly of Rewarding A, While Hoping for B). In vielen IT-Organisationen hofft das Management auf "Stabile, Bugfreie Software" (B). Aber die Gehalts-Boni der Entwickler sind an "Anzahl ausgelieferter Features pro Quartal" gekoppelt (A). Die Folge: Entwickler hacken rasend schnell kaputten Code zusammen, kassieren den Bonus und die Support-Architektur bricht unter der Last der Incidents zusammen. Das ist kein Entwickler-Fehler, das ist ein "Perverse Incentive" (Perverser Anreiz / Cobra Effekt).

Intervention

"Incentive Redesign" (Umgestaltung der Anreize) zerschlägt diese toxische Belohnungslogik. Wenn Ops getrennt von Devs sitzt und Ops für "Uptime" und Devs für "Features" bezahlt werden, hast du zwei Todfeinde erschaffen. Die Intervention zwingt das Management dazu, Boni, Beförderungen und Lob ("Hero-Kultur") knallhart umzuprogrammieren. Anstatt den Typen zu feiern, der am Wochenende das brennende System heldenhaft rettet (Heroismus-Bonus), bekommt das Team den Bonus, dessen System so langweilig stabil lief, dass am Wochenende niemand angerufen werden musste.

Erwartete Wirkung

Wenn du das Karotten-Modell reparierst, repariert das Team die Architektur. Wenn der Bonus des Product Owners plötzlich anteilig daran gekoppelt wird, dass das Ops-Team ruhig schlafen kann, wird der Product Owner aus tiefstem Eigeninteresse freiwillig 20% seiner Sprint-Kapazität in das Refactoring von Legacy-Code investieren. Die künstlichen Grabenkämpfe zwischen "Feature-Geschwindigkeit" und "Stabilität" lösen sich auf, da alle am selben System-Anreiz hängen.

Nebenwirkungen und Risiken

Anreize (Incentives) sind extrem leicht zu hacken (Gamification of Metrics). Wenn du Entwickler danach belohnst, wie viel "Test Coverage" sie schreiben, werden sie hunderte Unit-Tests coden, in denen das assert() Statement fehlt. Sie erreichen 100% Coverage auf dem Dashboard, aber die Tests prüfen gar nichts. Jedes neue Incentive-System muss kybernetisch auf den "Gaming The System" Effekt abgeklopft werden. Gute Anreize messen daher *Outcomes* (Kundenzufriedenheit, Lead-Time) und niemals *Inputs* (Code-Zeilen, Commits).

Diagramm

Wann diese Intervention wirksam wird

Der klassische Cobra-Effekt besagt: Die britische Regierung in Indien wollte wilde Kobras loswerden und bot Geld für jeden toten Schlangenkopf (Incentive). Die Folge: Die Inder begannen sofort, hunderttausende Kobras im Keller zu züchten, um sie zu schlachten und das Geld zu kassieren. Als die Regierung misstrauisch wurde und den Bonus stoppte, ließen die Züchter die verbleibenden Kobras einfach auf die Straße frei. Am Ende gab es mehr Kobras als vorher. Genau das passiert, wenn du QA-Testern in der IT einen Amazon-Gutschein für jeden gefundenen Bug gibst.

Wodurch sich diese Intervention von anderen Hebeln unterscheidet

*Feedback Loop Redesign* verkürzt die Taktzeiten und lenkt Informationen um (Maschinen-Kybernetik). *Incentive Redesign* operiert auf der psychologischen und finanziellen Maslowschen-Ebene der Entwickler (Menschliche Kybernetik): Was belohnen wir auf Jahres-Meetings mit Applaus und Beförderungen?

Wie du die Intervention sauber einleitest

Reiße alle Bonuszahlungen nieder, die isoliert auf ein bestimmtes Team zielen (Silo-Anreize). Wenn Frontend und Backend konkurrierende OKRs haben, sabotieren sie sich. Führe als wichtigste Intervention "Shared OKRs" ein. Beide Teams gewinnen den Bonus nur, wenn die *End-to-End Zykluszeit* (Lead Time) des Gesamtfeatures sinkt.

Erste Umsetzungsschritte

Achte zwingend auf die Sprache der Führungskräfte in den All-Hands Meetings. Wen stellen sie auf die Bühne? Das Team, das durch fehlerhafte Planung das System crashte und es als "Helden" rettete? Oder das Team, dessen Backend völlig geräuschlos 2 Millionen Hits skalierte, ohne auch nur ein Wort darüber zu verlieren? Optimiere dein System auf "Boring IT" (Langweilige IT).

Woran du Wirkung erkennst

Sind unsere jährlichen Beförderungs-Guidelines explizit darauf ausgelegt, Ingenieure zu ehren, die "Probleme verhindern", anstatt nur Ingenieure zu fördern, die als Brandbekämpfer auffallen ("Hero Metrics")?

Quellen

Donella Meadows — Leverage Points, Punkt 6: Structure of Information Flows

Steven Kerr — On the Folly of Rewarding A While Hoping for B (Academy of Management, 1975)

Wikipedia: Perverse Incentive (Cobra Effect)