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 sehr 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, entlassen oder persönlich angegriffen zu werden, sprechen sie eher offen über Beinahe-Fehler ("Near Misses"). Die Qualität der Fehlerkommunikation steigt. Architekten erhalten bessere Informationen darüber, wo die CI/CD-Pipeline hakt. Fixes behandeln dann strukturelle Schwächen, zum Beispiel durch automatische Syntax-Checks, statt bei moralischen Appellen stehen zu bleiben.

Nebenwirkungen und Risiken

"Blameless" wird von Junior-Managern oft missverstanden als "Konsequenzlos" (Niemand ist mehr für irgendwas verantwortlich). Das ist fatal. "Accountability" bedeutet klare Verantwortung für den Lernprozess. Wenn ein Dev die Produktion abschießt, verliert er nicht seinen Bonus. ABER er hat die wichtige, 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 beeinträchtigen 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 ungeeignet 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 klare 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)