Читать книгу Projekt Unicorn - Gene Kim - Страница 13

Maxine checkt ihre Aufgabenliste und schüttelt langsam und frustriert den Kopf. Sie ist jetzt seit zwei Tagen hier und entschlossen, einen Phoenix-Build auf ihrem Laptop durchzuführen, so wie es jeder neue Entwickler tun sollte. Das ist ihre aktuelle Mission. Aber laut ihrer Liste gibt es über 100 fehlende Items, und niemand scheint zu wissen, wo sie zu finden sind.

Sie hat noch nichts von dieser Liste erledigt. Abgesehen von der Aktualisierung und dem Versand ihres Lebenslaufs. Viele Freunde haben ihr sofort geantwortet und versprochen, sich nach offenen Stellen umzusehen, die für sie interessant sein könnten.

Maxine hat ihren Guide Josh nach all den Detailangaben gefragt, die ihr für einen Build fehlen, aber er konnte ihr nicht weiterhelfen. Normalerweise weiß ein Build-Team solche Dinge, aber die Details sind entweder veraltet oder fehlen ganz, das Wissen ist über die gesamte Organisation verstreut.

Sie ist frustriert, jede Abzweigung, die sie nimmt, führt in eine Sackgasse. Keine Herausforderung, die ihr Spaß macht. Was sie tut, da ist sie sich ziemlich sicher, ist eher das genaue Gegenteil von Spaß.

Im Herzen ist sie Softwareingenieurin und liebt Herausforderungen und Problemlösungen. Sie wurde mitten im wohl wichtigsten Projekt in der Geschichte des Unternehmens ins Exil geschickt. Und irgendwo existiert Code – ziemlich sicher Millionen von Codezeilen, die von Hunderten von Entwicklern über fast drei Jahre hinweg geschrieben wurden. Aber sie kann keine einzige Zeile davon finden.

Maxine liebt das Codieren und beherrscht es hervorragend. Aber sie weiß, dass es noch etwas Wichtigeres gibt als Code: die Systeme, die es Entwicklern ermöglichen, produktiv zu sein, sodass sie schnell und sicher hochwertigen Code schreiben und sich von all den Dingen befreien können, die sie daran hindern, wichtige Geschäftsprobleme zu lösen.

Systeme, die hier völlig zu fehlen scheinen. Maxine ist eine der Besten in ihrem Metier, aber nach vier Tagen hat sie noch immer fast nichts vorzuweisen. Einfach endloses Herumklicken, Dokumente lesen, Tickets öffnen, Meetings mit Menschen planen, um die Informationen zu bekommen, die sie benötigt, gefangen in der schlimmsten Schnitzeljagd aller Zeiten.

Für einen Moment fragt sich Maxine, ob sie die einzige Person ist, die dieses Problem hat. Aber sie sieht überall um sich herum Entwickler, die sich abmühen, sodass sie all ihre Selbstzweifel schnell zur Seite schiebt.

Maxine weiß, dass sie ein erstaunliches Kung Fu besitzt. Im Lauf ihrer Karriere musste sie schon oft Probleme bewältigen, die ihr hoffnungslos und unüberwindbar erschienen. Oft mitten in der Nacht. Manchmal ohne Zugriff auf Dokumentation oder Quellcode. Eines ihrer berühmtesten Kunststücke ist immer noch bekannt als der »Maxine Post-Holiday Save«, bei dem am Freitag nach Weihnachten in den Filialen alle Vor-Ort-Systeme, mit denen Umtauschaktionen und Rückerstattungen abgewickelt wurden, spektakulär abstürzten. Dieser Tag ist einer der geschäftigsten Einkaufstage des Jahres, an dem die Menschen in die Läden strömen, um Geschenke ihrer Lieben zurückzugeben, damit sie sich stattdessen die Produkte besorgen können, die sie wirklich haben wollen.

Mit ihrem Team arbeitete Maxine bis in die frühen Morgenstunden des Samstags daran, einen Multi-Threading-Deadlock im ODBC-Treiber eines Datenbankanbieters zu beheben. Sie musste die Vendor-Library manuell disassemblieren und dann einen Binär-Patch generieren. Von Hand.

Alle hatten behauptet, das sei nicht machbar. Aber zum Erstaunen aller Kollegen, die bereits weit über sieben Stunden an der Behebung dieses Ausfalls gearbeitet hatten, schaffte sie es. Das Professional Services Team des Datenbankanbieters bot ihr voller Bewunderung sofort eine Stelle an, die sie höflich ablehnte.

Nach und nach entstanden weitere Legenden über sie. Sie ist klassisch als Entwicklerin ausgebildet und hat in ihrer Laufbahn Software geschrieben, um Panoramabilder zu stitchen, hat Chip-Layout-Algorithmen für CAD/CAM-Anwendungen sowie Backend-Server für hochskalierende Multiuser-Games entworfen und in jüngster Zeit die Bestell-, Nachschub- und Planungsprozesse entwickelt, um das Zusammenspiel Tausender von Lieferanten in einem Produktionszeitplan für MRP-Systeme zu orchestrieren.

Sie lebt routinemäßig in der Welt der NP-vollständigen Probleme, die so schwierig sind, dass sie nicht in Polynomialzeit gelöst werden können. Sie liebt die Website Papers We Love, auf der sie immer mal wieder in ihren akademischen Lieblingsarbeiten aus Mathematik und Informatik schmökert.

Aber sie sah ihre Arbeit nie bloß als Schreiben von Anwendungscode – als etwas, das ausschließlich vor der Bereitstellung passiert. In der Produktion, wenn Theorie auf Realität trifft, hat sie Middleware-Server gefixt, die verrücktspielten, überlastete Nachrichtenbusse, intermittierende Ausfälle in RAID-Disk-Arrays und Core-Switches, die irgendwie immer wieder in den Halbduplexmodus umschalteten.

Sie hat technische Komponenten wieder in Ordnung gebracht, die sich mitten in der Nacht quasi »übergaben« und praktisch jede erreichbare Festplatte und jeden Logserver zumüllten, sodass die Teams nicht mehr herausfinden konnten, was eigentlich vor sich ging. Sie leitete dabei die Anstrengungen zur systematischen Isolierung, Diagnose und Wiederherstellung dieser Dienste mit der Intuition jahrzehntelanger Erfahrung aus unzähligen »Schlachten« in Produktivumgebungen.

Sie hat Stacktraces auf Anwendungsservern entziffert, die buchstäblich in Flammen standen, und sich in einem Wettlauf gegen die Zeit bemüht, sie vernünftig zu sichern, bevor das Wasser aus den Sprinklern, die Halonlöscher und die Notstromabschaltungen alles zerstörten.

Aber tief drinnen ist sie Entwicklerin. Sie ist eine Entwicklerin, die funktionale Programmierung liebt, weil sie weiß, dass pure Funktionen und Zusammensetzbarkeit die besseren Denkwerkzeuge sind. Sie verzichtet auf imperative Programmierung zugunsten deklarativer Denkweisen. Sie lehnt mit gesundem Respekt Zustandsveränderungen und nicht referentielle Transparenz ab. Sie bevorzugt die Lambda-Kalkulation gegenüber Turingmaschinen wegen ihrer mathematischen Reinheit. Sie liebt LISPs, weil sie Code als Daten betrachtet und umgekehrt.

Aber sie besitzt nicht nur ein Talent für theoretische Betrachtungen – sie liebt es auch, sich die Hände schmutzig zu machen, Geschäftswerte in Bereichen zu heben, an die zuvor niemand gedacht hat, oder per Strangler Pattern jahrzehntealten monolithischen Code zu zerlegen und ihn sicher, souverän und oft brillant zu ersetzen.

Sie ist immer noch die einzige Person, die alle Shortcuts kennt – von vi bis zu den neuesten und mächtigsten Editoren. Aber sie schämt sich auch nicht, zuzugeben, dass sie noch immer fast jede Kommandozeilenoption für Git nachschlagen muss – Git kann einfach beängstigend schwierig sein! Welches andere Tool verwendet SHA-1-Hashes als Teil seiner Benutzeroberfläche?

Und doch sitzt sie, so begabt sie auch sein mag, mit all ihren über Jahrzehnte verfeinerten Kniffen und Fähigkeiten, plötzlich mitten im Phoenix-Projekt und schafft es selbst nach zwei Tagen nicht, einen Phoenix-Build hinzubekommen. Sie hat inzwischen herausgefunden, wo sich zwei der vier Quellcode-Repositories befinden, und drei Installationsprogramme für einige der proprietären Compiler und die Versionsverwaltung ausfindig gemacht.

Aber immer noch wartet sie auf Lizenzschlüssel für die Versionsverwaltung und weiß nicht, wen sie um die Lizenzen für die beiden anderen Build-Tools bitten soll. Sie braucht Anmeldedaten für drei Netzwerkfreigaben und fünf SharePoints, und niemand weiß, wo die zehn mysteriösen Konfigurationsdateien zu bekommen sind, von denen in der Dokumentation die Rede ist. Die E-Mail, die sie dem Verfasser der Docs geschickt hat, kam zurück. Er arbeitet schon lange nicht mehr bei Parts Unlimited.

Sie steckt fest. Niemand antwortet wirklich zügig auf ihre E-Mails, ihre Tickets oder Sprachnachrichten. Sie hat Randy gebeten, ihr dabei zu helfen, ihre Anfragen zu eskalieren, aber alle zuständigen Kollegen antworten, dass es ein paar Tage dauern wird, weil sie so beschäftigt sind.

Natürlich akzeptiert Maxine niemals ein einfaches »Nein« als Antwort. Sie hat es sich zur Aufgabe gemacht, alles zu tun, was nötig ist, um einen Build zu erstellen. Sie hat fast alle, die ihr irgendetwas versprochen haben, in persona aufgetrieben. Sie hat herausgefunden, an welchem Arbeitsplatz sie sitzen, und hat sie genervt, praktisch an ihren Schreibtischen gezeltet – bereit, so lange zu bleiben, bis sie ihr endlich weiterhelfen.

Manchmal bekam sie, was sie brauchte: eine URL, ein SharePoint-Dokument, einen Lizenzschlüssel, eine Konfigurationsdatei. Aber meistens hatte die Person, die sie aufgetrieben hatte, doch nicht das, wonach sie suchte – und die Kollegen mussten jemand anderen fragen und im Namen von Maxine ein weiteres Ticket öffnen. Und dann warteten sie beide.

Manchmal fanden sie eine vielversprechende Spur oder einen Hinweis darauf, an wen oder wohin Maxine sich als Nächstes wenden müsste. Meistens war es jedoch eine Sackgasse, und sie stand wieder ganz am Anfang.

Der Versuch, einen Phoenix-Build durchzuführen, ist ungefähr so, als würde man Legend of Zelda spielen, geschrieben von einem Sadisten, der sie zu ausgedehnten Abenteuern zwingt, um versteckte Schlüssel zu finden, die über das ganze Königreich verstreut sind, und gefühllose Nicht-Spieler-Charaktere nur mickrige Hinweise ausspucken lässt. Und wenn man ein Level endlich geschafft hat, kann man das nächste Level doch nicht spielen – zuerst müssen irgendwelche Coupons an den Hersteller geschickt werden, um dann wochenlang auf die Aktivierungscodes zu warten.

Wäre dies wirklich ein Videospiel, wäre Maxine längst ausgestiegen, denn dieses Spiel ist einfach großer Mist. Aber Phoenix ist kein Spiel – Phönix ist wichtig, und bei wichtigen Dingen gibt Maxine niemals auf.

Maxine sitzt an ihrem Schreibtisch und schaut auf den Kalender, den sie ausgedruckt und an die Wand gepinnt hat.

Sie wendet sich wieder ihrem Computer zu und fährt mit dem Finger über ihre ständig wachsende Liste von Aufgaben – jedes Element ist eine Abhängigkeit, die sie benötigt, um den Build durchführen zu können.

Sie hat gerade zwei weitere SharePoint-Anmeldeinformationen hinzugefügt, die sie von zwei verschiedenen Dev-Managern besorgen musste, die aus irgendeinem Grund eigene Active-Directory-Domains nutzen. Es wird gemunkelt, dass dort teils wichtige Build-Dokumentation liegt, die einige der von ihr dringend gesuchten Informationen enthält.

Randy hat ihr eine Unmenge an Word-Dokumenten, Visio-Diagrammen und PowerPoint-Präsentationen geschickt, die sie schnell nach Hinweisen durchsucht. Die Dateien mögen vielleicht für Leute im Marketing oder Softwarearchitekten hilfreich sein, vermutet sie, aber sie ist Entwicklerin, eine Engineer. Sie will keine Hochglanzbroschüren für ein Auto sehen, das jemand zu bauen versprochen hat – sie will die Konstruktionspläne und die tatsächlichen Teile sehen, aus denen dieses Auto zusammengebaut wird.

Da diese ganzen Dokumente dennoch für irgendjemanden nützlich sein könnten, stellt sie sie ins Wiki. Nur Augenblicke später bittet jemand, den sie nicht kennt, darum, sie wieder zu entfernen, weil sie möglicherweise vertrauliche Informationen enthalten könnten.

Weiter unten auf ihrer To-do-Liste liest sie:

Jemanden finden, der mir Zugang zu Dev- oder Testumgebungen geben kann.

Diese waren in einigen der Dokumentationsdateien erwähnt, die sie gestern gelesen hat, aber sie hat nicht die geringste Ahnung, wen sie um Zugang bitten muss.

Einen Punkt hat sie durchgestrichen:

Brauche Konto für Integrationstest-Umgebung.

Das war längst nicht so befriedigend gewesen, wie sie gehofft hatte. Sie hat zwei Stunden lang in dieser Umgebung herumgestöbert und versucht, ein Grundverständnis von der riesigen Anwendung zu entwickeln. Aber am Ende war sie nur noch verwirrt gewesen – als würde man versuchen, sich den Grundriss eines riesigen Gebäudes vorzustellen, indem man ohne Karte oder Taschenlampe durch Luftschächte kriecht.

Sie gibt einen neuen Punkt ein:

Jemanden finden, der tatsächlich Integrationstests durchführt, um ein bisschen Shoulder-Surfing zu betreiben.

Jemandem dabei zuzusehen, wie er mit den Phoenix-Anwendungen arbeitet, könnte ihr bei der Orientierung helfen. Sie ist verblüfft, dass niemand eine Person kennt, die Phoenix tatsächlich benutzt. Für wen genau programmieren sie diesen ganzen Kram?

Als sie ihre Aufgabenliste noch einmal durchsieht, wird ihr klar, dass sie eigentlich nichts zu tun hat – sie hat heute schon alle möglichen Leute genervt und wartet jetzt nur noch darauf, dass diese auf sie zurückkommen – oder auch nicht.

Es ist Freitag, 13:32 Uhr. Noch dreieinhalb Stunden bis fünf, dann kann sie endlich nach Hause. Sie bemüht sich sehr, nicht wieder zu seufzen.

Sie sieht sich ihre Aufgabenliste an. Sie schaut auf die Uhr.

Sie schaut auf ihre Fingernägel und stellt fest, dass sie eine Maniküre braucht.

Sie steht mit ihrer Kaffeetasse vom Schreibtisch auf und geht in die Küche – vorbei an Gruppen von Menschen in Kapuzenpullis, die ihre Köpfe zusammenstecken und in gedämpfter Dringlichkeit miteinander reden. Nur um etwas zu tun zu haben, schenkt sie sich noch einen Kaffee ein. Sie betrachtet ihre Tasse, und ihr wird klar, dass sie heute bereits fünf davon getrunken hat, nur um das Bedürfnis zu befriedigen, wenigstens irgendetwaszu tun. Sie schüttet den Kaffee in den Ausguss.

Neben ihrer ständig wachsenden Aufgabenliste hat Maxine während der letzten zehn Jahre ein Arbeitstagebuch auf ihrem persönlichen Laptop geführt. Darin verzeichnet sie alles, woran sie gearbeitet hat, wie viel Zeit sie damit verbracht hat, die Erkenntnisse, die sie gewonnen hat, sowie eine Liste von Dingen, die sie nie wieder tun sollte (zuletzt: »Verschwende keine Zeit damit, die Verwendung von Leerzeichen in Dateinamen in Makefiles zu vermeiden – das ist zu schwierig. Verwende stattdessen einfach irgendetwas anderes.«).

Sie starrt ungläubig auf ihre riesige Aufgabenliste und ihre jüngsten Tagebucheinträge. Sie ist noch nie einem System begegnet, das sie nicht bezwingen konnte. Ist es möglich, dass das absolut mittelmäßige Phoenix-Projekt, in dem überhaupt nichts klappt, mich tatsächlich unterkriegt? Nur über meine Leiche, gelobt sie schweigend und widmet sich dann wieder ihrem Arbeitstagebuch.

MITTWOCH

16:00: Heute Nachmittag auf Josh gewartet, der mir sein Setup erklären sollte, damit ich es nachbauen kann. Er beschäftigt sich mit weiteren nächtlichen Build-Problemen.

Ich habe ein Ticket platziert, um Zugang zum Build-Server zu erhalten, aber mir wurde vom Sicherheitsdienst mitgeteilt, dass ich die Genehmigung meines Abteilungsleiters benötige. E-Mail an Randy gesendet.

Ich lese jedes Dokument zum Entwicklungsdesign, das ich finden kann, aber langsam sehen sie für mich alle gleich aus. Ich möchte den Quellcode sehen, nicht die Designdokumente lesen.

16:30: In einem der Designdokumente habe ich die prägnanteste Beschreibung von Phoenix gefunden: »Projekt Phoenix wird die Lücke zur Konkurrenz schließen und unseren Kunden ermöglichen, online die gleichen Dinge zu tun wie in unseren 900 Filialen. Wir werden endlich eine einheitliche Sicht auf unsere Kunden erhalten, sodass die Mitarbeiter vor Ort deren Präferenzen und deren Bestellhistorie sehen können, und ermöglichen so eine effektivere Cross-Channel-Werbung.«

Der Umfang von Phoenix ist ein wenig beängstigend. Es muss mit Hunderten von anderen Anwendungen im gesamten Unternehmen kommunizieren. Was könnte da alles schiefgehen!

17:00: Ich mach Schluss für heute. Chris ist vorbeigekommen und hat mich daran erinnert, kein Aufsehen zu erregen und unterm Radar zu bleiben. Und bloß nichts in die Produktivumgebung zu deployen.

Ja, ja, ja. Mein Gott. Ich kann nicht einmal einen Build in Gang bringen oder mich für Netzwerkfreigaben anmelden. Wie sollte ich irgendetwas in Production pushen?

Tödliche Langeweile. Ich geh nach Hause, um mit meinem kleinen Welpen zu spielen.

DONNERSTAG

9:30: Ja! Sie haben mir Accounts für ein paar weitere Wikis gegeben. Ich bin heiß darauf, mich reinzuwühlen. Das ist doch mal ein Fortschritt, oder?

10:00: Im Ernst? Das ist alles? Ich habe einige QA-Dokumente gefunden, aber das kann doch nicht alles sein, oder? Wo sind die Testpläne? Wo sind die automatisierten Testskripte?

12:00: Okay, ich habe William getroffen, den QA-Direktor. Scheint ein netter Kerl zu sein. Das Meeting hat gerade so lange gedauert, dass ich Benutzerkonten für die Netzwerkfreigabe bekommen habe. Millionen von Word-Dokumenten, gefüllt mit manuellen Testplänen.

Habe William eine E-Mail geschickt und ihn gefragt, ob ich mich mit einem Teil seines Testteams treffen kann. Wie führen sie all diese Tests durch? Sieht so aus, als bräuchten sie dazu eine kleine Armee. Und wo werden die Testergebnisse gespeichert? Ich stehe in seinem Kalender. In zwei Wochen. Wahnsinn.

15:00: Ich habe herausgefunden, wo das große tägliche Projekttreffen stattfindet: um 8 Uhr morgens bei den Whiteboards. Heute habe ich es verpasst, aber morgen gehe ich definitiv hin.

17:00: Ich habe in zwei Tagen fast nichts geschafft. Für alles, was ich machen will, muss ich eine E-Mail schreiben, ein Ticket öffnen oder irgendjemanden suchen. Ich verlege mich jetzt darauf, andere zum Kaffee einzuladen. Vielleicht bekomme ich so mehr Antworten.

FREITAG

10:00: Das »15-minütige Stand-up-Meeting« dauerte wegen der vielen Notfälle fast 90 Minuten. Ich weiß nicht, wie ich dieses Treffen gestern versäumen konnte – es wird so viel gebrüllt und geschrien, dass man es eigentlich nur schwer überhören kann. Wow.

OMG. Bei fast niemandem laufen Phoenix-Builds auf den Laptops. Und sie sollen das in ZWEI WOCHEN in Produktion deployen! (Niemand ist besorgt. Verrückt. Sie glauben, dass es erneut verschoben wird.)

Wenn ich an ihrer Stelle wäre, würde ich mir in die Hose machen. Na ja.

14:00: Ich habe eine Reihe von Freelance-Entwicklern gefunden, die vor zwei Monaten hinzugezogen wurden. Sie bekommen auch keine Builds hin. Erschreckend. Ich habe sie zum Mittagessen eingeladen. Was für eine Enttäuschung. Sie wissen noch weniger als ich. Wenigstens war der Salat in Ordnung.

Ich habe ihnen alles erzählt, was ich weiß, wofür sie sehr dankbar waren. Es ist immer gut, mehr zu geben, als man bekommt – man weiß nie, wer einem in Zukunft helfen kann. Vernetzung ist wichtig.

Notiz an mich selbst: Ich muss meinen Kaffeekonsum reduzieren. Gestern habe ich locker sieben Tassen getrunken. Das ist nicht gut – ich glaube, ich bekomme Herzrasen.

Um 16:45 packt Maxine ihre Sachen zusammen. Keine Chance, dass irgendjemand an einem Freitag um diese Zeit noch etwas für sie erledigt.

Sie schafft es fast bis zur Treppe, als sie auf Randy trifft.

»Hi, Maxine. Schade, dass wir mit der Entwicklungsumgebung nicht weitergekommen sind. Ich habe eine Reihe von Problemen eskaliert und werde heute noch einige Telefonate führen, bevor ich gehe.«

Maxine nimmt es gelassen. »Danke. Ich hoffe, das macht ein paar Leuten Feuer unterm Hintern.«

»Was auch immer nötig ist, hm?« Randy lächelt. »Äh, da ist noch eine Sache, die ich von Ihnen brauche …«

Oh oh, denkt Maxine – sagt aber: »Klar, was gibt’s?«

»Ähm. Jeder im Phoenix-Projekt muss seine Arbeitszeit erfassen«, sagt Randy. »Wir müssen den Auslastungsgrad nachweisen, ansonsten nimmt uns das Projektmanagement die Leute weg. Ich habe Ihnen einen Link zu unserem Zeiterfassungssystem geschickt. Könnten Sie das Formular ausfüllen, bevor Sie gehen? Sollte nur ein paar Minuten dauern.«

Er schaut sich nach links und rechts um, bevor er flüstert: »Ich brauche vor allem Ihre Stunden, denn wenn es um die Budgetierung für das nächste Jahr geht, wird es mir helfen, Ihre Position wieder zu besetzen.«

»Überhaupt kein Problem, Randy. Ich kümmere mich darum, noch bevor ich gehe«, sichert Maxine zu, aber so richtig glücklich ist sie damit nicht. Sie hat natürlich Verständnis für das große Budgetspiel, das stört sie gar nicht – sondern dass sie aufgrund ihrer akribischen Notizen schon weiß, was diese Woche als messbares Ergebnis herausgekommen ist: Null. Komma. Nichts.

Zurück an ihrem Schreibtisch, loggt sie sich in das Zeiterfassungssystem ein. Unter ihrem Namen sind Hunderte von Projektcodes zu finden. Nicht etwa die Projektnamen. Stattdessen handelt es sich um Projektcodes, die alle wie die Reservierungsnummern von Fluggesellschaften aussehen – zehn Zeichen lang in Großbuchstaben.

Sie schaut sich Randys E-Mail an, kopiert den Projektcode, den er ihr gegeben hat (PPX423-94-10), in das Feld, gibt dann pflichtgemäß für Mittwoch bis Freitag jeweils acht Stunden ein und klickt auf Senden. Sie runzelt die Stirn. Die Daten lassen sich nicht abschicken, solange sie nicht beschreibt, was genau sie an den Tagen gemacht hat.

Maxine stöhnt. Sie gibt für jeden Tag etwas ein, alles irgendwie Variationen von »An Phoenix-Builds gearbeitet, aber auf Gott und die Welt gewartet, weil mir alles Mögliche fehlt«. Sie verbringt fünf Minuten damit, den Text so abzuwandeln, dass sich die Einträge ausreichend voneinander unterscheiden.

Es hat sich schon schlimm genug angefühlt, die ganze Woche trotz aller Bemühungen so wenig geschafft zu haben, aber es fühlt sich noch viel deprimierender an, jetzt auch noch schriftlich darüber lügen zu müssen.

Während des Wochenendes scannt Maxine ständig ihr Telefon nach Aktualisierungen ihrer offenen Tickets, sieht aber immer nur, wie diese von einer Person zur nächsten wandern. Als ihr Mann Jake sie fragt, warum sie so vor sich hin brütet, weigert sie sich, zuzugeben, dass es an der Zeiterfassung liegt, die sie ausgefüllt hat – es war, wie Salz in die Wunde ihrer Unproduktivität zu reiben. Sie lässt sich von Waffles, ihrem neuen Welpen, ablenken und genießt es, ihre Kinder mit ihm spielen zu sehen.

Bis Montagmorgen hat sich Maxine selbst erfolgreich davon überzeugt, fröhlich, zuversichtlich und optimistisch zu sein, als sie in das riesige Auditorium kommt, in dem das Townhall-Meeting stattfindet, das der CEO des Unternehmens, Steve Masters, alle zwei Monate veranstaltet. Seit ihrem Eintritt in die Firma hat sie dieses immer gern besucht. Insbesondere das allererste Meeting hat sie sehr beeindruckt, weil sie zuvor noch nie erlebt hatte, wie sich Führungskräfte direkt an ein ganzes Unternehmen gewandt und Fragen von fast 7.000 Mitarbeitern beantwortet haben.

Steve moderiert normalerweise zusammen mit Dick, dem CFO. Vor etwa einem Jahr begann Steve, die Townhalls auch zusammen mit Sarah Moulton zu leiten, der Senior VP of Retail Operations. Sie trägt die Ergebnisverantwortung für den Einzelhandel, den zweitgrößten Geschäftsbereich, der über 700 Millionen Dollar Umsatz pro Jahr generiert. Während Steve und Dick ein gewisses Maß an Vertrauen und Authentizität ausstrahlen, wirkt Sarah weniger vertrauens- und glaubwürdig. Letztes Jahr hatten ihre Beiträge bei jedem Townhall-Treffen eine etwas andere Tonlage, jedes Mal versprach sie eine völlig anders geartete Umgestaltung als bei den vorherigen Meetings, verwirrte durch diese organisatorischen Schleudertraumata alle und erntete schließlich: Spott.

Maxine sieht, wie sich Steve abseits der Bühne vorbereitet und Last-Minute-Notizen auf ein gefaltetes Blatt Papier schreibt. Jemand reicht ihm ein Mikrofon, und er betritt unter höflichem Applaus die Bühne. »Guten Morgen allerseits. Vielen Dank, dass Sie heute bei uns sind. Dies ist das 66. Townhall-Meeting, bei dem ich das Privileg habe, Gastgeber zu sein.

Wie Sie wissen, besteht unsere Aufgabe seit fast einem Jahrhundert darin, dafür zu sorgen, dass die Autos unserer hart arbeitenden Kundeninnen und Kunden zuverlässig funktionieren, damit diese ihren Alltag bewältigen können. Für die meisten unserer Kunden bedeutet Alltag, dass sie zur Arbeit fahren, um ihren Lebensunterhalt zu verdienen, dass sie ihre Kinder zur Schule bringen und dass sie in der Lage sind, sich um ihre Familie zu kümmern. Parts Unlimited hilft unseren Kunden in vielerlei Hinsicht. Wir sind ein weltweit angesehenes Fertigungsunternehmen, das die hochwertigen und zugleich erschwinglichen Bau- und Ersatzteile herstellt, die unsere Kunden brauchen, damit ihre Autos störungsfrei laufen. Wir beschäftigen aber auch über 7.000 Mitarbeiterinnen und Mitarbeiter von Weltklasse, die unseren Kunden in fast 1.000 Filialen in diesem großartigen Land zur Seite stehen. Wir sind oft die einzige Alternative, um den Besuch teurer Werkstätten zu vermeiden.«

Maxine hat diese Worte von Steve auf solchen Treffen schon fast 50 Mal gehört – es ist ihm offensichtlich wichtig, alle daran zu erinnern, wer genau ihre Kunden sind. Wenn mit Maxines Auto etwas schiefgeht, bringt sie es normalerweise zu ihrem Autohaus, weil es noch Garantie hat. Aber die große Mehrheit ihrer Kunden hat diesen Luxus nicht. Deren Autos sind älter, manchmal älter als ihre eigenen Kinder – tatsächlich könnte es sein, dass die Kunden von Parts Unlimited dieselbe Marke und dasselbe Modell aus demselben Baujahr fahren, das sie früher als Teenager fuhren. Diese Kunden haben oft nur wenig frei verfügbares Einkommen. Wenn ihr Auto in Reparatur muss, kann es sie ihre ganzen Ersparnisse kosten (falls sie überhaupt welche haben). Und während das Auto in einer Werkstatt steht, frisst es nicht nur ihre Ersparnisse, sondern die Menschen kommen auch nicht zur Arbeit. Und das bedeutet wiederum, dass sie nicht für ihre Familien sorgen können, weil sie kein Geld verdienen.

Maxine schätzt diese Hinweise auf ihre Kunden – wenn Ingenieure »den Kunden« nur abstrakt und nicht als reale Person betrachten, erhält man selten die richtigen Ergebnisse.

Steve fährt fort: »Seit fast einem Jahrhundert hat sich diese Mission nicht geändert, ganz im Gegensatz zum Geschäftsumfeld. Im Fertigungsbereich haben wir jetzt scharfe Konkurrenz aus Übersee, die unsere Preise unterbieten. Im Einzelhandel haben unsere Mitbewerber Tausende von Geschäften in denselben Märkten eröffnet, die wir bedienen.

Wir befinden uns zudem in einer Zeit unglaublicher wirtschaftlicher Veränderungen. Amazon und die anderen E-Commerce-Giganten gestalten unsere Wirtschaft um. Einige der bekanntesten Einzelhandelsketten, mit denen viele von uns aufgewachsen sind, sind pleite gegangen und mussten aufgeben, wie der Spielwaren-Händler Toys’R’Us, der Videoverleiher Blockbuster oder die Buchhandelskette Borders. Gleich in der Nähe unseres Firmensitzes kommen viele von uns jeden Tag an den Räumen vorbei, in denen sich früher eine Blockbuster-Filiale befand und die jetzt seit über einem Jahrzehnt leer stehen.

Dagegen sind auch wir nicht immun. Unsere Umsatzzahlen pro Filiale sind weiterhin rückläufig. Viele unserer Kunden bestellen ihre neuen Scheibenwischer lieber online oder per Telefon bei unseren Konkurrenten, als in einen unserer Läden zu gehen und dort bei realen Menschen zu kaufen.

Aber ich glaube, dass die Konsumenten nicht bloß Autozubehör wollen, sondern auch Hilfestellung von Menschen, denen sie vertrauen können. Und deshalb sind unsere Filialmitarbeiter so wichtig. Deshalb investieren wir so viel in Aus- und Fortbildung. Und das Phoenix-Projekt wird es uns ermöglichen, unseren Kunden dieses Fachwissen und unsere Vertrauenswürdigkeit über die Kanäle anzubieten, die sie bevorzugen, seien es nun unsere physischen Geschäftslokale oder sei es online.

Sarah wird später über den Fortschritt des Phoenix-Projekts sprechen und darüber, wie es die drei Messgrößen unterstützt, die mir am wichtigsten sind: Mitarbeiterengagement, Kundenzufriedenheit und Cashflow. Wenn alle unsere Mitarbeiter jeden Tag begeistert zur Arbeit kommen und wir unsere Kunden durch ständige Innovationen und großartigen Service überzeugen, wird sich das von ganz allein im Cashflow niederschlagen.

Aber bevor wir unsere wichtigsten Jahresziele durchgehen, lassen Sie mich zuerst über etwas sprechen, das wahrscheinlich Ihnen allen auf der Seele liegt.« Steve hält für einen Moment inne. »Vor Kurzem habe ich eine E-Mail mit der Nachricht verschickt, dass Bob Strauss den Vorsitz von Parts Unlimited übernimmt. Wie viele von Ihnen wissen, bin ich seit elf Jahren im Unternehmen – und in den ersten acht davon hatte ich das Privileg, für Bob zu arbeiten. Er war derjenige, der mich damals eingestellt hat, als ich noch Verkaufsleiter bei einem anderen Hersteller war. Ich werde Bob immer dafür dankbar sein, dass er mir die Chance gegeben hat, COO dieses Unternehmens zu werden, und dass er mich über die Jahre hinweg als Mentor begleitet hat. Als er in den Ruhestand ging, übernahm ich von ihm das Amt des CEO und Vorsitzenden.

Mit Wirkung von letzter Woche hat das Board of Directors Bob erneut zum Chairman ernannt«, sagt Steve, während seine Stimme zu zittern beginnt. Maxine sieht erstaunt, wie er sich eine Träne aus dem Auge wischt. »Natürlich unterstütze ich diesen Schritt und freue mich darauf, wieder mit Bob zusammenzuarbeiten. Ich habe Bob gebeten, ein paar Worte an uns zu richten und uns zu sagen, was das für das Unternehmen bedeutet.«

Bis zu diesem Moment war Maxine nicht klar, welch großer Rückschlag das für Steve sein musste. Sie hatte gehört, dass es sich um eine Degradierung handelte, aber, um ehrlich zu sein, sie verstand diese Art von Veränderungen auf der Führungsebene nicht wirklich und interessierte sich auch nicht besonders dafür. Führungskräfte kamen und gingen – oft ohne großen Einfluss auf sie und ihre tägliche Arbeit. Aber jetzt ist sie gefesselt von dem Drama, das sich vor ihren Augen abspielt.

Ein etwas gebeugt wirkender älterer Mann mit weißen Haaren und schiefem Lächeln betritt die Bühne und stellt sich neben Steve.

»Hallo zusammen. Es ist großartig, nach so vielen Jahren wieder hier vor Ihnen zu stehen. Ich sehe sogar einige bekannte Gesichter, was mich sehr glücklich stimmt. Für diejenigen unter Ihnen, die mich nicht kennen: Mein Name ist Bob Strauss. Ich war 15 Jahre lang CEO dieses Unternehmens, damals, als noch die Dinosaurier die Erde beherrschten. Und davor war ich bereits fast 30 Jahre lang Angestellter in diesem großartigen Unternehmen. Wie Steve erwähnt hat, habe ich ihn vor vielen Jahren mit großer Hoffnung und Stolz von einem anderen Unternehmen abgeworben.

Seit meiner Pensionierung war ich weiterhin im Board of Directors tätig. Die Aufgabe des Boards ist sehr einfach: die Interessen der Aktionäre des Unternehmens zu vertreten, zu denen auch fast alle von Ihnen gehören. Wir wollen sicherstellen, dass die Zukunft des Unternehmens gesichert ist. Wenn Sie eine Betriebsrente haben oder an unserem Aktienkaufplan für Mitarbeiter teilnehmen, ist das für Sie wahrscheinlich genauso wichtig wie für mich.

Wir tun dies in erster Linie, indem wir die Führungskräfte des Unternehmens zur Rechenschaft ziehen, indem wir den CEO einstellen und, äh, gelegentlich auch feuern«, sagt er ganz klar. Maxine hält kurz die Luft an – bis zu diesem Moment hat Bob eher wie ein freundlicher Großvater gewirkt. Aber offenbar gibt es da auch eine unnachsichtige Seite.

Allein der Blick auf den Aktienkurs zeigt, dass der Markt nicht glaubt, dass wir uns so gut entwickeln, wie wir es sollten. Wenn der Aktienkurs unseres Unternehmens sinkt, während der Aktienkurs unserer Konkurrenten steigt, muss sich etwas ändern.

Ich stelle mir gern vor, dass Unternehmen zwei Arten von Operationsmodi besitzen: eine für Friedens- und eine für Kriegszeiten. In Friedenszeiten laufen die Dinge gut. Das sind Zeiten, in denen wir als Unternehmen wachsen und unsere Geschäfte so führen können wie immer. In diesen Zeiten ist der CEO oft auch gleichzeitig Chairman of the Board. Aber wenn sich ein Unternehmen in der Krise befindet, wenn es schrumpft oder Gefahr läuft, völlig zu versagen, wie es jetzt bei uns der Fall ist, dann befinden wir uns im Krieg.

Im Krieg geht es nun im Wesentlichen darum, irgendwie der totalen Vernichtung zu entgehen. Und deshalb trennt ein Board in Kriegszeiten oft die Rollen von CEO und Chairman voneinander.« Bob hält inne, blinzelt in die hellen Lichter und lässt seinen Blick über das mucksmäuschenstille Publikum schweifen. »Ich möchte, dass jeder weiß, dass ich volles Vertrauen in Steve und seine Führungsqualitäten habe. Und wenn alles gut geht, werden wir einen Weg finden, wie wir ihm den Vorsitz wieder übertragen können, damit ich zurück in den Ruhestand gehen kann. Dahin, wo ich hingehöre.« Die Menge lacht nervös, als Bob winkt und seinen Abgang macht.

Steve tritt an die Vorderkante der Bühne und sagt: »Und eine Runde Applaus für Bob Strauss bitte.«

Nach einem gedämpften Beifall resümiert Steve: »Unsere diesjährigen Unternehmensziele betreffen die Stabilisierung unseres Geschäfts. Unser Fertigungsbereich, der zwei Drittel unseres Umsatzes ausmacht, stagniert, ist aber immer noch rentabel. Die Fertigung ist seit fast einem Jahrhundert die Hauptstütze unseres Geschäfts, und wir konnten uns gegen unsere sehr heftige asiatische Konkurrenz durchsetzen.

Unsere Einzelhandelsaktivitäten performen jedoch weiterhin unterdurchschnittlich. Unser Umsatz ist hier fast fünf Prozent niedriger als im vergangenen Jahr«, stellt er fest. »Unser wichtigstes Quartal kommt erst noch, also gibt es Hoffnung. Aber Hoffnung allein ist keine Strategie, und Sie haben ja gesehen, wie die Wall Street auf unsere bisherigen Leistungen reagiert hat. Ich bin jedoch weiterhin zuversichtlich, dass das Phoenix-Projekt uns helfen wird, uns an die neuen Marktbedingungen anzupassen.

Deshalb übergebe ich jetzt kurzerhand an Sarah Moulton, unsere Senior VP für den Einzelhandelsbereich, die erklären wird, warum das Phoenix-Projekt für die Zukunft des Unternehmens so wichtig ist.«

Sarah betritt die Bühne in einem auffallend schönen königsblauen Geschäftsanzug. Was auch immer Maxine von Sarah hält, sie muss zugeben, dass sie immer fabelhaft aussieht. Tatsächlich würde sie bestens auf die Titelseite von Fortune passen – intelligent, aggressiv und ehrgeizig.

»Wie Steve und Bob erwähnt haben«, beginnt Sarah, »befinden wir uns mitten in einer Digital Disruption, einer Zeit eines unglaublichen digitalen Bruchs im Einzelhandel. Sogar unsere Kunden bestellen online und per Telefon. Das Ziel des Phoenix-Projekts ist es, unseren Kunden die Möglichkeit zu geben, so zu bestellen, wie sie es wollen, ob online, in unseren Geschäften oder über unsere Vertriebspartner. Und über welchen Kanal auch immer sie bestellen, sie sollen die Möglichkeit haben, sich ihre Produkte nach Hause liefern zu lassen oder sie in einem der Geschäfte abzuholen.

Das ist es, worum es uns seit Jahren geht. Im Moment befinden sich unsere Läden noch im finsteren Mittelalter. Das war Parts Unlimited 1.0. Das Phoenix-Projekt macht daraus Parts Unlimited 2.0. Es gibt so viele Möglichkeiten, in der Konkurrenz mit den E-Commerce-Giganten effizienter zu werden, aber wir müssen dazu innovativ und agil sein. Damit wir relevant bleiben, müssen die Menschen uns als einen Marktführer betrachten, der neue Geschäftsmodelle entwickelt – was im ersten Jahrhundert unseres Bestehens funktioniert hat, funktioniert vielleicht nicht mehr in unserem zweiten.«

Wie immer hat das, was Sarah sagt, eine gewisse Gültigkeit, was Maxine zähneknirschend zugibt, aber Sarah kann so dermaßen herablassend sein.

»Das Phoenix-Projekt ist die aktuell wichtigste Initiative für unser Unternehmen, und unser Überleben hängt davon ab. Wir haben in den letzten drei Jahren fast 20 Millionen Dollar für dieses Projekt ausgegeben, aber die Kunden haben davon bisher noch nichts gehabt«, fährt sie fort. »Ich habe beschlossen, dass es für uns an der Zeit ist, endlich das Spielfeld zu betreten. Im Laufe dieses Monats werden wir das Phoenix-Projekt launchen. Keine Verzögerungen mehr. Keine Verschiebungen mehr.«

Maxine nimmt ein deutliches Keuchen des Publikums wahr, bevor ein lautes Brummen einsetzt, das Ergebnis vielfältigen, unruhigen Gemurmels in der Zuhörerschaft. Sarah fährt fort: »Damit sind wir endlich auf Augenhöhe mit der Konkurrenz und bereit, Marktanteile zurückzugewinnen.«

Maxine seufzt frustriert. Sie versteht die Dringlichkeit, aber das ändert nichts an der Tatsache, dass es über 100 Entwickler gibt, die bei Weitem nicht so produktiv sind, wie sie sein sollten, und die sich mit der (vergeblichen) Durchführung von Routine-Builds herumschlagen, zu viel Zeit in Meetings verbringen oder auf Dinge warten, die sie für ihre Arbeit brauchen. Sarahs Rede klingt wie die eines Generals, der einem erklärt, wie wichtig es sei, den Krieg zu gewinnen, bevor man dann herausfindet, dass alle Soldaten schon seit drei Jahren in irgendeinem Hafen festsitzen.

Immerhin hat Sarah heute nicht schon wieder einen völlig neuen Ansatz verkündet.

Steve bedankt sich bei Sarah und kommt dann schnell auf die Finanzen des Unternehmens sowie einen Betriebsunfall zu sprechen, der letzten Monat in einer der Produktionsstätten passiert ist. Er erzählt von Hannah, deren Finger von einer Stanzmaschine zerquetscht wurden, und dass diese Maschine durch eine neue ersetzt wurde, bei der ein Sensor verhindert, dass sich die Stempel schließen, wenn sich jemand im Gefahrenbereich befindet. Er lobt das Team dafür, dass es nicht darauf gewartet hat, bis dafür ein Budget beschlossen wurde: »Denken Sie immer daran, dass Sicherheit eine wesentliche Voraussetzung für erfolgreiche Arbeit ist.«

Maxine liebt diese Berichte und war immer beeindruckt und emotional bewegt davon, wie sehr Steve sich um die Sicherheit seiner Mitarbeiter kümmert.

Er kommt zum Ende: »Damit ist unser Bericht fast abgeschlossen. Wir haben noch rund 15 Minuten Zeit für Fragen und Antworten.«

Maxines Aufmerksamkeit schweift ab, als die Mitarbeiter Fragen an Steve richten zur Umsatzprognose, der Performance der Einzelhandelsgeschäfte, zu den jüngsten Problemen in der Produktion … Aber als jemand nach dem Payroll-Problem fragt, schreckt sie hoch, bevor sie sich gleich wieder tief in ihren Sitz verkriecht, während sie sich anstrengt, akustisch alles zu verstehen.

»Ich entschuldige mich bei allen, die davon betroffen waren«, antwortet Steve. »Mir ist klar, wie unangenehm das für alle Leidtragenden war, und ich versichere Ihnen, dass wir sehr konkrete Maßnahmen ergriffen haben, um sicherzustellen, dass dies nie wieder geschieht. Es war eine Kombination aus technischen Problemen und menschlichem Versagen, und wir glauben, dass wir beides behoben haben.«

Maxine schließt die Augen, fühlt, wie sich ihre Wangen leuchtend rot färben, und hofft, dass sie niemand anschaut. Sie versteht nicht, wie ihre Versetzung ins Exil des Phoenix-Projekts in irgendeiner Form als Abhilfe betrachtet werden kann.