Moving from Blame to Accountability

Systemproblem

In 99% der traditionellen IT-Firmen endet eine Post-Mortem-Analyse eines schweren Server-Ausfalls mit dem Satz: "Entwickler X hat das falsche Skript ausgeführt. Wir haben ihn ermahnt, besser aufzupassen." Das ist "Blame" (Schuldzuweisung). Systemtheoretisch ist das absolut nutzlos. Wenn du den Menschen bestrafst, verdeckst du die Fehler im System, die es diesem Menschen überhaupt erst ermöglicht haben, auf den roten Knopf zu drücken. Die Folge: Entwickler verstecken ihre Fehler aus Angst, das Lernen der Gesamtorganisation stoppt, und die Architektur verrottet stillschweigend weiter.

Intervention

"Moving from Blame to Accountability" ersetzt personengebundene Schuldzuweisungen durch systemische Verantwortlichkeit. Die Denkweise dreht sich um 180 Grad: "Menschen machen keine Fehler. Das System war so schlecht designt, dass es den Entwickler getäuscht oder im Stich gelassen hat." Die Intervention etabliert eine "Blameless Post-Mortem" Kultur.

Erwartete Wirkung

Wenn Entwickler nicht mehr fürchten, gefeuert oder angeschrien zu werden, fangen sie an, radikal ehrlich über Beinahe-Katastrophen ("Near Misses") zu sprechen. Die Fehler-Kommunikation explodiert positiv. Architekten erhalten plötzlich den echten Roh-Traffic an Informationen, wo die CI/CD Pipeline schmerzhaft hakt. Fixes behandeln nun strukturelle Schwächen (z.B. "Wir bauen einen automatischen Syntax-Check ein") statt moralische Appelle ("Bitte strengt euch mehr an").

Nebenwirkungen und Risiken

"Blameless" wird von Junior-Managern oft missverstanden als "Konsequenzlos" (Niemand ist mehr für irgendwas verantwortlich). Das ist fatal. "Accountability" bedeutet harte Verantwortung für den *Lernprozess*. Wenn ein Dev die Produktion abschießt, verliert er nicht seinen Bonus. ABER er hat die absolute, unverhandelbare Pflicht (Accountability), in den nächsten 48 Stunden eine Architekturskizze vorzulegen, wie *das System* umgebaut wird, damit dieser Vorgang unmöglich gemacht wird.

Diagramm

Wann diese Intervention wirksam wird

Systemdenker wie Sidney Dekker (Just Culture) haben gezeigt, dass in hochkomplexen Umgebungen (wie verteilten Microservices) "Root Causes" als einzelner Fehlerteufel gar nicht existieren. Ausfälle sind fast immer das perfekte Zusammenspiel von 10 kleinen, völlig normalen System-Abweichungen. Die Suche nach dem "Schuldigen" ist daher wissenschaftlich inkorrekt.

Wodurch sich diese Intervention von anderen Hebeln unterscheidet

*Causal Loop Diagrams (CLD)* und das *Iceberg Model* können verwendet werden, um in der Retro zu beweisen, dass die "Schuld" nicht beim Entwickler lag. Die vorliegende Intervention ("Moving from Blame to Accountability") ist jedoch der sozial-psychologische Vertrag der Firma, der dem Entwickler überhaupt erst die psychologische Sicherheit (Psychological Safety) gibt, am CLD-Zeichnen teilzunehmen, ohne Repressionen zu befürchten.

Wie du die Intervention sauber einleitest

Banne die Frage "Wer war das?" aus allen technischen Incident-Reviews. Ersetze sie durch "Was ist hier passiert?", gefolgt von "Welche Informationen fehlten dem Entwickler in dem Moment der Entscheidung?" und "Wie hat die Architektur es zugelassen, dass ein lokaler Klick das globale System zerstören konnte?".

Erste Umsetzungsschritte

Diese Intervention muss zwingend Top-Down vom CIO oder CTO vorgelebt werden. Der stärkste Hebelpunkt zur Etablierung dieser Kultur ist der Moment, in dem ein Senior Manager oder Lead-Architekt vor der gesamten Entwicklermannschaft aufsteht und ausführlich zelebriert, wie er gestern selbst fast die Datenbank gelöscht hat und wie dumm *das System* an dieser Stelle war.

Woran du Wirkung erkennst

Erlauben die HR-Verträge bei der jährlichen Bonusauswertung überhaupt eine "Blameless" Kultur, oder werden dort noch immer harte Bug-Ticket-Zählungen von Individuen zur Bestrafung herangezogen?

Quellen

The Systems Thinker: Moving from Blame to Accountability

Peter Senge — The Fifth Discipline, Kap. 4: Personal Mastery

Sidney Dekker — Just Culture (Ashgate, 2012)