Alert Fatigue und Fuck Bingo

Über Profanität, Macht und darüber, was passiert, wenn ein Leader zum lautesten Alert im System wird

Der CTO beendete den Streit mit seiner Handfläche.

Sie knallte so hart auf den Konferenztisch, dass wir beide augenblicklich verstummten.

„Das ist doch Bullshit. Ihr wollt einfach nicht die Arbeit machen.“

Dann verließ er den Raum.

Ich war der VP of Engineering. Mein Gegenüber war unser Head of Backend Engineering, und wir hatten uns über mehr gestritten als nur die technische Entscheidung, die vor uns lag. Er sah das Infrastructure- und Security-Team als Blocker: Leute, die Aufgaben anhäufen, Regeln einführen und Entwickler ausbremsen. Ich sah in ihm jemanden, der jede Grenze als Einladung zum Verhandeln und jeden Vorschlag als etwas betrachtete, das man umgehen musste.

Als der CTO auf den Tisch schlug, hörte keiner von uns beiden mehr zu. Ich hatte meine Autorität ausgespielt. Ich hatte dem Head of Backend gesagt, dass die Ausrichtung der Engineering-Org meine Verantwortung sei und ich ihm nicht für jede Entscheidung eine Erklärung schulde. Er grub sich ein. Ich grub mich noch tiefer ein.

Der CTO hat den Konflikt nicht ausgelöst. Was er tat, war, ihn von einer Meinungsverschiedenheit in einen Befehl zu verwandeln.

Er kam später zurück, nachdem er sich beruhigt hatte. Keine Entschuldigung, kein Versuch, aufzudröseln, was passiert war. Wir einigten uns darauf, etwas zu tun, das er ohnehin schon vorgeschlagen hatte. Auf dem Papier hatte das Meeting eine Entscheidung hervorgebracht. In der Praxis hatte es eine Lektion hervorgebracht: Konflikt war nur so lange akzeptabel, bis die mächtigste Person im Raum genug davon hatte.

Ich habe die Lektion gelernt. Ich habe dafür gesorgt, dass es vor ihm nicht noch einmal zu so einer Meinungsverschiedenheit kam. Ich hörte auf, den Head of Backend zu führen, und bat den CTO, die Beziehung zu übernehmen.

Damals nannte ich das Deeskalation. Rückblickend hatte ich mich kleiner gemacht, um eine weitere Explosion zu vermeiden.

Das menschliche Alerting-System#

Man hätte den Ausbruch leichter abtun können, wäre er selten gewesen. War er aber nicht.

Ein kaputtes Deployment konnte ein „Warum hast du das nicht vorher getestet, verdammt noch mal?“ auslösen. Aus einem Problem in der Mobile App wurde „Leute, nichts funktioniert. Nichts. Wir sind gerade komplett down.“ Die Entwickler hörten, dass das Produkt peinlich sei, die Qualität schlecht und dass es offenbar niemanden interessierte.

Irgendwann startete das Unternehmen einen 30-tägigen Hackathon, um das Release eines Produkts durchzudrücken. Die Führung schaffte große Countdown-Uhren an. Einen Monat lang wurde das Verstreichen der Zeit selbst zum Alarm.

Bei Ausfällen oder Incidents reagierte das Infrastruktur-Team so, wie Site Reliability Teams es gelernt haben: ruhig stürzten sie sich auf die Herausforderung, untersuchten sie und blieben wachsam. Das waren Engineers auf der Ebene, auf der schon eine kleine Änderung die größten Auswirkungen haben kann – die Möglichkeit eines Ausfalls war also real, gerade während eines 30-tägigen Hackathons mit kaum bis gar keinen klaren Anforderungen von einem nicht existenten Produktteam. Aber jeder Defekt, jedes Experiment und jede Meinungsverschiedenheit landete auf ungefähr demselben rhetorischen Schweregrad.

Mit der Zeit fingen die Witze an.

„So würde es der CTO sagen“, schrieb dann jemand privat. Ein Engineer scherzte, er würde für den Monat ein „Fuck-Bingo“ führen.

Fuck-Bingo war nicht nur Galgenhumor. Es war Deduplizierung. Die Engineers hatten sich einen sozialen Filter für das Rauschen der Führungsebene gebaut.

Im Site Reliability Engineering ist ein Alert nicht bloß die Beschreibung dessen, was ein Monitoring-System beobachtet hat. Er ist ein Anspruch auf die Aufmerksamkeit eines Menschen. Ein guter Alert signalisiert eine relevante Auswirkung und fordert eine Handlung ein. Ein schlechter feuert, weil sich eine Zahl bewegt hat.

Googles SRE-Leitfaden warnt davor, dass ein niedriges Signal-Rausch-Verhältnis zu Alert Fatigue führt. Menschen werden nicht wachsamer, wenn ein System sie ständig alarmiert. Sie lernen, dass man dem Alarm nicht trauen kann.

Führungssprache funktioniert genauso, nur dass Hierarchie zusätzliche Spannung reinbringt. Eine Nachricht von einem CTO wird nicht so gelesen wie eine von einem Kollegen auf Augenhöhe. Sie kommt von jemandem, der eine Roadmap umlenken, eine technische Entscheidung überstimmen und beeinflussen oder entscheiden kann, ob du noch einen Job hast.

Jedes „STOP“, jedes „ASAP“, jedes „Nichts funktioniert“ vergibt einen Schweregrad. Wenn alles wie ein SEV-1 klingt, gehen der Organisation irgendwann die Worte für einen echten Notfall aus.

Die naheliegende Schlussfolgerung wäre, dass Führungskräfte aufhören sollten zu fluchen, aber ehrlich gesagt halte ich das nicht für die richtige.

Es gibt einen Unterschied zwischen „dieser verdammte Ausfall“ und „Was machst du da, verdammt noch mal?“. Das Erste stellt Sprecher und Zuhörer auf dieselbe Seite einer beschissenen Situation. Das Zweite macht den Zuhörer zum Incident.

Fluchen kann Humor, Vertrautheit, Überraschung oder gemeinsame Frustration signalisieren. Es kann aber auch demütigen. Was die Bedeutung verändert, ist nicht das Wort allein, sondern seine Richtung und die Macht dahinter. Slack macht diese Unterscheidung schwerer: Es nimmt das Grinsen und den Tonfall weg, bewahrt aber die Hierarchie.

Charity Majors flucht reichlich in ihren Texten. Sie gibt Managern aber auch eine viel bessere Regel an die Hand in „An Engineer’s Bill of Rights (and Responsibilities)“: Sprich die harten Dinge aus, bring Dringlichkeit rein, wenn sie nötig ist, und versuch, deine Emotionen nicht zum Problem aller anderen zu machen.

Und genau bei diesem letzten Teil scheitert alarmierende Sprache. Sie überträgt den inneren Zustand der Führungskraft auf die Organisation und nennt das Ergebnis Alignment.

Ein ruhigeres Unternehmen ist kein sichereres#

Im Unternehmen wurde es schließlich ruhiger. Sicherer wurde es dadurch nicht.

Die Engineers lernten, Vorschläge erst dann einzubringen, wenn jede Annahme wasserdicht war. Neue Architekturideen und Proofs of Concept blieben so lange unsichtbar, bis sie kaum noch angreifbar waren – was den Iterationsprozess verlangsamte. Manche Pipeline-Failures wurden behoben, ohne dass sie je zur Sprache kamen. Sicherheitsprobleme wurden nicht immer so offen gemeldet, wie es nötig gewesen wäre. Und am schlimmsten: Konflikte zwischen Menschen in ihren Rollen wurden gar nicht mehr ans C-Level herangetragen – außer natürlich, das C-Level holte dich mit HR ins Zimmer und bat dich um Feedback zu jemandem, den es ohnehin feuern wollte.

Die Bugs verschwanden. Die Umstände, die sie hervorbrachten, nicht.

Genau diesen Kreislauf beschrieb John Allspaw in Etsys „Blameless PostMortems and a Just Culture“. Wenn Menschen mit Bestrafung oder Demütigung rechnen, verschweigen sie genau die Details, die man braucht, um zu verstehen, warum ein Fehler für sie im Moment sinnvoll erschien. Allspaw nannte das Ergebnis „Cover-Your-Ass-Engineering“: Das Management weiß weniger, latente Probleme bleiben unsichtbar, und dieselbe Art von Fehler wird umso wahrscheinlicher wieder auftauchen.

Das Team machte nicht weniger Fehler. Es lieferte nur keine brauchbaren Erkenntnisse mehr darüber.

Eine Führungskraft, die schlechte Nachrichten bestraft, legt am Ende ihre eigene Observability lahm.

Das ist – mehr noch als die Kraftausdrücke selbst – der Preis. Die Organisation beginnt, den Anschein von Kontrolle zu optimieren. Führungskräfte bekommen sauberere Status-Updates und ausgefeiltere Vorschläge. Sie hören weniger Einwände. Von oben sieht das nach Disziplin aus. Von unten fühlt es sich an, als lernte man, welche Informationen sicher zu teilen sind.

Es wäre verlockend, den CTO in dieser Geschichte zum simplen Bösewicht zu machen. War er aber nicht.

Er gehörte zu den technisch begabtesten Leuten im Unternehmen. Eine fachliche Diskussion mit ihm konnte wirklich großartig sein. Sein Beharren auf Standards machte den Code meistens besser. Das Produkt lag ihm sehr am Herzen, und er verstand Teile des Systems besser als jeder andere.

Genau das machte es schwieriger, dieses Verhalten in Frage zu stellen – und zugleich lehrreicher.

Führungsversagen beginnt oft als Stärke ohne Bremse. Fachliches Urteilsvermögen wird zum Bedürfnis, alles zu reviewen. Hohe Standards werden zur Geringschätzung unfertiger Arbeit. Die Fähigkeit, ein Projekt zu retten, wird zur Gewohnheit, es zu übernehmen.

Manchmal verschwand der CTO in einem Solo-Arbeitsrausch und schrieb neu, woran die Entwickler eine Woche gebaut hatten. Der Rewrite war vielleicht sogar besser. Er brachte dem Team aber auch bei, dass Ownership nur vorläufig war: Deine Arbeit gehörte dir, bis die Person mit mehr Autorität beschloss, wieder Individual Contributor zu werden.

Michael Lopp bezeichnet dies als „Management via Worry and Crisis“. Seine nützlichste Beobachtung ist nicht, dass krisengetriebene Manager irrational handeln. Sondern dass eine Krise zum Bewältigungsmechanismus für den Kontrollverlust werden kann, der mit Führung einhergeht. Die Organisation wächst; die Arbeit rückt weiter weg; andere treffen Entscheidungen, die du nicht getroffen hättest. Eine Krise heraufzubeschwören holt die Arbeit – und die Aufmerksamkeit aller – zurück zu dir.

Es funktioniert – kurz. Deshalb überlebt die Gewohnheit.

Die Leute halten inne. Sie hören zu. Sie handeln. Die Führungskraft spürt, wie die Organisation reagiert.

Doch Bewegung ist nicht dasselbe wie Verständnis, und Gehorsam ist nicht dasselbe wie Commitment.

Befehle brauchen ein Ablaufdatum#

Den größten Teil meiner Karriere habe ich in Infrastructure und Security verbracht – dort gebaut und dafür programmiert … Systeme fangen tatsächlich Feuer. Manchmal ist der richtige Satz ein Imperativ.

„Stopp mit dem Deployen.“

Während eines Incidents kann dieser Befehl verhindern, dass fünf gut gemeinte Leute fünf neue Variablen einbringen. Wenn die Rolle des Incident Commander verstanden ist, weiß das Team, wer die Response koordiniert und wann die normale Entscheidungsfindung ausgesetzt ist. Ein gutes Incident Command liefert genug Kontext zum Handeln: Deployments stoppen, der Checkout schlägt fehl, Maria ist Incident Commander, Erkenntnisse in den Incident-Channel, nächstes Update um 14:25.

Die Legitimität kommt nicht aus der Lautstärke. Sie kommt aus dem Protokoll. Die Autorität wird deklariert, ist auf den Incident begrenzt und nützt den Leuten, die die Arbeit machen.

Imperativische Sprache sollte eine TTL haben.

Joel Spolsky hat in „The Command and Control Management Method“ eine verwandte Unterscheidung getroffen. Command and Control kann sinnvoll sein, wenn Soldaten in einer Situation auf Leben und Tod sofort handeln müssen. Software-Organisationen sind anders: Die Person, die am dichtesten an der Arbeit dran ist, hat meist relevantere Informationen als die Führungskraft, die gerade den Raum betritt. Spolsky nannte die darauf folgende Unterbrechung durch die Führungskraft „Hit-and-run-Mikromanagement“. Die Führungskraft wirft die Arbeit aus der Bahn und zieht weiter, bevor sie mit den Konsequenzen leben muss.

„Mach es einfach und stell es nicht infrage“ hat kein Protokoll und kein Ablaufdatum. Es behandelt ganz normale Wissensarbeit als Dauer-Incident und Widerspruch als Versagen bei der Umsetzung.

Entschlossenheit verlangt diesen Deal nicht.

In dem Meeting, in dem der CTO auf den Tisch haute, hätte er uns immer noch unterbrechen können. Er hätte sagen können: Stopp. Ihr streitet über Zuständigkeit, nicht über das Problem. Jeder von euch fasst das Anliegen des anderen zusammen. Dann wählen wir den kleinsten Proof of Concept. Wenn ihr euch dann immer noch uneinig seid, treffe ich die Entscheidung und erkläre, warum.

Das sind Kommandos. Aber sie hätten dem Konflikt auch einen Ort gegeben, an den er gehen kann.

Die härtere Wahrheit ist: Ich wollte, dass der CTO eine Form von Leadership zeigt, die ich selbst schon versäumt hatte zu zeigen.

Ich hatte meinen Titel benutzt, um einen Streit zu beenden. Meine Sprache war ruhiger, aber die Botschaft war dieselbe: Ich entscheide; du fügst dich. Am Anfang meiner Karriere dachte ich, Autorität bedeute, dass ich mich nicht mehr mit so vielen Leuten abstimmen muss. Als ich wuchs, mich weiterbildete, Mentoring und Coaching von Menschen bekam, die ich immer noch bewundere, wie „Ingrid Rivera“ habe ich gelernt, dass Autorität die Pflicht vergrößert, Kontext zu liefern – besonders dann, wenn andere gar nicht die Macht haben, deine Entscheidung abzulehnen.

Kontext ist kein Konsens. Rücksprache ist kein Veto. Eine Führungskraft kann sagen, dass ein Projekt bereits läuft und ohne neue Belege nicht gestoppt wird. Die Tür, die offen bleiben muss, ist schmaler: Zeig mir, welche Annahme falsch ist, und wir korrigieren den Kurs.

Ich arbeite ständig daran. Coaching und Journaling helfen, aber der nützliche Moment ist viel kleiner: die Pause zwischen dem Gefühl, übergangen zu werden, und dem Versuch, zu beweisen, dass ich die Autorität im Raum bin. Verteidige ich die Entscheidung, oder verteidige ich mich selbst?

Wenn ich diesen Moment verpasse, muss auch die Wiedergutmachung klar sein: Ich habe meinen Rang ausgespielt. Das hat das Gespräch abgewürgt. Tut mir leid. Lass es uns wieder öffnen.

Mein Vater hatte eine weniger technische Version von all dem:

Tenés dos orejas y una boca: escuchá el doble de lo que hablás.

Du hast zwei Ohren und einen Mund. Hör doppelt so viel zu, wie du redest.

Das sagte er immer, als ich jung war und dazu neigte, mich in eine Situation zu stürzen, bevor ich sie verstanden hatte. Ich habe Jahre gebraucht, um zu erkennen, dass dieser Rat umso wichtiger wird, je mehr Autorität du bekommst. Je höher du steigst, desto weniger Leute sagen dir, dass du zu laut bist. Stattdessen bauen sie Filter.

Führungskräfte merken selten den Moment, in dem ihre Dringlichkeit zu Lärm wird. Das Team merkt es zuerst.

Wenn du Glück hast, machen sie dann eine Bingo-Karte. Wenn nicht, hören sie einfach auf, dir zu sagen, was schiefläuft.