Als Maxine am Dienstag der folgenden Woche zur Arbeit kommt, trifft sie auf einen strahlenden Kurt. »Ich habe den Job«, begrüßt er sie überschwänglich.
»Wirklich? Den Dev-Job?«, fragt Maxine.
»Ja, den Dev-Job!«, antwortet er, als könne er es selbst nicht ganz glauben. »Ohne Kirstens Unterstützung wäre das nicht möglich gewesen. Ich gehe zum Data-Hub-Team, und du kommst mit.«
»Das ist großartig!«, jubelt Maxine. »Wie hast du Randy dazu gebracht, meine Versetzung zu genehmigen?«
»Nun, er war nicht besonders glücklich darüber, dich zu verlieren. Er hat immer wieder betont, dass du das Beste bist, was hier seit Urzeiten passiert ist, aber … nun, ich habe da meine Möglichkeiten«, sagt Kurt mit einem verschmitzten Lächeln.
Maxine gibt ihm ein High Five.
Er schaut sich um und flüstert: »Viele Manager berichten von ungewöhnlichen Vorgängen. Anscheinend hatten die hohen Tiere der Tech-Abteilungen Anfang der Woche irgendwo außerhalb ein Treffen mit Steve, und angeblich hat man sich auf einen einmonatigen Feature-Freeze geeinigt. Es sieht so aus, als träten sie jetzt tatsächlich auf die Bremse, was neue Features angeht, um all die technischen Schulden zu begleichen, die sich über die Jahre angehäuft haben!«
»Wirklich?!« Maxine kann es kaum glauben.
»Ihnen ist klar, dass der ganze Mist, der zusammengeschustert wurde, jetzt gefixt werden muss«, fährt er fort. »Ops stoppt alle Arbeiten, die nicht mit dem Phoenix-Projekt zusammenhängen, um sich auf die technischen Schulden zu konzentrieren und die Automatisierung voranzutreiben. Auch Dev und QA werden aus den gleichen Gründen die Arbeit an Features einstellen.
Das ist unsere Chance, ins Rampenlicht zu treten. Und allen zu zeigen, wie großartiges Engineering aussieht«, freut sich Kurt laut.
Im Verlauf des Tages kommt eine E-Mail, in der Kurts neue Rolle beschrieben wird. Maxine will Kurts Gefühle nicht verletzen, aber sie ist sich ziemlich sicher, dass er den Job letztlich nur bekommen hat, weil ihn ansonsten absolut niemand aus der Entwicklungsabteilung haben wollte. Das Data-Hub-Team wird weithin als die eigentliche Ursache der katastrophalen Abstürze rund um den Phoenix-Launch betrachtet. Chris hat das Team sogar während eines der Treffen, an denen Maxine teilgenommen hat, namentlich an den Pranger gestellt, was sie für ziemlich unfair hielt.
Dem Data-Hub-Team die Schuld für den krassen Fehlschlag zu geben, als den man das Phoenix-Deployment bezeichnen kann, ist in etwa so, als würde man einem Passagier im Heck eines Flugzeugs die Schuld für einen fatalen Crash geben, weil er seinen Sicherheitsgurt nicht fest genug angelegt hatte.
Sie weiß genau, warum es so leicht ist, das Data-Hub-Team zu beschuldigen. Es beschäftigt sich mit einem der am wenigsten glamourösen Technologiebereiche im Unternehmen. Der Data Hub ist Teil eines großen, langweiligen Message-Bus-Systems, das Maxine aber bereits sehr schätzt, weil darüber die meisten der wichtigsten Anwendungen und Aufzeichnungssysteme miteinander kommunizieren: die Produktdatenbank, die Preisdatenbank, die Bestandsverwaltungssysteme, die Systeme zur Auftragsabwicklung und -planung, das Rechnungswesen und fast 100 andere wichtige Anwendungen, von denen viele schon Jahrzehnte alt sind.
Maxine ist nicht davon begeistert, dass es tatsächlich drei Bestandsverwaltungssysteme gibt – zwei für die physischen Ladengeschäfte (eines wurde bei einer Akquisition »geerbt« und nie stillgelegt) und ein weiteres für den E-Commerce-Kanal. Und mindestens sechs Auftragserfassungssysteme – drei zur Unterstützung der Filialen, eines im E-Commerce, ein weiteres für OEM-Kunden und noch eines für den Verkauf über Tankstellen und Servicestationen.
Maxine liebt zwar byzantinische Prozesse (so wie Kinderärzte kranke Kinder lieben), aber selbst sie ist erstaunt darüber, mit wie vielen Systemen der Data Hub kommunizieren muss.
Je mehr Maxine sich mit der Arbeit des Data Hub beschäftigt, desto verblüffter ist sie. Der Hub wirkt einfach nicht so, als wäre er ein Teil von Phoenix. Schließlich wurde der Großteil des Data-Hub-Systems vor über 20 Jahren geschrieben, also lange bevor Phoenix auch nur als Konzept existierte.
Offenbar war der Hub früher eine Sammlung kleinerer Anwendungen, die über das gesamte Unternehmen verstreut waren. Einige davon liefen gemeinsam mit den ERP-Systemen im Finanzwesen, weitere im Fertigungsbereich und wieder andere in der Entwicklungsabteilung unter Chris’ Obhut.
Als der Phoenix-Juggernaut ins Rollen kam, wurden unglaublich viele neue Anforderungen an diese Teams gestellt, ohne dass ausreichend personelle Ressourcen vorhanden waren. Unmengen an neuen Phoenix-Features wurden Monat um Monat verzögert, da der alltägliche Geschäftsbetrieb den Data Hub durch konkurrierende Anforderungen blockierte.
Schließlich wurden alle diese Komponenten im Rahmen einer Neuorganisation in einer Gruppe zusammengeführt, die ebenfalls einfach »Data Hub« genannt und dem Phoenix-Projekt zugeordnet wurde, wobei die Phoenix-Notwendigkeiten immer Vorrang haben sollten. Und jetzt geben alle Data Hub die Schuld für alles, was schiefgelaufen ist.
Am Mittwochmorgen treffen sich Maxine, Nörgel-Dave und Kurt zum ersten Mal mit den Engineers von Data Hub. Maxine ist überrascht, dass auch Dave so schnell zum Data Hub versetzt wurde. Sie fragt ihn, wie er das hinbekommen hat.
Nörgel-Dave lächelt lediglich und sagt: »Einer der vielen Vorteile meiner überzeugenden Persönlichkeit – kein Manager lässt die Gelegenheit aus, mich zu einem anderen Team abzuschieben. Dadurch komme ich praktisch immer dort hin, wo ich auch selbst hinwill.«
Jetzt steht sie neben Dave, während sich die anderen fünf Ingenieure von Data Hub im zentralen Besprechungsbereich versammeln.
Sie sind alle entweder in einem ähnlichen Alter wie sie selbst oder kommen frisch vom College, niemand liegt altersmäßig dazwischen. Sie vermutet, dass die älteren Entwickler seit Gründung des Teams dabei sind, während sich die jüngeren Ingenieure schnell auf interessantere Positionen verabschieden und durch neue Hochschulabsolventen ersetzt werden.
Chris räuspert sich und wendet sich der Gruppe zu. »Guten Morgen allerseits. Bitte heißen Sie Kurt Reznick willkommen, der die Nachfolge von Peter antritt.«
Kurt scheint von der äußerst knappen Einführung überrascht zu sein, sagt aber fröhlich: »Hallo zusammen. Wie Sie vielleicht wissen, ist dies das erste Dev-Team, das ich leiten werde. Ich glaube, meine Aufgabe lässt sich ganz einfach beschreiben: zuzuhören, Ihnen alles zu geben, was Sie brauchen, damit Sie erfolgreich arbeiten können, und alle Hindernisse zu beseitigen, die Ihnen im Weg stehen.« Die unbeeindruckten Blicke zeigen, dass sich jeder Kurts Mangel an Erfahrung bewusst ist.
Kurt fährt fort: »Ich habe mit unseren zahlreichen internen Kunden gesprochen, und sie haben mir erzählt, wie wichtig der Daten Hub ist. Sie haben mir aber auch erzählt, dass wir oft den Engpass für notwendige Veränderungen im gesamten Unternehmen und auch im Phoenix-Projekt darstellen. Und wie wir alle wissen, fällt Phoenix ebenfalls aus, sobald unser Dienst ausfällt. Ich habe für Ende der Woche ein Brainstorming anberaumt, um Ideen dazu zu sammeln, wie wir unseren Service zuverlässiger und belastbarer gestalten können.«
»Data Hub und Peter dafür verantwortlich zu machen, wenn Phoenix versagt, ist Schwachsinn«, bemerkt einer der leitenden Entwickler.
»Ich stimme Ihnen völlig zu, Tom«, sagt Kurt. »Und seien Sie versichert, dass ich daran arbeiten werde, diese Wahrnehmung zu korrigieren.«
Kurt fährt fort: »Ich weiß es wirklich zu schätzen, dass Peter sich mit mir treffen wollte, bevor ich hier heute anfange. Er hat mir erzählt, dass er seit Jahren um zusätzliche Entwicklerplanstellen kämpft, weil die geschäftlichen Anforderungen, insbesondere im Zusammenhang mit der Integration von Phoenix, ständig gewachsen sind. Er empfahl mir, es weiter zu versuchen.«
Kurt gestikuliert in Richtung Chris. »Und ich verspreche Ihnen, dass ich mich weiterhin bei Chris für mehr Personal einsetzen werde.«
»Und ich werde weiter bei Steve darum werben«, antwortet Chris mit zusammengekniffenen Lippen. Kurt grinst. »In der Zwischenzeit habe ich zwei erfahrene Entwickler mitgebracht, die sich freiwillig für unser Team gemeldet haben. Maxine ist Lead Developer des MRP-Teams, und Dave ist Senior Developer im Backend-Server-Team von Phoenix. Sie sind zwei der Entwickler, denen ich am meisten vertraue.«
Die Data-Hub-Entwickler schauen sie überrascht an, aber auch deutlich glücklich, dass sie und Dave hier sind.
»Es wird in Kürze eine Anweisung von Chris hinsichtlich eines Feature-Freeze kommen, sodass wir problematische Bereiche unseres Codes überarbeiten und die Fehler, unter denen letztlich unsere Kunden leiden, fixen können«, sagt Kurt. »Aber warten Sie nicht auf die offizielle Mitteilung. Am wichtigsten ist es jetzt, die Dinge zu fixen, die Ihrer Meinung nach dringend gefixt werden sollten, und Priorität hat, was Ihrer Meinung nach dazu beiträgt, dass Sie selbst produktiver arbeiten können oder dass der Data Hub stabiler läuft. Ich kümmere mich um alle Beschwerden, die uns deswegen erreichen sollten.«
Maxine grinst, als sie die widerwillige Zustimmung in den Gesichtern der Data-Hub-Engineers sieht.
Als Neulinge integrieren sich Dave und Maxine in die täglichen Rituale des Data-Hub-Teams. Sie nehmen an den täglichen Teamtreffen teil und erklären sich schnell bereit, wenn es darum geht, irgendwo freiwillig auszuhelfen.
Maxine tut sich mit Tom zusammen, dem älteren Entwickler, der sich zu der Ungerechtigkeit geäußert hatte, für den Fehlschlag von Phoenix zum Sündenbock gemacht zu werden. Tom ist Ende 40 und trägt Brille, Jeans und T-Shirt. Sie sitzt mit aufgeklapptem Laptop an seinem Schreibtisch, während er ihr erklärt, woran er gerade arbeitet.
Währenddessen wird Maxine klar, dass der Data Hub ein über Jahrzehnte hinweg gewachsener Mischmasch verschiedener Technologien ist, darunter Java-Servlets, einige Python-Skripte und etwas, das sie für Delphi hält. Es gibt sogar einen PHP-Webserver.
Sie verurteilt keine dieser Technologien und lehnt sie auch nicht ab – schließlich leistet das Konglomerat seit Jahrzehnten erfolgreich seinen Dienst. Das Ganze ist vielleicht nicht das eleganteste Stück Software, aber Dinge, die seit 20 Jahren produktiv eingesetzt werden, sind selten elegant. Software kann man mit einer sich ständig wandelnden Stadt vergleichen, in der immer wieder ganze Viertel modernisiert werden müssen. Sie muss allerdings zugeben, dass der Data Hub nicht gerade als die hippeste Nachbarschaft angesehen werden kann. Neue Hochschulabsolventen zu rekrutieren, die die heißesten und gefragtesten Sprachen und Frameworks lernen und anwenden wollen, fällt in diesem Bereich zweifellos schwer.
Aber zumindest ist der Data Hub in einem viel besseren Zustand als die Phoenix-Build-Systeme, die wie unbewohnbare, radioaktiv verseuchte Katastrophengebiete oder ausgebrannte Ruinen eines Kriegsgebiets wirken.
Maxine sitzt an Toms Schreibtisch, während er erklärt, woran er gerade arbeitet: »Hier habe ich ein dringendes Problem. Data Hub erzeugt gelegentlich falsche Nachrichtentransaktionen und stürzt unter hoher Last ab. Das passiert manchmal, wenn Mitarbeiter in den Filialen in der Werkstattanwendung Reparaturarbeiten für einen Kunden als abgeschlossen markieren«, sagt er. Verlegen fährt er fort: »Da stecken einige Tage Arbeit drin. Ich habe endlich einen halbwegs reproduzierbaren Testfall geschaffen – der Fehler passiert etwa in einem von zehn Fällen. Ich bin mir ziemlich sicher, dass es an einer Race Condition liegt.«
Da wir ja bereits darüber gesprochen haben, ins kalte Wasser geworfen zu werden, denkt Maxine. Aber sie genießt die Herausforderung und ist sich sicher, dass es, wenn sie das Problem lösen, einen sehr positiven Einfluss auf das gesamte Team haben wird. Schließlich gehören Wettlaufsituationen zu den härtesten Problemkategorien in verteilten Systemen und der Softwareentwicklung insgesamt. Wenn das Python-Problem der Mädchen in der Mittelschule einem Karate-Gegner mit gelbem Gürtel entspricht, kann das, was Tom beschreibt, selbst die erfahrensten Träger eines schwarzen Gürtels der zehnten Stufe zur Verzweiflung und in den Wahnsinn treiben.
Maxine ist beeindruckt, dass Tom das Problem überhaupt reproduzieren kann. Jemand nannte diese Art von Problem einmal »Heisenbug« und bezog sich dabei auf die Phänomene der Quantenphysik, bei denen der Akt der Beobachtung die Natur der Realität selbst verändert, gemäß der Heisenberg’schen Unschärferelation.
Diese Art von Arbeit unterscheidet sich deutlich von der Darstellung des Programmierens in Filmen, in denen oft ein junger, männlicher Programmierer wütend in die Tasten haut, natürlich im Kapuzenpulli, aber seltsamerweise auch mit Sonnenbrille (was sie im wirklichen Leben noch bei keinem Entwickler gesehen hat). Typischerweise hat der Junghacker viele verschiedene offene Fenster vor sich, in denen rasend schnell Text vorbeiscrollt. Eine ganze Schar von Menschen schaut ihm besorgt über die Schulter. Nach ein paar Sekunden schreit der Coder »Ich hab’s!« – und alle jubeln. Die Lösung ist gefunden, das Feature fertig, die Welt gerettet. Und Klappe.
Die Wirklichkeit sieht anders aus: Entwickler starren normalerweise tief konzentriert auf den Bildschirm und versuchen zu verstehen, was der Code macht, damit sie ihn sicher und mit chirurgischer Präzision ändern können, ohne etwas anderes durch einen unbeabsichtigten Nebeneffekt zu (zer)stören, besonders wenn sie an unternehmenskritischen Abschnitten arbeiten.
Tom führt sie Schritt für Schritt durch das Problem. »Wenn mehrere Reparaturvorgänge gleichzeitig verarbeitet werden, kann es vorkommen, dass einem der Vorgänge die falsche Kunden-ID zugeordnet wird und der Data Hub komplett abstürzt«, erklärt er. »Ich habe versucht, das Kundenobjekt phasenweise zu sperren, aber das verlangsamt die gesamte Anwendung so stark, dass es als Möglichkeit ausscheidet. Wir haben schon genug Leistungsprobleme.«
Maxine nickt, weil Tom ihre seit Langem vertretene Meinung bestätigt, dass Multithreading-Fehler so komplex sind, dass sie die menschliche Logik nahezu überfordern, zumal die meisten gängigen Programmiersprachen wie Java, C# und JavaScript die Veränderung von geteilten Zuständen fördern.
Es ist fast unmöglich, vorherzusagen, wie sich ein Programm verhalten wird, wenn ein anderer Teil des Programms jederzeit Daten ändern kann, auf die man angewiesen ist, denkt sich Maxine. Aber sie ist sich ziemlich sicher, dass sie weiß, wie dieses Problem gelöst werden kann.
»Können wir den Codepfad noch einmal durchgehen?«, fragt Maxine. Dabei geht sie eine geistige Checkliste durch, um ihre Hypothese zu überprüfen. Es gibt einen Threadpool, der eingehende Nachrichten bearbeitet. Check. Service Records können von mehreren konkurrierenden Threads bearbeitet werden. Check. Die Threads tauschen Objekte aus, die beim Aufruf ihrer Methoden mutiert werden. Check.
Hypothese bestätigt. Das Problem liegt fast sicher in der Zustandsveränderung, denkt sie. Genau wie in der Mittelschule.
»Du hast recht, es ist definitiv eine Race Condition«, sagt Maxine. »Und ich bin ziemlich sicher, dass wir dieses Problem lösen können, ohne das gesamte Kundenobjekt sperren zu müssen. Kann ich dir zeigen, was ich mir vorstelle?«
Als er nickt, schlägt sie – genau wie bei den Mädchen der Mittelstufe – vor, den Codepfad mithilfe von funktionalen Programmierprinzipien neu zu schreiben. In Toms Testfall gibt es eine Menge Mocks und Stubs, um die Produktivumgebung zu simulieren: einen Konfigurationsserver, eine Datenbank, einen Nachrichtenbus, eine Factory für Kundenobjekte …
Sie entfernt all das, weil es nicht diese Bereiche des Systems sind, die sie testen will. Stattdessen schiebt sie die Input-/Output-Vorgänge und Nebeneffekte an den Rand und erstellt Unittests, um zu prüfen, wie ein eingehender Reparaturauftrag verarbeitet wird, wie Kundendaten transformiert und welche Nachrichten zurückgesendet werden.
Sie lässt jeden Thread eine eigene Kopie des Kundenobjekts erstellen. Sie schreibt alle Objektmethoden in eine Reihe reiner Funktionen um – Funktionen, deren Ausgabe ausschließlich vom Input abhängig ist, ohne Nebeneffekte, Mutationen oder Zugriffe auf den globalen Zustand.
Als Maxine Tom einen Unittest präsentiert, der das Problem zu 100 Prozent reproduziert, sowie die vollkommen threadsichere Korrektur, die immer funktioniert, starrt Tom sie mit großen Augen an. »Das ist … das ist unglaublich.«
Sie weiß, warum er beeindruckt ist. Ihr Code ist so einfach, dass man ihn leicht verstehen und auf seine Richtigkeit prüfen kann. Während Tom staunend auf den Bildschirm schaut, sagt er schließlich: »Ich kann kaum glauben, wie sehr du den Code vereinfachst hast. Wie kann man damit dasselbe erreichen wie mit dem komplexen Durcheinander, das wir vorher hatten?« Den Rest des Nachmittags stellt er Fragen und versucht offensichtlich, sich selbst zu beweisen, dass Maxines Testfall das Problem erfasst hat und die Neufassung korrekt funktioniert. Endlich sagt er: »Ich kann es kaum glauben, aber du hast wirklich recht. Es funktioniert tatsächlich!«
Maxine grinst über Toms Reaktion. Ein weiterer Beweis dafür, dass funktionale Programmierprinzipien die besseren Denkwerkzeuge sind. Und der Code ist gegenüber dem Anfangszustand jetzt bereits deutlich verbessert – er ist definitiv sicherer, leichter zu testen und viel leichter zu verstehen. Das macht echt Spaß, findet sie. Und es ist ein großartiges Beispiel für das Erste Ideal von Lokalität und Einfachheit.
»Okay, lass uns die Lösung mergen«, sagt er, öffnet ein Terminalfenster und gibt einige Befehle ein. Er dreht sich zu Maxine. »Herzlichen Glückwunsch! Du hast gerade deinen ersten Fehler behoben und die erste Änderung eingecheckt!«
Maxine gibt ihm breit grinsend ein fettes High Five. Gleich am ersten Tag einen Fehler in einer Race Condition zu bezwingen, ist verdammt beeindruckend. »Fantastisch! Also, lass uns das Ding testen und in Production pushen.« Maxine ist begeistert von der Vorstellung, wie ihnen ein dankbarer Filialleiter ergriffen die Hand schüttelt.
»Äh … also«, bringt Tom mühsam heraus. »Die Tests beginnen erst am Montag.«
Maxine spürt, wie ihr das Herz in die Hose rutscht. »Wir können es nicht selbst testen?«
»Früher konnten wir das, bevor wir wieder ins Phoenix-Projekt integriert wurden«, antwortet er wehmütig. »QA hat das Testen übernommen. Und als es Probleme mit verschiedenen Teams gab, die die Testumgebung gleichzeitig nutzten, haben sie allen den Zugang gesperrt. Jetzt sind sie die Einzigen, die sich einloggen können – vom Testen ganz zu schweigen.«
»Warte mal«, sagt sie. »Wir schreiben die Tests, können sie aber nicht laufen lassen?«
Er lacht. »Nein, nein. QA schreibt die Tests. Sie lassen uns nicht einmal mehr die Testpläne sehen.«
Maxine atmet hörbar aus, da sie weiß, wohin das führt. »Und wir können es nicht in die Produktivumgebung pushen?«
Tom lacht wieder. »Nein, nicht mehr. Früher konnten wir das. Aber jetzt liegt die Bereitstellung bei jemand anderem. ›Kümmert euch um euren eigenen Kram‹, hieß es.« Er zuckt mit den Schultern. Maxine ist sich ziemlich sicher, dass sie weiß, wer »Kümmert euch um euren eigenen Kram« gesagt hat. Zum Beispiel Chris.
Die Freude, die Maxine bei der Arbeit an ihrem aktuellen Problem empfunden hat, ist verpufft. Schließlich sind Codekorrekturen, speziell von Features, nur ein Bruchteil der gesamten Arbeit. Die Aufgabe ist erst erfüllt, wenn ein Kunde das, was sie gefixt haben, auch anwenden kann. Und selbst dann ist die Arbeit noch nicht ganz abgeschlossen, denn es lässt sich immer noch etwas mehr darüber erfahren, wie man einem Kunden helfen kann, seine Ziele am besten zu erreichen.
»Mist«, murmelt sie. Ich bin wieder genau da, wo ich angefangen habe – weit weg vom Ersten Ideal. Immer noch kann ich nichts eigenständig bewegen, denkt Maxine. Erneut ist sie wieder von anderen abhängig, um Kundennutzen zu schaffen.
Blind gegenüber der traurigen Situation, öffnet Tom fröhlich ein neues Fenster. »Es ist gar nicht so schlimm. Wir müssen bloß ins Ticketing-System gehen und den Fehler als »erledigt« markieren. Dann weiß das QA-Team, dass es getestet werden muss, damit es in die Produktivumgebung geschoben werden kann.«
Tom schaut auf seine Uhr und dreht sich zu ihr um: »Das war großartig. Wir haben heute echt was erreicht. Sollen wir uns einen anderen Fehler herauspicken?« Maxine zwingt sich ein Lächeln ab und nickt. Das ist scheiße, denkt sie stattdessen. Sie mag es, Dinge, die sie angefangen hat, auch zu beenden.
Maxine arbeitet den ganzen Tag mit Tom weiter, immer am nächstdringenden Fehler, der behoben werden muss. Tom beglückwünscht Maxine noch einmal dazu, wie sie Probleme knackt. Er ist beeindruckt davon, wie sie Modultests schreibt, die ohne komplexe Integrationstestumgebung durchgeführt werden können. Aber es gibt Grenzen – Aufgabe des Data Hub ist es, Systeme miteinander zu verbinden. Man kann nicht alles auf einem einzigen Laptop simulieren. Es wäre reizvoll, die Architektur von Data Hub komplett zu überarbeiten, damit das doch möglich würde, denkt Maxine schwärmerisch.
Obwohl es ihr Spaß macht, Data Hub und die Bereiche des Unternehmens, die es verbindet, kennenzulernen, hat diese Arbeit doch auch etwas zutiefst Unbefriedigendes an sich.
Sie denkt an Eriks Zweites Ideal von Fokus, Flow und Freude. Die ganze Freude, die sie gefühlt hatte, verflüchtigte sich, als Tom ihr erklärte, dass sie nur einen kleinen Teil der für die vollständige Wertschöpfung erforderlichen Arbeit abschließen könnten. Das ist ihr einfach nicht genug. In ihrem MRP-Team konnte jeder Entwickler seinen eigenen Code testen und sogar selbst in Produktion bringen. Es musste nicht wochenlang auf andere gewartet werden, damit diese die Arbeit für sie erledigen. Die Möglichkeit, Code zu testen und in die Produktivumgebung zu pushen, macht die Entwicklung produktiver, sorgt für zufriedenere Kunden, schafft Verantwortlichkeit für die Codequalität bei den Personen, die ihn schreiben, und gestaltet die Arbeit als solche freudvoller und befriedigender.
Maxine beginnt, darüber nachzudenken, wie einige der von der Rebellion entwickelten Tools eingeführt werden könnten. Wir müssen zumindest standardisierte Entwicklungsumgebungen zur Verfügung stellen, damit man auf seinem Laptop Builds machen kann, meint sie. Ein weiteres Thema für das nächste Dockside-Meeting.
Währenddessen macht sie weiter und unterstützt Tom bei seiner Arbeit. Gemeinsam beheben sie zwei weitere Fehler und nehmen dann ein neues Feature in Angriff, das allerhöchste Priorität hat. Dabei geht es darum, Geschäftsregeln für Garantieerweiterungen zu erstellen, was offenbar so wichtig ist, dass der Feature-Freeze hier nicht gilt.
»Warum hat das so hohe Priorität?«, fragt Maxine Tom, während sie das Ticket liest. »Das generiert hohe Umsätze«, erklärt Tom. »Garantieerweiterungen gehören zu den Produkten mit den höchsten Gewinnspannen. Die Kunden haben das Pilotprogramm extrem gut angenommen, insbesondere für Produkte wie Reifen. Jetzt brauchen die Mitarbeiter in den Filialen eine Möglichkeit, die Garantieinformationen abzurufen, damit sie Reparaturarbeiten durchführen und die Ansprüche der Kunden bei der Versicherungsgesellschaft geltend machen können.«
Tom fährt fort: »Großartig für den Kunden, großartig für uns, und ein Drittversicherer übernimmt das gesamte finanzielle Risiko.«
»Cool«, findet Maxine mit aufkeimendem Interesse. Das sind die Features, die umsetzen, was Steve im Townhall-Meeting als Devise ausgegeben hat. Es ist schon lange her, dass Maxine mit der Umsatzseite des Geschäfts zu tun hatte.
Sich selbst wieder auf ihren grenzenlosen Optimismus besinnend, beginnt sie mit Tom, das Feature zu durchdenken und herauszufinden, was alles erforderlich ist, um es zu realisieren. Sie versucht, nicht darüber nachzudenken, dass das Ergebnis einfach liegen bliebe, bis das QA-Team irgendwann Zeit hätte, es zu testen, selbst wenn sie das Feature heute fertig bekämen.
Am nächsten Morgen sitzen Tom und Maxine an einem Whiteboard und listen alle Systeme auf, die sie ändern müssen, um die Garantieerweiterungen umzusetzen. Zwei weitere Engineers sind hinzugekommen, da sich der Umfang der Aufgabe als immer größer herausstellt. Und dann wird ihnen klar, dass sie sich auch mit Entwicklern aus zwei weiteren Teams abstimmen müssen. Maxine schätzt, dass sie insgesamt sechs weitere Gruppen hinzuziehen müssen, weil so viele unterschiedliche Teilsysteme betroffen sind.
Maxine ist bestürzt, dass die Anzahl der Teams, die einbezogen werden müssen, ständig wächst. Dies widerspricht völlig dem Ersten Ideal von Lokalität und Einfachheit. Im aktuellen Fall sind die vorzunehmenden Änderungen nicht allein lokal umsetzbar, sondern müssen von vielen unterschiedlichen Gruppen vorgenommen werden. Das entspricht ganz und gar nicht dem berühmten Amazon-Ideal des »Zwei-Pizza-Teams«, bei dem Features von Teams erstellt werden sollen, die von maximal zwei Pizzas satt werden.
Wir brauchen eine ganze Wagenladung Pizzas, um dieses Feature umzusetzen, schätzt Maxine und sieht zu, wie Tom weitere Kästchen auf die Tafel zeichnet.
Kurt steckt kurz seinen Kopf in den Konferenzraum. »Hey, sorry für die Unterbrechung. Jemand von Ops und der Manager, der für die Anwendung fürs Channel-Training-Management zuständig ist, sind gerade in einer Konferenzschaltung. Alle Kunden-Log-ins schlagen fehl. Sie behaupten, dass der Konnektor nicht mehr funktioniert?«
»Nicht schon wieder«, stöhnt Tom. »Die Authentifizierung arbeitet schon seit dem Phoenix-Launch unzuverlässig. Wir sind dran …«
»Verstanden«, sagt Kurt und tippt etwas in sein Telefon. »Ich habe gerade einen Chatkanal für uns eingerichtet, okay?«
Maxine folgt Tom zurück an seinen Schreibtisch. Als er ein weiteres Browserfenster öffnet und etwas eingibt, wird ein Anmeldefehler auf seinem Bildschirm angezeigt. »Okay, irgendwas funktioniert definitiv nicht richtig. Mal sehen, ob wir den Grund dafür isolieren können …«, murmelt Tom. »Ich bezweifle, dass es sich tatsächlich um einen Data-Hub-Konnektor handelt. Wahrscheinlich ist es eher der Authentifizierungsdienst für Unternehmenskunden oder ein Problem im Netzwerk.«
Maxine nickt und macht sich Notizen, während mehr vom Data-Hub-Universum sichtbar wird. Skeptisch schlägt sie vor: »Können wir Netzwerk und Authentifizierung nicht sofort ausschließen? Wenn eines von beiden die Ursache wäre, könnten wir nicht einmal die Website erreichen, und bei fehlender Authentifizierung würden alle Dienste ausfallen.«
»Gutes Argument«, stimmt Tom zu. »Es könnte dennoch definitiv ein Netzwerkfehler sein – wir hatten in letzter Zeit eine Reihe von Problemen. Gerade letzte Woche blockierten die Netzwerkleute versehentlich einige interne IP-Adressen, was uns echte Probleme beschert hat.«
»Netzwerk. Es sind immer die Netzwerkleute, oder?«, konstatiert sie lächelnd. »Aber wenn es immer die Netzwerkleute sind, warum rufen sie dann uns an?«, fragt Maxine.
»Tja, die Benutzer merken nur, dass sie keine Verbindung zum Data Hub bekommen«, antwortet Tom. »Wir erklären ihnen dann immer, dass es nicht an uns liegt, sondern an dem Ziel, mit dem wir uns verbinden müssen. Aber das interessiert niemanden.«
Als Maxine sieht, wie Tom das Ops-Ticketing-System aufruft und ein neues Ticket erstellt, fragt sie: »Wozu ist das gut?«
»Wir brauchen die Protokolldateien für den Data Hub und die Konnektoren, um zu sehen, ob darüber noch Datenverkehr läuft oder ob nicht«, antwortet er und füllt die zahlreichen Felder aus.
»Wir können nicht direkt auf die Protokolldateien zugreifen?«, fragt Maxine und fürchtet sich ein bisschen vor der Antwort.
»Nein. Die Leute von Ops lassen uns nicht«, antwortet er und gibt weiter Daten ins Formular ein.
»Jemand muss also auf das Ticket antworten und die Protokolle für uns vom Server kopieren?«, fragt sie ungläubig.
»Ja«, erwidert er und fährt mit dem Tippen fort, offensichtlich sehr geübt beim Ausfüllen. Er springt zwischen den Eingabefeldern hin und her, tippt, fährt mit der Maus zu einem Drop-down-Feld und klickt schließlich auf Senden, nur um festzustellen, dass noch ein weiteres Pflichtfeld ausgefüllt werden muss.
Maxine stöhnt. Die Data-Hub-Anwendung, an der sie arbeiten, könnte genauso gut im Weltraum oder tief in einem Bergwerk laufen. Sie können nicht direkt darauf zugreifen, sie können nicht sehen, was dort passiert, und um möglicherweise zu verstehen, was tatsächlich vor sich geht, müssen sie mit jemandem aus Ops über das Ticketing-System kommunizieren.
Sie fragt sich, ob das Ticket bei ihrem Helpdesk-Freund Derek landet.
Tom gelingt es schließlich, das Ticket abzuschicken. Zufrieden sagt er: »Jetzt warten wir.«
»Wie lange dauert es normalerweise?«, fragt Maxine.
»Bei einem Sev-2-Vorfall? Ist nicht allzu dramatisch – es dauert wahrscheinlich nicht länger als eine halbe Stunde. Wenn es nicht direkt mit einem Ausfall zusammenhängt, könnte es auch ein paar Tage dauern«, sagt Tom. Er schaut auf die Uhr. »Was sollen wir in der Zwischenzeit machen?«
Selbst beim Data-Hub-Team kann sie dem »Waiting Place« nicht entkommen.
Vier Stunden später, nach Durchsicht der Logdateien, sind sie sich sicher, dass das Problem nicht am Data Hub liegt. Zwei Stunden danach haben sie endlich auch alle anderen davon überzeugt. Wie Tom vermutet hatte, lag es an einer internen Netzwerkänderung.
Es folgt eine weitere Runde intensiver Schuldzuweisungen zwischen Ops und dem Marketing sowie innerhalb der technischen Abteilungen. Schließlich mischt sich auch noch Sarah ein und fordert ernste Konsequenzen.
»Oh, oh«, sagt Tom, der mit Maxine vom hinteren Ende des Tischs zuschaut. »Das wird nicht gut ausgehen.«
Von: Wes Davis (Director, Distributed Operations)
An: Alle IT-Mitarbeiterinnen und -Mitarbeiter
Datum: 25. September, 19:50
Betreff: Personelle Veränderungen
Mit sofortiger Wirkung verlässt Chad Stone aus dem Bereich Netzwerktechnik unser Unternehmen. Bitte richten Sie alle E-Mails an seine Managerin Irene Cooper oder an mich.
Bei allem, was mir heilig ist, bitte machen Sie keine weiteren Fehler, damit ich nicht noch mehr dieser unangenehmen E-Mails schreiben muss. (Und falls ich selbst gefeuert werde, richten Sie Ihre E-Mails bitte an Bill Palmer, VP of IT Operations.)
Danke, Wes
Schließlich geht der Tag zu Ende, und ein weiteres Treffen in der Dockside Bar steht bevor. Die Rebellen haben das gesamte Data-Hub-Team eingeladen, sich ihnen anzuschließen. Maxine ist damit einverstanden, lieber zu viele Personen mit einzubeziehen, anstatt aus Versehen einige wichtige Kolleginnen und Kollegen außen vor zu lassen. Tom und drei weitere Engineers tauchen auf. Maxine ist froh, dass sie gekommen sind. Nach den letzten paar Tagen ist sie begierig auf ein Brainstorming zu der Frage, wie man die Produktivität der Entwickler im Data-Hub-Team deutlich verbessern könnte.
Maxine beobachtet, wie viel Spaß sie haben und dass sie eine Gemeinschaft von Menschen sind, die gern Zeit miteinander verbringt. Kurt steht auf und wendet sich an die Gruppe.
»Herzlich willkommen, neue Mitglieder des Widerstands! Ich möchte euch alle kurz vorstellen«, sagt Kurt. Er geht die Runde durch, wie er es auch bei Maxine und Kirsten getan hat. »Nachdem ihr jetzt etwas über einige der subversiven Dinge gehört habt, an denen wir arbeiten, damit die Engineers bei Parts Unlimited wieder mit Freude bei der Sache sein können, wie wäre es, wenn ihr uns mitteilt, was euch das Leben erleichtern würde?«
Zwei Kollegen von Tom machen den Anfang und stellen sich und ihre beruflichen Hintergründe vor. Einer gehört wie Tom seit fast einem Jahrzehnt zum Data-Hub-Team, aber ihm fällt nichts ein, worüber er sich beschweren könnte: »Meine Arbeitswelt ist völlig in Ordnung, und ich bedanke mich für die Einladung zu diesem kleinen Umtrunk.«
Da er offensichtlich nichts mehr hinzuzufügen hat, schließt sich Tom an. »Wie mein Kollege bin ich schon lange im Data-Hub-Team. Damals hieß es noch Octopus – weil es mit genau acht Anwendungen verbunden war. Jetzt sind es über 100.
Ich hatte heute ein tolles gemeinsames Programmiererlebnis mit Maxine, und ich kann immer noch nicht glauben, dass wir wirklich einen Race-Condition-Bug gefixt haben! Ich finde Maxines Idee super, Data-Hub-Entwicklungsumgebungen aufzusetzen, die wir alle nutzen können«, fährt er fort. »Ich bin nicht stolz darauf, aber ich muss leider zugeben, dass es Zeiten gab, in denen wir neue Entwickler eingestellt haben, die selbst sechs Monate später immer noch keinen vollständigen Build auf ihren Maschinen durchführen konnten«, sagt er und schüttelt den Kopf. »Das war nicht immer so. Als ich anfing, war es einfacher. Aber im Laufe der Jahre haben wir einige Dinge hartcodiert, bei denen wir das nicht hätten tun sollen, ein paar andere hier und dort aktualisiert und das Ganze nie richtig dokumentiert … und jetzt? Ein ziemliches Chaos.«
Er schaut hoch und grinst seine Teamkollegen am Tisch an: »Kennt ihr den alten Entwicklerwitz ›Auf meinem Laptop hat es funktioniert!‹? Nun, bei uns im Data Hub bringen wir es nicht einmal auf den Laptops zum Laufen.«
Alle lachen. Jeder Entwickler auf diesem Planeten kennt das Problem. Es passiert normalerweise zum ungünstigsten Zeitpunkt, dass beispielsweise etwas in der Produktion abstürzt, aber auf mysteriöse Weise auf dem Laptop des Entwicklers perfekt funktioniert. Maxine erinnert sich an unzählige Male, als sie mühsam herausfinden musste, worin genau der Unterschied zwischen dem Laptop eines Entwicklers und der Produktionsumgebung bestand.
»Meine Schmerzpunkte?« Tom grübelt. »Es sind unsere Umgebungen. Früher hatten wir das gut im Griff, aber dann wurden wir ins Phoenix-Projekt integriert und mussten Umgebungen benutzen, die von einem zentralen Team stammen, das sich ausschließlich um Environments kümmert.«
»Es ist verrückt. Im Vergleich zum Rest von Phoenix ist unsere Abteilung winzig. Aber um heutzutage den Data Hub zu betreiben, müssen wir Gigabytes an völlig irrelevanten Abhängigkeiten installieren«, fährt er fort. »Es dauert ewig, herauszufinden, wie man alles zum Laufen bringt, und es passiert leicht, dass etwas aus Versehen in Mitleidenschaft gezogen wird. Kein Witz: Ich sichere jeden Tag meinen Arbeitslaptop, weil ich Angst habe, dass plötzlich meine Builds nicht mehr funktionieren und ich Wochen damit verbringen muss, alles zu reparieren.«
Tom lacht: »Vor zehn Jahren verlor ich meine Emacs-Konfigurationsdatei und konnte keine aktuelle Sicherung finden. Und ich war einfach nicht in der Lage, sie von Grund auf wiederherzustellen. Ich habe schließlich aufgegeben und den Editor gewechselt.«
Alle lachen und geben dann ihre eigenen Geschichten von Qualen und Trauer über den Verlust von Lieblingstools zum Besten.
Tom wendet sich an Maxine. »Ich würde gern ein paar Tage damit verbringen, eine Dev-Umgebung aufzusetzen, die wir alle bei unserer täglichen Arbeit nutzen können. Wenn wir ein VM- oder Docker-Image hätten, könnte jedes Teammitglied jederzeit ein Build auf jedem beliebigen Rechner durchführen. Das wäre fantastisch.«
»Du und ich, wir werden auf jeden Fall fantastisch miteinander auskommen«, sagt Maxine lächelnd. »Wir brauchen Entwickler, die ihre ganze Energie auf die Entwicklung von Features konzentrieren können und nicht darauf, Builds zum Laufen zu bringen. An der Stelle bin ich absolut mit Leidenschaft dabei und würde mich über deine Unterstützung sehr freuen.«
»Das ist großartig«, findet Kurt. »Wir alle wissen, wie wichtig Environments sind. Von mir aus könnt ihr vorerst die Hälfte eurer Arbeitszeit dafür verwenden – ich werde das im Zeiterfassungssystem entsprechend verstecken.«
Später am Abend taucht Kirsten auf und gießt sich aus dem gemeinsamen Krug ein Bier ein. Lächelnd fragt sie: »Was habe ich verpasst?«
»Nichts als die Planung des unvermeidlichen Umsturzes der bestehenden Ordnung natürlich«, antwortet Kurt. Die neuen Mitglieder des Data-Hub-Teams starren Kirsten an, als sie Platz nimmt.
Kurt fragt: »Und, Kirsten, wie läuft das Projekt Umkehr? Der Feature-Freeze? Ich habe gehört, dass Bill Palmer Steve davon überzeugt hat, die Arbeit an allen Features auf Eis zu legen, damit jeder seine technischen Schulden begleichen kann.«
»Stimmt«, gibt sie zu. »Sarah Moulton geht vor Wut durch die Decke und beschwert sich, dass all die ›untätigen Entwickler‹ die bereits gemachten Zusagen des Unternehmens an Kunden und Wall Street gefährden. Ich kann immer noch nicht glauben, dass sie nicht versteht, dass das auch ihr hilft. Aber das Projekt Umkehr kommt definitiv: 30 Tage lang wird Ops mit ihrer Arbeit ausschließlich Phoenix unterstützen.«
»Diesmal machen sie ernst«, bestätigt Brent. »Bill war fantastisch. Er hat mir unmissverständlich gesagt, dass ich nur an Dingen arbeiten darf, die mit Phoenix zu tun haben. Er hat mich von den Pager-Bereitschaften für praktisch alles befreit. Hat mich von allen Mailinglisten entfernt, mich aus jedem Chatraum geschmissen und mich angewiesen, keine Anrufe mehr anzunehmen. Und das Beste daran ist, dass ich mich absolut nicht an der Behebung akuter Ausfälle beteiligen darf. Wenn ich das tue, würde er mich feuern.«
Als Maxine das hört, ist sie schockiert. Bill würde Brent feuern? Wenn man sich all die Leute in Erinnerung ruft, die in letzter Zeit gefeuert wurden, versteht sie nicht, warum Brent dabei grinst.
»Es ist fantastisch«, unterstreicht Brent ganz aufgewühlt. »Bill hat mir erklärt, dass er die Bereichsleiter weder rauswerfen noch ihnen vorschreiben kann, was sie tun sollen. Das Einzige, was er tun könne, sei, sicherzustellen, dass ich keine Zeit mit solchen Dingen verschwende. Er meinte, ich solle jedem, der versucht, mich zu erreichen, sagen, dass ich gefeuert werde, wenn ich sie zurückrufe.«
Brent lacht, offensichtlich beschwingt, trinkt sein Bier aus und schenkt sich ein neues ein. »Er hat Wes beauftragt, alle meine E-Mails und Telefonanrufe zu überprüfen und jeden deutlich zurechtzuweisen, der versucht, mich zu erreichen. Das Leben ist wirklich großartig! Im Ernst, es war nie besser.«
Maxine grinst. Sie hat in ihrer Laufbahn oft erlebt, wie Engineers zum Hindernis werden können. Es kann Spaß machen, sich immer im Auge des Orkans zu befinden, aber es ist sicher nicht nachhaltig. Auf diesem Weg warten irgendwann nur noch automatische Weckanrufe, Erschöpfung, Zynismus und Burn-out.
Kirsten lächelt ebenfalls. »Es funktioniert. Brents Name steht häufiger auf kritischen Aktionspunkten als der jeder anderen Person, und Bill hat allen mitgeteilt, dass es oberstes Ziel sein muss, Brent zeitlich zu entlasten.
Auf Entwicklungsseite verspricht Chris, dass 30 Tage lang alle Teams, die in irgendeiner Form mit dem Phoenix-Projekt zusammenhängen, nicht an neuen Features arbeiten dürfen«, fasst Kirsten zusammen und liest dann etwas von ihrem Handy ab: »›Alle Teams müssen Fehler oberster Priorität beheben, die Codebasis stabilisieren und alles tun, was nötig ist, um eine weitere Release-Katastrophe zu verhindern.‹«
Maxine hört aufgeregtes Gemurmel am Tisch. Sie weiß, dass solch eine Maßnahme genau jetzt unabdingbar ist – und dass dies eine fantastische Gelegenheit für die Rebellion sein könnte.
»Es gibt noch viele Meinungsverschiedenheiten auf der Hierarchieebene direkt unterhalb von Chris darüber, wie man den Freeze umsetzen soll und kann«, fährt Kirsten fort. »Aber sie haben so viel Zeit damit vertrödelt, sich Regeln auszudenken, woran man arbeiten darf und woran nicht, dass wir bereits eine Woche verloren haben; viele Teams arbeiten immer noch an Features – Business as usual. Wir brauchen in dieser Frage viel mehr Klarheit von der Führungsebene – bei diesem Tempo wird der ganze Monat um sein, ohne dass wir unsere technischen Schulden in irgendeiner Form reduzieren konnten, möglicherweise nehmen sie sogar zu.«
»Es überrascht mich, dass niemand über die ganzen Probleme spricht, die es mit Umgebungen, automatisierten Tests oder fehlender Telemetrie in der Produktion gibt«, sagt Kurt. »Wir haben einige erstaunliche Möglichkeiten entwickelt, die auch andere nutzen können. Aber wir können keine Lösungen anbieten, wenn die Betroffenen gar nicht wissen, dass sie ein Problem haben.«
Kurt wirkt ratlos. Und frustriert.
»Ich möchte unbedingt dabei helfen«, sagt Shannon und hebt die Hand. »Ich habe schon mit einigen Phoenix-Teams gearbeitet. Ich könnte morgen bei allen vorbeischauen, um sie nach ihren Engpässen zu fragen und danach, ob sie Ideen haben, wie man diese beheben kann.«
»Seht gut, sehr gut«, sagt Kurt und macht sich ein paar Notizen. »Ich würde auch gerne helfen, Shannon«, sagt Maxine. »Aber Tom und ich werden am Montag ziemlich eingespannt sein, denn Montag ist Testtag. Endlich testet QA unsere Änderungen. Davon abgesehen bin ich dabei!« Ein volles Tablett mit Bierkrügen und zwei weiteren Gläsern Wein wird gebracht.
Bald sind alle in intensive Gespräche über technische Schulden und Ideen dazu vertieft, wie man Projekt Umkehr ausnutzen kann. Maxine dreht sich zur Seite, als Erik sich auf den Sitz neben ihr fallen lässt.
Er klinkt sich in das Gespräch ein, als wäre er schon die ganze Zeit dabei gewesen. »Mit Projekt Umkehr stehen Sie alle am Anfang einer großen Reise. Die meisten Tech-Giganten sind durch technische Schulden fast zu Fall gebracht worden: Facebook, Amazon, Netflix, Google, Microsoft, eBay, LinkedIn, Twitter und viele andere mehr. Wie beim Phoenix-Projekt wurden sie so sehr durch technische Schulden belastet, dass sie nicht mehr das liefern konnten, was ihre Kunden verlangten«, sagt Erik. »Die Folgen wären langfristig fatal gewesen – und auf jedes überlebende Unternehmen kommt eine Firma wie Nokia, die durch technische Schulden in den Abgrund gestoßen wurde.
Technische Schulden sind, wie Deadlines, eine Tatsache des Lebens. Businessleute verstehen Fristen, haben aber oft nicht den blassesten Schimmer, dass technische Schulden überhaupt existieren. Technische Schulden sind von Natur aus weder gut noch schlecht – sie entstehen, weil wir in unserer täglichen Arbeit immer wieder Kompromissentscheidungen treffen müssen«, sagt er. »Um eine Deadline einzuhalten, nehmen wir manchmal Abkürzungen oder verzichten auf automatisierte Tests oder codieren etwas fest für einen ganz bestimmten Fall, obwohl wir wissen, dass es langfristig nicht funktionieren wird. Manchmal tolerieren wir täglich wiederkehrende Workarounds, etwa manuell Umgebungen zu erstellen oder Deployments durchzuführen. Wir machen einen schweren Fehler, wenn wir nicht erkennen, wie sehr so etwas unsere zukünftige Produktivität beeinträchtigt.«
Erik schaut sich am Tisch um und freut sich, dass alle seinen Worten aufmerksam lauschen.
»Alle Tech-Giganten haben irgendwann in ihrer Geschichte einen Feature-Freeze eingesetzt, um ihre Systeme massiv neu aufzustellen und die gesamte Architektur umzukrempeln. Man denke nur an Microsoft in den frühen 2000er-Jahren, als Computerwürmer das Internet routinemäßig zum Erliegen brachten, vor allem CodeRed, Nimda und natürlich SQL Slammer, die fast 100.000 Server auf der ganzen Welt in weniger als zehn Minuten infiziert und zum Absturz gebracht hatten. Bill Gates war darüber so besorgt, dass er ein berühmtes internes Memo an seine Mitarbeiter schrieb, in dem er anordnete, dass sich ein Entwickler immer dann, wenn er sich zwischen der Implementierung eines Features und der Verbesserung der Sicherheit entscheiden müsste, Letzteres wählen sollte, weil nicht weniger als das Überleben des Unternehmens auf dem Spiel stünde. Und damit begann die berühmte Sicherheitskampagne, die jedes Produkt bei Microsoft betraf. Interessanterweise pflegt auch Satya Nadella, jetziger Chef von Microsoft, immer noch eine Kultur, in der ein Entwickler, wenn er die Wahl zwischen der Arbeit an einem Feature und der Entwicklerproduktivität hat, immer die Entwicklerproduktivität wählt.
Noch einmal zurück ins Jahr 2002 – damals schrieb der CEO von Amazon, Jeff Bezos, ein ebenfalls berühmtes Memo an die Technologen der Firma, in dem er erklärte, dass sie ihre Systeme so umstrukturieren müssten, dass alle Daten und Funktionen über Dienste bereitgestellt werden. Zuerst nahmen sie die interne Software namens Obidos in den Blick, die ursprünglich 1996 geschrieben worden war und fast die gesamte Geschäftslogik, die Renderingfunktionen der Website und die allgemeine Funktionalität enthielt, die Amazon so berühmt gemacht hatte.
Aber mit der Zeit wurde sie zu komplex bzw. zu komplektiert, als dass die einzelnen Teams noch unabhängig voneinander arbeiten konnten. Amazon hat wahrscheinlich innerhalb von sechs Jahren mehr als eine Milliarde Dollar ausgegeben, um alle internen Dienste neu zu organisieren und zu entkoppeln. Das Ergebnis war verblüffend. In 2013 wurden fast 136.000 Deployments pro Tag durchgeführt. Es ist interessant, dass all diese CEOs, die ich erwähne, selbst einen Softwarehintergrund haben, nicht wahr?
Vergleichen Sie das mit der tragischen Geschichte von Nokia. Als der Markt von Apple und Android aufgemischt wurde, gab Nokia Hunderte Millionen Dollar für die Einstellung von Entwicklern und für Investitionen zur Einführung von Agile aus – aber ohne ihr eigentliches Problem zu erkennen: technische Schulden in Form einer Architektur, in der die Entwickler nicht produktiv sein konnten. Es fehlte ihnen die Einsicht in die Notwendigkeit, die Grundlagen ihrer Softwaresysteme zu erneuern. Genau wie bei Amazon im Jahr 2002 waren die Softwareteams bei Nokia nicht mehr in der Lage, das zu entwickeln, was aktuell gebraucht wurde, weil sie durch die Symbian-Plattform eingeengt wurden.
In 2010 war Risto Siilasmaa Vorstandsmitglied bei Nokia. Als er erfuhr, dass die Erstellung eines Symbian-Builds ganze 48 Stunden dauerte, fühlte es sich für ihn an, als hätte jemand seinen Kopf mit einem Vorschlaghammer getroffen«, sagt Erik. »Er wusste, dass die Tatsache, dass es zwei Tage dauern würde, bis jemand feststellen könnte, ob eine Änderung funktionierte oder überarbeitet werden musste, auf einen fundamentalen und fatalen Fehler in ihrer Architektur hinwies, der sowohl ihre kurzfristige Rentabilität als auch die langfristige Überlebensfähigkeit zunichtemachte. Unter diesen Umständen hätte selbst die zwanzigfache Anzahl an Entwicklern keinen Geschwindigkeitsvorteil gebracht.«
Erik hält inne. »Es ist unglaublich. Sensei Siilasmaa wusste, dass all die Zusagen, Hoffnungen und Versprechungen, die seitens des Engineerings kamen, pure Illusion waren. Obwohl es zahlreiche interne Bestrebungen zur Migration weg von Symbian gab, wurden diese von den Topmanagern immer wieder torpediert, bis es schließlich zu spät war.
Die kaufmännische Seite versteht Features und Funktionen, Anwendungen oder Apps, sodass es einfach ist, dafür finanzielle Mittel zu erhalten«, fährt er fort. »Aber sie haben keinen Blick für die zugrunde liegende umfangreiche Architektur, auf der alles basiert und die die Systeme, Teams und Daten miteinander verbindet. Und dazu gehören auch außerordentlich wichtige Komponenten: die Systeme, die die Entwickler in ihrer täglichen Arbeit verwenden, um produktiv zu sein.
Es ist schon komisch: Die Technikgiganten setzen ihre besten Engineers für diese unterste Schicht ein, sodass alle Entwickler davon profitieren können. Aber bei Parts Unlimited arbeiten die allerbesten Engineers an den Funktionen der obersten Ebene, während niemand – außer den Praktikanten – auf der untersten Ebene arbeitet, auf der die Produktivität von Entwicklern erst ermöglicht wird.«
Erik fährt fort: »Ihre Aufgabe ist also klar. Sie müssen jetzt technische Schulden zurückzahlen, was Ihnen dabei helfen wird, das Erste Ideal der Lokalität und Einfachheit und das Zweite Ideal von Fokus, Flow und Freude zu realisieren. Aber mit ziemlicher Sicherheit müssen Sie auch das Dritte Ideal der Verbesserung der täglichen Arbeit zu meistern lernen.« Damit steht er auf und verlässt den Tisch so abrupt, wie er sich ihnen angeschlossen hat.
Alle schauen ihm hinterher. Dann sagt Kirsten: »Kommt er zurück?« Nörgel-Dave wirft die Hände in die Luft. »Was bei Nokia passiert ist, passiert jetzt auch bei uns. Vor zwei Jahren konnten wir innerhalb von zwei bis vier Wochen ein wegweisendes neues Feature implementieren. Und wir lieferten eine Menge toller Sachen. Ich erinnere mich noch genau daran! Wenn du eine geniale Idee hattest, konnten wir sie für dich umsetzen.
Aber jetzt? Ähnlich umfangreiche Features dauern 20 bis 40 Wochen. Zehn Mal länger! Kein Wunder, dass alle so wütend auf uns sind«, platzt es aus Dave heraus. »Wir haben mehr Entwickler eingestellt, aber es fühlt sich an, als bekämen wir immer weniger erledigt. Und wir sind nicht nur langsamer, sondern es ist auch noch unglaublich gefährlich geworden, Änderungen vorzunehmen.«
»Das ergibt Sinn«, sagt Kirsten. »Fast alle Kenngrößen zeigen, dass die Produktivität unverändert oder sogar gesunken ist. Die Quote für die Einhaltung der Liefertermine für neue Funktionen hat sich verschlechtert. Ich habe seit unserem letzten Treffen ein wenig recherchiert – und meine Projektleiter gebeten, einige Feature-Implementierungen genauer zu prüfen und herauszufinden, wie viele Teams für die Umsetzung erforderlich waren. Die durchschnittliche Anzahl der involvierten Teams betrug 4,2, was schockierend hoch ist. Dann erzählten sie mir, dass in vielen Fällen mehr als acht Teams interagieren mussten«, berichtet sie. »Wir haben es zwar nie formell aufgezeichnet, aber die meisten meiner Leute sagen, dass diese Zahlen definitiv höher sind als vor zwei Jahren.«
Maxine fällt die Kinnlade herunter. Absolut niemand kann irgendetwas erreichen, wenn er ständig mit acht anderen Teams zusammenarbeiten muss – das ist ihr klar. Genau wie bei den Garantieerweiterungen, an denen sie mit Tom gearbeitet hat.
»Nun, Projekt Umkehr ist unsere Chance, einige dieser Dinge zu beheben und uns einen Ausweg aus dieser Situation zu erarbeiten«, sagt Kurt. »Shannon will herausfinden, welche Hilfestellung die Phoenix-Teams brauchen. Wie sieht es mit uns aus? Wenn uns jemand die Autorität übertrüge und zudem für einen Monat unendliche Mittel an die Hand gäbe, was würden wir tun?«
Maxine grinst, als sie die Vorschläge hin und her fliegen hört. Sie beginnen, eine Liste zu erstellen: Alle Entwickler verwenden eine gemeinsame Build-Umgebung. Alle Entwickler werden durch ein kontinuierliches Build- und Integrationssystem unterstützt. Jeder kann seinen Code in produktionsähnlichen Umgebungen ausführen. Automatisierte Testsuiten sollen das manuelle Testen ersetzen, damit sich die QA-Mitarbeiter höherwertigen Aufgaben widmen können. Die Architektur wird entkoppelt, um die Featureteams von ihren Fesseln zu befreien, sodass Entwickler wieder unabhängig voneinander Werte schaffen können. Alle Daten, die die Teams benötigen, sind über leicht konsumierbare APIs abrufbar.
Shannon schaut lächelnd auf die Liste, die sie erstellt haben. »Ich werde die aktualisierte Liste veröffentlichen, sobald ich die Interviews mit den Teams morgen abgeschlossen habe. Das ist echt spannend«, sagt sie. »Es ist genau das, was unsere Entwickler wollen, selbst wenn sie es nicht so genau ausdrücken können. Und es ist etwas, wobei ich ihnen helfen kann!«
Eine tolle Liste, findet Maxine. Der Enthusiasmus aller Beteiligten ist offensichtlich. »Das ist in der Tat eine großartige Liste, Shannon, die die Art und Weise, in der die Entwickler arbeiten, dramatisch ändern könnte,« stimmt Erik zu und setzt sich diesmal neben Kirsten. Maxine schaut sich um und fragt sich, woher er kommt. Mit einer Geste Richtung Kirsten fährt er fort: »Aber bedenken Sie die gegnerischen Truppen, die sich bereits formieren. Das gesamte Projektmanagement ist bestrebt, Projekte im Zeit- und Budgetrahmen zu halten, die Regeln zu befolgen und vor langer Zeit gemachte Zusagen durchzusetzen. Schauen Sie sich an, wie sich Chris’ Teamleiter verhalten – trotz Projekt Umkehr arbeiten sie weiter an Features, weil sie Angst haben, ihre Termine zu verpassen.
Warum? Vor einem Jahrhundert, als Massenproduktion die Industrie revolutionierte, bestand die Rolle von Führungskräften darin, den Arbeitsprozess zu gestalten und in Einzelschritte zu zerlegen sowie zu überprüfen, ob die Aufgaben von Armeen austauschbarer Arbeiter, die dafür bezahlt wurden, ihre Hände und nicht ihren Kopf zu benutzen, korrekt ausgeführt wurden. Die Arbeit wurde atomisiert, standardisiert und optimiert. Und die Arbeiterinnen und Arbeiter hatten wenig Möglichkeiten, das System, in dem sie gefangen waren, zu verbessern.
Was seltsam ist, nicht wahr?, überlegt Erik. Innovation und Lernen finden an vorderster Front statt, nicht in der Etappe. Probleme müssen dort gelöst werden, wo es zum Tagesgeschäft weltweit führender Experten gehört, ständig mit solchen Problemen konfrontiert zu werden.
Und deshalb betrifft das Dritte Ideal die Verbesserung der täglichen Arbeit. Es ist die ständige Dynamik, die es uns ermöglicht, unsere Arbeitsweise zu verändern und zu verbessern, indem wir lernen. Wie Sensei Dr. Steven Spear gesagt hat: ›Unwissenheit ist die Mutter aller Probleme, und das Einzige, womit man sie überwinden kann, ist Lernen.‹
Das am meisten untersuchte Beispiel einer lernenden Organisation ist Toyota«, fährt er fort. »Die berühmte Andon-Leine ist nur eines der vielen Werkzeuge bei Toyota, die Lernen ermöglichen. Wenn jemand auf ein Problem stößt, erwarten alle, dass er sofort um Hilfe bittet, auch wenn es bedeutet, dass die gesamte Montagelinie angehalten werden muss. Und man bedankt sich sogar dafür, denn es ist eine Gelegenheit, die tägliche Arbeit zu verbessern.
So werden Probleme schnell erkannt, man schwärmt aus und löst sie, und danach werden die neuen Erkenntnisse weiterverbreitet, sodass alle davon profitieren können«, erklärt er. »Das ist es, was Innovation und operative Exzellenz ermöglicht – und das Übertrumpfen des Wettbewerbs durch effektiveres Lernen.
Im Widerspruch zum Dritten Ideal steht jemand, der auf der Einhaltung der Prozesse besteht und SHWESIG unterwegs ist«, sagt er mit einem breiten Lächeln. »SHWESIG: So Haben Wir Es Schon Immer Gemacht. Das ist diese riesige Bibliothek an Regeln und Vorschriften, Prozessen und Verfahren, Genehmigungen und Stage-Gates – wobei ständig neue Regeln hinzugefügt werden, um zu verhindern, dass sich eine jüngst ereignete Katastrophe wiederholt.
Sie kennen das vielleicht als starre Projektpläne, unflexible Beschaffungsabläufe, mächtige Architekturprüfungsausschüsse, unregelmäßige Release-Pläne, langwierige Genehmigungsprozesse, strikte Aufgabentrennung …
Alle diese Dinge tragen zu den Koordinierungskosten unserer Handlungen bei und erhöhen die Verzögerungskosten. Und weil die Entfernung zwischen den Stellen, an denen entschieden wird, und den Orten, an denen die Arbeit geleistet wird, immer größer wird, nimmt die Qualität unserer Ergebnisse ab. Wie Sensei W. Edwards Deming einmal bemerkt hat, ›wird ein schlechtes System einen guten Menschen in jedem Einzelfall besiegen‹.
Möglicherweise müssen Sie alte, überkommene Regeln ändern oder die Art und Weise, in der die Mitarbeiter eingesetzt werden und Ihre Systemarchitektur funktioniert«, fährt er fort. »Für eine Führungskraft besteht die Aufgabe nicht mehr darin, streng zu lenken und zu kontrollieren, sondern zu lotsen und zu beraten, Möglichkeiten zu schaffen und Hindernisse zu beseitigen. General Stanley McChrystal hat in massiver Weise die Entscheidungsbefugnis in der Joint Special Operations Task Force dezentralisiert, um endlich Al Qaida im Irak, diesen viel kleineren, aber schlagkräftigeren Gegner, besiegen zu können. Hier wurden die Folgen von Verzögerungen nicht in Geld gemessen, sondern in Menschenleben und der Sicherheit der Einwohner, die geschützt werden sollten.
Das ist kein Servant Leadership, sondern eine transformative Form der Führung«, stellt Erik fest. »Dazu muss es für eine Organisation eine Vision geben, muss man intellektuell bereit sein, die Grundannahmen von Arbeitsabläufen infrage zu stellen, muss man den Wert inspirierender Kommunikation, persönlicher Anerkennung und unterstützender Führung verstehen.
Manche denken, dass es darum geht, dass die Chefs nett sind«, lacht Erik. »Quatsch. Es geht um Exzellenz, das unermüdliche Streben nach Perfektion, den dringlichen Wunsch, eine Mission zu erfüllen, ständige Unzufriedenheit mit dem Status quo und eine Begeisterung dafür, denjenigen zu helfen, denen die Organisation dient.
Was uns zum Vierten Ideal der psychologischen Sicherheit bringt. Niemand wird Risiken eingehen, experimentieren oder Neuerungen einführen, wenn eine Kultur der Angst herrscht, in der die Menschen sich nicht trauen, dem Chef schlechte Nachrichten zu überbringen«, sagt Erik feixend. »In solchen Organisationen ist man innovationsscheu, und wenn irgendwo ein Problem auftritt, lautet die erste Frage: ›Wer ist dafür verantwortlich?‹ Dann werden die Verursacher benannt, beschuldigt und beschämt. Es werden neue Regeln geschaffen, mehr Freigabeprozesse und zusätzliche Drills eingeführt. Falls nötig, entledigt man sich des ›faulen Apfels‹ und macht sich vor, das Problem damit gelöst zu haben«, fährt er fort.
»Das Vierte Ideal behauptet, dass wir eine psychologische Sicherheit brauchen, die garantiert, dass es für jeden gefahrlos möglich ist, Probleme anzusprechen. Bei Google hat eine Forschergruppe mehrere Jahre das Projekt Oxygen verfolgt und festgestellt, dass psychologische Sicherheit einer der wichtigsten Faktoren für das gute Funktionieren von Teams ist: Man muss sich darauf verlassen können, dass das Team niemanden beschämt, ablehnt oder bestraft, wenn er oder sie sich zu Wort meldet. Wenn etwas schiefgeht, sollten wir fragen: ›Was hat das Problem verursacht?‹, nicht ›Wer?‹. Wir verpflichten uns, die Zukunft besser zu gestalten als die Gegenwart. Wie Sensei John Allspaw gesagt hat, ist jeder Zwischenfall eine Gelegenheit zum Lernen, eine ungeplante Investition, die ohne unsere Zustimmung erfolgt ist.
Stellen Sie sich folgendes Szenario vor: Sie sind Teil einer Organisation, in der jeder Einzelne Entscheidungen trifft, jeden Tag wichtige Probleme löst und anderen beibringt, was er gelernt hat«, sagt Erik. »Ihr Gegner ist eine Organisation, in der nur die obersten Führungskräfte Entscheidungen treffen. Wer wird gewinnen? Ihr Sieg ist unvermeidlich.
Es ist verdammt einfach für Führungskräfte, in Phrasen und Plattitüden über psychologische Sicherheit zu reden und darüber, den Mitarbeitern an der Front eine Stimme und mehr Einfluss zu geben«, konstatiert er. »Aber es reicht nicht, irgendwelche Plattitüden zu verbreiten. Eine Unternehmensführung muss die gewünschten Verhaltensweisen ständig vorleben und trainieren und positiv verstärken. Psychologische Sicherheit verflüchtigt sich schnell, wenn Führungskräfte mikromanagen, nicht zu ihren eigenen Wissenslücken stehen und sich wie aufgeblasene, arrogante Besserwisser gerieren. Und es geht nicht nur um die Führungspersönlichkeiten, sondern auch darum, wie sich die Kolleginnen und Kollegen verhalten.«
Ein Barkeeper kommt auf Erik zu und flüstert ihm etwas ins Ohr. Erik murmelt: »Schon wieder?« Er schaut auf und sagt: »Ich bin gleich wieder da. Ich muss mich kurz um etwas kümmern«, und verschwindet.
Alle am Tisch starren Erik hinterher. Dwayne sagt schließlich: »Er hat absolut recht mit seinem Dritten und Vierten Ideal. Was können wir gegen die Kultur der Angst tun, die bei uns überall herrscht? Denkt nur an das, was mit Chad passiert ist. Er hat versucht, das Richtige zu tun, und ist dafür gefeuert worden. Ich habe wahrscheinlich mehr Gründe, Chad nicht zu mögen, als jeder andere von euch – diese ständigen alltäglichen Netzwerkausfälle haben mich verrückt gemacht. Aber ihn zu entlassen, trägt nicht dazu bei, dass diese Ausfälle in Zukunft weniger werden.«
»Ich habe mich ein wenig umgehört, um herauszufinden, was tatsächlich passiert ist«, fährt Dwayne fort. »Offenbar hatte Chad zusätzlich zu seinem normalen Dienst vier Nächte nacheinander gearbeitet, um bei der Initiative zur Modernisierung der Filialen mitzuhelfen. Als ich ihn fragte, warum er das mache, lautete seine Antwort, dass er nicht an miesen Beurteilungen der Kollegen in den Filialen schuld sein wolle.«
Kirsten runzelt die Stirn. Dwayne fährt fort: »Sein Manager drängte ihn immer wieder, nach Hause zu gehen, und am Mittwoch verließ er schließlich auch pünktlich das Büro. Aber um Mitternacht war er schon wieder online, weil er das Team nicht im Stich lassen wollte. Er war so besorgt wegen der sich anstauenden Arbeit in Tickets und Chatrooms, dass er nachts nicht mehr durchschlafen konnte. Also kommt er am Donnerstagmorgen zur Arbeit, immer noch müde von all diesen langen Nächten, und nimmt eine dringend notwendige interne Veränderung am Netzwerk vor«, erzählt Dwayne weiter. »Er öffnet seinen Laptop, und da warten ungefähr 30 geöffnete Terminalfenster mit all den Dingen, an denen er aktuell arbeitet. In eins davon gibt er einen Befehl ein und drückt Enter. Und es stellt sich heraus, dass er das falsche Fenster erwischt hat.
Bam! Die meisten der Tier-2-Businesssysteme sind nicht mehr erreichbar, einschließlich des Data Hub«, sagt er. »Am nächsten Tag wird er gefeuert. Erscheint euch das richtig? Ist das fair oder gerecht?«
»Oh, mein Gott«, platzt Maxine entsetzt heraus. Sie weiß genau, wie sich das anfühlt. Sie hat so etwas in ihrer Laufbahn schon mehrmals selbst erlebt. Du tippst etwas ein, drückst die Eingabetaste und merkst sofort, dass du einen großen Fehler gemacht hast, aber es ist zu spät. Einmal hat sie versehentlich eine Kundendatenbank gelöscht, weil sie dachte, es sei die Testdatenbank. Sie hat versehentlich den falschen Produktionsserver neu gestartet und damit ein Auftragseingabesystem für einen Nachmittag außer Betrieb gesetzt. Sie hat falsche Verzeichnisse gelöscht, falsche Servercluster heruntergefahren und falsche Anmeldeinformationen deaktiviert.
Jedes Mal hatte sie das Gefühl, ihr Blut würde zu Eis gefrieren, gefolgt von Panik. Einmal, zu Beginn ihrer Laufbahn, als sie versehentlich das Quellcode-Repository der Produktivumgebung gelöscht hatte, wollte sie sich am liebsten unter ihrem Schreibtisch verkriechen. Aufgrund des verwendeten Betriebssystems wusste sie, dass niemals jemand herausfinden würde, dass sie dafür verantwortlich war. Aber obwohl sie Angst davor hatte, beichtete sie es ihrem Manager. Das war eines der schrecklichsten Erlebnisse in ihrer Zeit als Berufsanfängerin.
»Das ist wirklich, wirklich scheiße, Dwayne«, findet Brent. »Das hätte auch ich sein können … Im Ernst, ich bin ständig in Situationen, in denen mir solche Fehler passieren können.«
Maxine stimmt zu: »Genau, das hätte jeden von uns treffen können. Unsere Systeme sind so eng miteinander verknüpft, dass selbst kleinste Änderungen katastrophale Auswirkungen haben können. Und schlimmer noch, Chad konnte nicht um Hilfe bitten, als er sie offensichtlich gebraucht hätte. Niemand kann auf Dauer solche wahnsinnig langen Arbeitszeiten durchhalten. Wer würde nicht irgendwann anfangen, Fehler zu machen, wenn man nächtelang kaum ein Auge zumacht?«
»Genau!«, ruft Dwayne. »Wie konnte es so weit kommen, dass überhaupt jemand vier Nächte hintereinander durcharbeitet? Was für Erwartungen werden an uns gestellt, dass jemand nicht mal einen Tag freinehmen kann, wenn es dringend nötig ist? Und was für eine Botschaft wird gesendet, wenn die Belohnung für solch eine Einsatzbereitschaft letztlich die Entlassung ist?«
»Ausgezeichneter Punkt, Dwayne«, lobt Erik, der erneut zu ihnen an den Tisch zurückgekehrt ist. »Sie wären überrascht, wie sehr Steve dieses Gefühl der Ungerechtigkeit würde nachempfinden können. Sie wüssten es, wenn Sie schon einmal in der Fertigung gearbeitet hätten.«
»Wie das?«, fragt Maxine. Sie hat schon oft direkt mit dem Fabrikpersonal gearbeitet.
»Wussten Sie, dass Steve, als er als COO und VP of Manufacturing zu Parts Unlimited kam, seine Zusage davon abhängig machte, dass das Unternehmen öffentlich das Ziel ›null Arbeitsunfälle am Arbeitsplatz‹ ausgab? Er wurde fast aus dem Raum gelacht, nicht nur vom Board, sondern auch vom Montagepersonal und sogar von der Gewerkschaftsführung«, sagt Erik lächelnd. »Die Leute dachten, er sei naiv und vielleicht sogar etwas wirr im Kopf. Wahrscheinlich weil sie glaubten, ein ›richtiger Wirtschaftslenker‹ müsse sich an Rentabilität oder Terminerfüllung messen lassen. Oder vielleicht an Qualitätskenngrößen. Aber an Sicherheit?
Es ging das Gerücht um, dass Steve zu Bob Strauss, dem damaligen Chairman, gesagt haben soll: ›Wenn man sich nicht darauf verlassen kann, dass die Mitarbeiter in der Fertigung bei der Arbeit sicher und geschützt sind, warum sollte dann irgendjemand all das glauben, was wir zu unseren Qualitätszielen sagen? Oder über unsere Möglichkeiten, Geld zu verdienen? Sicherheit ist eine wesentliche Voraussetzung von Arbeit.‹«
Erik hält inne. »Selbst in diesen vermeintlich aufgeklärten Tagen äußern sich Führungskräfte selten in dieser Form. Steve hatte sehr genau die Arbeit von Sensei Paul O’Neill studiert, dem legendären CEO von Alcoa in den 1980er- und 1990er-Jahren, der die Sicherheit am Arbeitsplatz über alles andere stellte. Sein Vorstand hielt ihn zunächst für verrückt, aber in den 15 Jahren seiner Amtszeit als CEO stieg der Nettogewinn von 200 Millionen auf 1,5 Milliarden Dollar und die Marktkapitalisierung von Alcoa von 3 auf 27 Milliarden Dollar.
Trotz dieser beeindruckenden wirtschaftlichen Leistung«, fährt Erik fort, »spricht Sensei O’Neill vor allem über sein Vermächtnis in Sachen Arbeitssicherheit. Seit Jahrzehnten ist Alcoa unangefochtener Branchenbester, was die Sicherheit am Arbeitsplatz betrifft. Als er zum Unternehmen kam, war Alcoa bereits zu Recht stolz darauf, eine überdurchschnittliche Sicherheitsbilanz aufzuweisen. Aber da jedes Jahr dennoch rund zwei Prozent der 90.000 Mitarbeiter verletzt wurden, bestand eine 40-prozentige Wahrscheinlichkeit, dass man am Arbeitsplatz verletzt werden würde, wenn man lebenslang bei Alcoa beschäftigt bliebe.
Bei Alcoa herrschen weitaus gefährlichere Arbeitsbedingungen als in Ihren Werken«, sagt er. In der Aluminiumverarbeitung muss man mit großer Hitze, hohem Druck, korrosiven Chemikalien und tonnenschweren Endprodukten umgehen, die zudem sicher transportiert werden müssen.
Sensei O’Neill drückte es mit diesen berühmten Worten aus: ›Jeder ist nicht nur für seine eigene Sicherheit, sondern auch für die seiner Teamkollegen verantwortlich. Wenn Sie etwas bemerken, das jemanden verletzen könnte, müssen Sie die Gefahr so schnell wie möglich beheben.‹ Er hat immer betont, dass die Beseitigung von Sicherheitsproblemen niemals im Budget veranschlagt werden sollte. Gefahren sollten einfach entschärft werden, und das nötige Geld dafür würde man im Nachhinein schon lockermachen«, fährt Erik fort. »Er hat tatsächlich allen Werksarbeitern seine private Telefonnummer gegeben mit der Aufforderung, ihn anzurufen, wenn sie jemals mitbekämen, dass irgendein Werksleiter nicht schnell genug reagieren oder Sicherheitsaspekte nicht ernst genug nehmen würde.
Sensei O’Neill erzählte eine Geschichte über den ersten Todesfall am Arbeitsplatz, mit dem er zu tun hatte«, fährt Erik fort. »Dabei starb in Arizona ein 18-jähriger Junge. Er kletterte in eine Extrusionsmaschine und versuchte, ein Stück Abfallmaterial zu entfernen. Doch als er das tat, löste sich ein Ausleger, der herumschwang und ihn tötete.
Dieser junge Mann hatte eine Frau, die im sechsten Monat schwanger war«, erzählt Erik. »Es gab dort zwei Aufseher. Sensei O’Neill sagte, beide hätten dem jungen Mann dabei zugesehen und ihm dieses Verhalten wahrscheinlich selbst beigebracht.
Am Ende stand Sensei O’Neill vor der gesamten Belegschaft und erklärte den Mitarbeitern: ›Wir haben ihn getötet. Wir alle haben ihn getötet. Ichhabe ihn getötet. Weil ich nicht deutlich genug gemacht habe, dass sich unsere Mitarbeiter bei der Arbeit nicht verletzen dürfen. Und deshalb haben es Mitarbeiter in Kauf genommen, dass Menschen verletzt werden. Wir alle sind dafür verantwortlich, uns selbst und alle anderen zu schützen.‹
Weiter berichtete er: ›Die Belegschaft von Alcoa bestand aus äußerst fürsorglichen Menschen. Jedes Mal, wenn jemand verletzt worden war, trauerten sie und bedauerten den Unfall – aber sie verstanden nicht, dass sie selbst dafür verantwortlich waren. Es war zu einem erlernten Verhalten geworden, Verletzungen in Kauf zu nehmen.‹«
Erik macht eine kurze Pause, um sich eine Träne aus dem Auge zu wischen. »Eine von Steves ersten Maßnahmen war die Einbeziehung von Sensei O’Neills vorrangigem Ziel von null Unfällen am Arbeitsplatz in jeden Aspekt des Betriebs der Produktionsanlagen hier bei Parts Unlimited. Eine seiner ersten Handlungen war die Einführung einer Richtlinie, dass ihm jeder Arbeitsplatzunfall innerhalb von 24 Stunden direkt gemeldet werden muss, zusammen mit Verbesserungsplänen. Was für ein großartiges Beispiel für das Dritte Ideal der Verbesserung der täglichen Arbeit und das Vierte Ideal der psychologischen Sicherheit.«
Während Erik einige Augenblicke lang seinen Blick starr auf die Wand richtet, wird Maxine plötzlich klar, warum Steve in jedem Townhall-Meeting über Sicherheit am Arbeitsplatz spricht. Er weiß, dass er die tägliche Arbeitsroutine der Mitarbeiter nicht direkt beeinflussen kann. Dennoch kann er die gewünschten Werte und Normen auf diese Weise effektiv vermitteln und verstärken, wie Maxine erkennt.
Sie schaut Erik an. Sie hat bisher noch nie mit Steve gesprochen. Wie könnte sie also das umsetzen, wovon Erik gesprochen hat?
Von: Chris Allers (VP, R&D)
An: Alle Mitarbeiterinnen und Mitarbeiter im Development; Bill Palmer (VP, IT Operations)
Datum: 25. September, 23:10
Betreff: Projekt Umkehr: Feature-Freeze
Mit sofortiger Wirkung wird im Rahmen von Projekt Umkehr ein Feature-Freeze für das Phoenix-Projekt verhängt. Wir werden 30 Tage lang maximale Anstrengungen unternehmen, um die Stabilität und Zuverlässigkeit von Phoenix sowie aller unterstützenden Systeme zu verbessern.
In dieser Zeit werden wir die Arbeit an allen Features unterbrechen, damit wir Mängel beheben, problematische Bereiche des Codes überarbeiten und unsere technischen Schulden begleichen können. Auf diese Weise erhöhen wir die Entwicklungsproduktivität und erreichen in Zukunft einen schnelleren Featuredurchsatz.
Während dieses Zeitraums werden wir auch alle Phoenix-Deployments aussetzen, mit Ausnahme von Notfalländerungen, und unsere Ops-Teamkollegen werden daran arbeiten, die Bereitstellungen schneller und sicherer zu gestalten und die Belastbarkeit unserer Produktivsysteme zu erhöhen.
Wir sind zuversichtlich, dass dies dem Unternehmen helfen wird, seine wichtigsten strategischen Ziele zu erreichen. Wenn Sie Fragen haben, schicken Sie mir bitte eine E-Mail.
Vielen Dank, Chris
Von: Alan Perez (Operating Partner, Wayne-Yokohama Equity Partners)
An: Sarah Moulton (SVP of Retail Operations)
Datum: 27. September, 15:15
Betreff: Strategische Optionen **VERTRAULICH**
Sarah – ganz im Vertrauen …
Das war ein gutes Meeting gestern. Ich freue mich, dass ich die Gelegenheit hatte, Ihnen meine Philosophie bezüglich der Generierung von Shareholder Value zu erläutern – ganz generell bevorzugen wir »Value« und operative Disziplin gegenüber Wachstum. Unsere Firma hat durch Investitionen in Unternehmen wie Parts Unlimited außerordentliche Renditen erzielt. Mein Plan würde einen außergewöhnlichen und beständigen Cashflow ermöglichen, und zwar in einer Geschwindigkeit, die die meisten Menschen normalerweise für unmöglich halten. In anderen Unternehmen haben wir für Investoren (und Führungskräfte) beträchtlichen Wohlstand geschaffen.
Wie versprochen, stelle ich Ihnen mehrere CEOs aus unserem Unternehmensportfolio vor, mit denen Sie vielleicht Gespräche führen möchten. Bitte fragen Sie sie, wie wir ihnen bei der Steigerung des Shareholder Value geholfen haben.
Mit freundlichen Grüßen, Alan
PS: Habe ich richtig verstanden, dass es jetzt einen »Feature-Freeze« für Phoenix gibt? Vergrößert das den Rückstand nicht zusätzlich? Und was machen Sie jetzt mit all den neu hinzugezogenen Entwicklern, über die Sie beim letzten Mal gesprochen haben? Wie werden sie eingesetzt?