Dem Plan folgen — in den Berg hinein

10 Min. Lesezeit

Wenn dem Plan folgen bedeutet, gemeinsam zu sterben

Es war fünf Tage vor Weihnachten. Einhundertneunundfünfzig Menschen flogen nach Hause zu ihren Familien. Manche hatten Geschenke im Gepäckfach über sich. Manche dachten bereits an die Mahlzeiten, die sie teilen würden, die Gesichter, die sie sehen würden, die Umarmungen, die am Ankunftsgate in Cali auf sie warteten.

Sie kamen nie an.

Die Nacht, in der der Berg gewann

American Airlines Flug 965 war ein Routineflug von Miami nach Cali, Kolumbien. Die Boeing 757 war in einwandfreiem technischen Zustand. Der Kapitän hatte über dreizehntausend Flugstunden. Der Erste Offizier war erfahren und kompetent. Das Wetter war klar in der Höhe.

Nichts war falsch — außer dass alles katastrophal schiefgehen sollte.

Während des Anflugs bot die Flugsicherung eine Abkürzung an. Die Crew nahm an. Eine einfache Änderung am Plan. Sie begannen, den Flugmanagementcomputer neu zu programmieren und gaben einen neuen Wegpunkt ein: „R” für Rozo, die Navigationsbake in der Nähe von Cali.

Aber der Buchstabe R rief zuerst eine andere Bake auf. Eine in der Nähe von Bogotá. Einhundertdreißig Kilometer entfernt. In der falschen Richtung.

Die Crew wählte sie aus. Das Flugzeug, gehorsam wie immer, schwenkte nach links und begann, von Cali wegzufliegen, direkt auf die Anden zu.

Sie bemerkten es nicht. Die Instrumente zeigten ihnen, dass sie auf Kurs waren — dem Kurs, dem der Computer folgte, nicht dem Kurs, den sie beabsichtigt hatten. Die Piloten vertrauten dem Plan. Sie hatten ihn selbst eingegeben. Warum sollten sie ihn anzweifeln?

Draußen vor den Fenstern, unsichtbar in der Dunkelheit, erhoben sich die Berge.

Die letzten Sekunden

Um 21:41 Uhr erwachte das Bodenannäherungswarnsystem schreiend zum Leben: „TERRAIN, TERRAIN. PULL UP. PULL UP.”

Der Kapitän reagierte sofort. Er schob die Schubhebel nach vorne. Er zog die Nase hart hoch. Das Flugzeug reagierte — es tat alles, was es konnte, um zu steigen, zu entkommen, zu überleben.

Aber jemand hatte die Bremsklappen vom Sinkflug noch ausgefahren gelassen. Diese Flächen auf den Tragflächen, konstruiert um das Flugzeug zu verlangsamen, stahlen den Auftrieb, den sie so verzweifelt brauchten. Die Crew bemerkte es nicht. Sie waren auf den Steigflug fokussiert. Sie folgten dem Rettungsverfahren.

Sechs Sekunden später schlug Flug 965 in die Flanke des El Diluvio — „Die Flut” — ein Bergrücken, der sich auf fast dreitausend Meter erhebt.

Vier Passagiere überlebten, aus dem Wrack geschleudert. Einhundertneunundfünfzig Menschen — Eltern, Kinder, Kollegen, Freunde — nicht.

Das ist keine alte Geschichte

Ich erzähle Ihnen diese Geschichte nicht, um bei der Tragödie zu verweilen, sondern weil ich jeden Tag beobachte, wie Organisationen in Berge fliegen.

Nicht wörtliche Berge. In gewisser Weise schlimmer — unsichtbare. Technische Schulden, vor denen erfahrene Entwickler seit Jahren warnen. Architekturentscheidungen, die von Beratern aufgezwungen wurden, die gegangen sind, bevor die Konsequenzen eintrafen. Roadmaps, diktiert von Menschen, die nie Software ausgeliefert haben, die Teams zwingen zu bauen, was in der Zeit, die nicht existiert, nicht gebaut werden kann.

Die Crew von Flug 965 war nicht dumm. Sie war nicht nachlässig. Es waren hochqualifizierte Fachleute, die teure Ausrüstung gemäß dokumentierter Verfahren bedienten. Sie folgten dem Plan.

Und der Plan flog sie in einen Berg.

Die Verführung des Plans

Pläne sind verführerisch. Sie bieten Gewissheit in einer unsicheren Welt. Sie ermöglichen es uns, Stakeholdern zu sagen, wann wir fertig sein werden. Sie erzeugen die Illusion, dass wir verstehen, was wir bauen, wie lange es dauern wird und was die Zukunft bringt.

Aber Pläne sind nicht die Realität. Sie sind unsere beste Vermutung über die Realität zu einem bestimmten Zeitpunkt — normalerweise dem Zeitpunkt, als wir am wenigsten über das wussten, was wir versuchten.

Die Crew von Flug 965 hatte einen Plan. Er war bei der Flugsicherung hinterlegt. Er war in den Computer programmiert. Er berücksichtigte Treibstoff, Zeit, Wegpunkte und Höhenbeschränkungen. Es war ein guter Plan.

Er berücksichtigte nur nicht einen einzigen falschen Tastendruck.

Der Berg interessiert sich nicht für Ihren Plan

Hier ist die unbequeme Wahrheit, die jeder Vorstand, jeder Programmmanager, jeder Gantt-Diagramm-Enthusiast verstehen muss:

Die Realität verhandelt nicht.

Der Berg interessierte sich nicht dafür, dass die Crew einen Plan hatte. Der Berg interessierte sich nicht dafür, dass der Computer ihnen zeigte, sie seien auf Kurs. Der Berg interessierte sich nicht für die dreizehntausend Flugstunden des Kapitäns oder die Sicherheitsbilanz der Fluggesellschaft oder die Weihnachtspläne der Passagiere.

Der Berg war einfach da. Und als sich der Pfad des Flugzeugs mit der Position des Berges kreuzte, gewann der Berg. Er gewinnt immer.

Technische Komplexität ist ein Berg. Architektonische Einschränkungen sind ein Berg. Die physikalischen Gesetze, die bestimmen, wie sich Software-Systeme unter Last verhalten — das sind Berge. Jedes Mal, wenn die Führung das Urteil der Entwickler mit einer Direktive von Beratern oder einem Mandat aus der Vorstandsetage überstimmt, programmiert sie einen neuen Kurs. Manchmal führt dieser Kurs in Terrain, das niemand aus der Vorstandsetage sehen kann.

Die Warnsysteme, die wir ignorieren

Das Bodenannäherungswarnsystem von Flug 965 gab der Crew eine Warnung. Sie war laut. Sie war unmissverständlich. Sie war absichtlich erschreckend.

Sie hatten sechs Sekunden. Es reichte nicht — teils weil die Bremsklappen ihre Steigrate stahlen, aber auch teils weil die Warnung zu spät kam. Die alte Warnsystemtechnologie konnte nicht vorausschauen; sie konnte nur den Boden erkennen, der von unten heranraste.

Ihre Organisation hat auch Warnsysteme. Erfahrene Entwickler, die sagen „diese Architektur skaliert nicht”. Der Teamleiter, der warnt, dass der Zeitplan eine Fantasie ist. Ingenieure, die — wieder einmal — erklären, warum der von der teuren Beratungsfirma vorgeschriebene Ansatz nicht funktionieren kann. Erfahrene Stimmen, abgetan als „änderungsresistent” oder „keine Teamplayer”, weil sie sich weigern so zu tun, als wäre der Berg nicht da.

Das sind Ihre Terrain-Warnungen. Sie schreien Sie gerade an.

Hören Sie zu? Oder folgen Sie dem Plan, den jemand außerhalb Ihres Cockpits für Sie programmiert hat?

Nach dem Absturz

Die Untersuchung von Flug 965 veränderte die Luftfahrt. Die Branche entwickelte Enhanced Ground Proximity Warning Systems — EGPWS —, die GPS und Terraindatenbanken nutzen, um Berge voraus zu sehen, nicht nur unten. Fluggesellschaften überarbeiteten ihre Verfahren zur Programmierung von Flugcomputern. Die Ausbildung betonte Situationsbewusstsein statt blindem Vertrauen in die Automatisierung.

Einhundertneunundfünfzig Menschen starben, und eine Branche lernte.

Aber nicht jede Organisation lernt aus Katastrophen. Manche reagieren, indem sie Lösungen von denselben Menschen kaufen, die ihnen das Problem verkauft haben.

Das Framework, das Lernen verbietet

Es gibt noch einen anderen Weg, wie Organisationen sich selbst in Berge fliegen: Sie kaufen Management-Frameworks, die versprechen, Entwickler zu „reparieren”. Sie vorhersehbar zu machen. Sie reibungslos durch einen Prozess fließen zu lassen wie Bauteile am Fließband. Die Verkaufspräsentation enthält immer das Wort „Lernen” — kontinuierliche Verbesserung, Feedback-Schleifen, Anpassung.

Aber dann kommt die Implementierung.

Das Framework wird von Menschen installiert, die nie produktiven Code geschrieben haben. Die Trainer gehen. Und was bleibt, ist ein System, das Lernen bestraft. Zurückgehen ist Versagen. Refactoring ist Verschwendung. Die Richtung zu ändern, nachdem man neue Informationen entdeckt hat, ist Abweichung vom Plan. Der gesamte Apparat ist um die Illusion herum konstruiert, dass Arbeit vorwärts fließt und nie zurückkehrt — dass man am Anfang alles wissen und dann einfach ausführen kann.

Das widerspricht allem, was wir über Software-Entwicklung wissen. Test-Driven Development funktioniert genau deshalb, weil man zurückgeht. Man schreibt einen fehlschlagenden Test, man bringt ihn zum Bestehen, man überarbeitet. Rot, grün, refaktorisieren. Der Zyklus ist das Lernen. Jede Iteration lehrt etwas über das Problem, das man vorher nicht wissen konnte.

Aber das Framework wurde mit dem Versprechen verkauft, dass die Führung endlich Sichtbarkeit und Kontrolle haben würde. Dass Entwickler zu vorhersehbaren Ressourcen werden würden. Dass Schätzungen zu Zusagen und Zusagen zu Lieferterminen werden würden. Zurückgehen war nicht Teil der Verkaufspräsentation.

Also wenn Entwickler versuchen zu refaktorisieren — versuchen zu lernen, versuchen zu verbessern — wird ihnen gesagt aufzuhören. Der Meilenstein ist fixiert. Der Zeitplan ist genehmigt. Die Ressourcen sind zugewiesen. Es gibt keine Zeit zum Lernen. Es gibt nur Zeit zum Ausführen. So zerstören Organisationen die intrinsische Motivation ihrer Entwickler — indem sie Denken als Fehler statt als Funktion behandeln.

Und das Flugzeug sinkt, selbstbewusst und kontrolliert, auf einen Berg zu, den die Dashboards des Frameworks nicht zeigen.

Wenn die Methode zum Meister wird

Es gibt eine subtilere Gefahr als in einen Berg zu fliegen. Manchmal schaffen Organisationen so starre Richtlinien, dass selbst wenn Piloten die Landebahn klar sehen können, es ihnen verboten ist zu landen.

Am 16. Oktober 2023 näherte sich Lufthansa-Flug LH458 — ein Airbus A350 aus München — dem San Francisco International Airport. Das Wetter war klar. Die Landebahn war sichtbar. Das Flugzeug funktionierte einwandfrei. Die Crew war erfahren und aufmerksam.

Aber SFO betrieb an diesem Abend nur Sichtanflüge. Und Lufthansas Unternehmensrichtlinie, eingeführt nach dem erschreckenden Air Canada-Beinahe-Unglück von 2017, bei dem eine übermüdete Crew fast auf einem Rollweg voller Flugzeuge gelandet wäre, verbot ihren Piloten, Sichtanflüge bei Nacht anzunehmen. Die Richtlinie verlangte einen Instrumentenanflug — ILS oder satellitengestützt — unabhängig von den Bedingungen.

Das ILS war ausgeschaltet. Die Crew konnte die Landebahn sehen. Sie durften nicht auf ihr landen.

Also erklärten sie einen Treibstoffnotfall und wichen nach Oakland aus. Die Passagiere wurden mit Bussen zurück nach San Francisco gebracht. Niemand starb. Aber eine ganze Flugzeugladung Menschen verbrachte Stunden in einem Bus, weil die Unternehmensrichtlinie wichtiger geworden war als das Urteil der Piloten.

Das passiert, wenn Organisationen auf Versagen mit dem Entzug von Ermessensspielraum reagieren. Nachdem Air Canada 759 fast über tausend Menschen getötet hätte, weil sie bei einem Sichtanflug einen Rollweg mit einer Landebahn verwechselten, war Lufthansas Reaktion rational: Nächtliche Sichtanflüge komplett verbieten. Die Möglichkeit menschlichen Versagens eliminieren, indem man menschliches Urteilsvermögen eliminiert.

Aber Richtlinien können nicht jede Situation vorhersehen. Die Crew von LH458 war nicht übermüdet. Sie war nicht verwirrt. Sie konnten genau sehen, wohin sie mussten. Die Richtlinie, konzipiert um eine Art von Versagen zu verhindern, schuf eine andere Art von Absurdität.

In Software-Organisationen passiert das ständig. Ein Projekt scheitert, weil Entwickler autonome Entscheidungen getroffen haben, die die Führung nicht verstand. Die Reaktion? Entwicklerautonomie entziehen. Genehmigungsprozesse einführen. Freigaben verlangen. Vorschreiben, dass alle technischen Entscheidungen durch nicht-technische Manager fließen, die von Framework-Verkäufern trainiert wurden, genau den Menschen zu misstrauen, die die Software bauen.

Die Entwickler können die Landebahn sehen. Sie wissen, wie man landet. Aber sie dürfen nicht. Die Methode ist zum Meister geworden. Die Richtlinie existiert, um vor einem Versagen zu schützen, das nicht passiert, während sie neue Versagen schafft, die niemand vorhergesehen hat.

Und manchmal weicht das Unternehmen nicht nach Oakland aus. Manchmal geht der Treibstoff aus. Die eigene Organisation zurückzufordern bedeutet, den Menschen zu vertrauen, die das Flugzeug tatsächlich fliegen.

Die Entscheidung, die zählt

Jeden Tag stehen Führungskräfte vor einer Wahl: dem Plan folgen oder der Realität folgen.

Dem Plan zu folgen ist bequem. Es bedeutet, der Quartalsbericht sieht planbar aus. Es bedeutet, niemand muss erklären, warum sich die Roadmap geändert hat. Es bedeutet, das teure Management-Framework, das Sie gekauft haben, funktioniert wie beworben.

Der Realität zu folgen ist schwer. Es bedeutet, Unsicherheit zuzugeben. Es bedeutet, Stakeholdern die Wahrheit zu sagen. Es bedeutet, den Menschen zu vertrauen, die der Arbeit am nächsten sind, Ihnen zu sagen, was tatsächlich passiert — und ihnen zu glauben, wenn es Ihrem sorgfältig konstruierten Plan widerspricht.

Die Crew von Flug 965 folgte ihrem Plan. Sie vertrauten ihrem Computer. Sie sanken selbstbewusst durch die Dunkelheit, überzeugt davon, dass sie wussten, wo sie waren.

Sie lagen falsch. Und weil sie falsch lagen, sahen einhundertneunundfünfzig Menschen Weihnachten nie.

Wie viele Projekte müssen sterben, bevor Ihre Organisation lernt? Wie viele Millionen müssen abgeschrieben werden? Wie viele talentierte Entwickler müssen ausbrennen und gehen, deren Warnungen zu spät bestätigt werden? Wie viele Unternehmen müssen sterben — tatsächlich sterben, Türen geschlossen, alle weg — bevor die Führung versteht, dass die Menschen im Cockpit vielleicht mehr über das Fliegen wissen als die Menschen in der Vorstandsetage?

Ihr Berg wartet

Irgendwo in Ihrer Organisation erhebt gerade ein erfahrener Entwickler einen Einwand. Er sagt, der Zeitplan ist unmöglich. Er erklärt, warum die von oben vorgeschriebene Architektur die geplanten Funktionen nicht unterstützen kann. Er weist darauf hin, dass der von externen Beratern aufgezwungene Ansatz allem widerspricht, was er über den Bau von Software weiß, die tatsächlich funktioniert.

Er ist Ihre Terrain-Warnung. Er schreit Sie an.

Was werden Sie tun?

Werden Sie dem Plan folgen, der von oben herab gereicht wurde? Werden Sie auf Kurs bleiben, Ihre erfahrene Crew zwingen, einen Flugpfad auszuführen, von dem sie wissen, dass er falsch ist, ihre Warnungen als Negativität oder Widerstand gegen Veränderung abtun?

Oder werden Sie den Menschen vertrauen, die das Flugzeug tatsächlich fliegen — und sie den Berg sehen lassen, bevor er alle an Bord tötet?

Einhundertneunundfünfzig Menschen starben fünf Tage vor Weihnachten, weil trainierte Fachleute ihrem Plan mehr vertrauten als der Realität.

Der Berg ist immer noch da. Er ist immer da.

Die einzige Frage ist, ob Sie ihn rechtzeitig sehen werden.