- Unternehmen geben viel Geld aus, um zu operativen Fähigkeiten wie Toyotas Fertigungskompetenz, Six-Sigma-Qualität oder Dells Lieferkette aufzuschließen, doch Verbesserungsprogramme führen nur selten zu nachhaltiger Performance
- TQM ist ein Beispiel dafür, wie eine Methode einst breit eingesetzt und dann rasch verdrängt wurde: Weniger als 10 % der Fortune 1000 verfügten über ein gut entwickeltes TQM-Programm
- Die Ursache des Scheiterns liegt weniger in der Wahl eines bestimmten Tools als darin, wie ein neues Programm mit physischen, wirtschaftlichen, sozialen und psychologischen Strukturen zusammenspielt; Verbesserung wird letztlich zu einem Systemproblem
- Wenn Performance-Lücken größer werden, wählen Organisationen zwischen Work Harder, also länger arbeiten, und Work Smarter, also Fähigkeiten aufbauen; Letzteres wird wegen Verzögerungen und Fehlerrisiken leicht verdrängt
- Shortcuts, die Verbesserungszeit verkürzen, sind attraktiv, weil sie kurzfristig den Output steigern; häufen sich jedoch spät sichtbar werdende Fähigkeitsverluste an, können sie eine Organisation in eine Capability Trap führen
Das Paradox scheiternder Verbesserungsprogramme
- Unternehmen investieren aktiv in Prozessverbesserungen, um operative Fähigkeiten in Bereichen wie Fertigung, Qualität, Kundenverständnis und Supply-Chain-Management zu entwickeln
- 1997 gaben US-Unternehmen zusammen mehr als 100 Mrd. US-Dollar für Managementberater und Schulungen aus; ein erheblicher Teil davon floss in den Versuch, zu den operativen Fähigkeiten führender Unternehmen aufzuschließen
- Trotz einiger spektakulärer Erfolge erzielen viele Verbesserungsprogramme keine nennenswerten Ergebnisse
- TQM zeigt dieses Paradox besonders deutlich
- Angeregt durch den Erfolg japanischer Unternehmen in den 1980er-Jahren wurde TQM unter US-Unternehmen sehr populär
- Mitte der 1990er-Jahre ließ das Interesse in Wissenschaft und Wirtschaftspresse nach, und TQM wurde von neuen Innovationen wie Re-engineering verdrängt
- Unternehmen, die sich ernsthaft den Disziplinen und Methoden von TQM verschrieben, erzielten eine höhere Performance als ihre Wettbewerber
- In einer Studie hatten weniger als 10 % der Fortune 1000 ein gut entwickeltes TQM-Programm
- In einer anderen Studie war TQM 1993 das am dritthäufigsten eingesetzte Business-Tool, fiel bis 1999 jedoch auf Platz 14 zurück
- Frühere Verbesserungsmethoden tauchen teils unter neuem Namen wieder auf
- Die Kerndisziplinen der statistischen Prozesskontrolle und der Reduzierung von Variation leben in Six Sigma weiter
- Quality Circles werden wieder als High-Performance Work Teams bezeichnet
Schwieriger als die Tools ist die Implementierungsstruktur
- Tools und Methoden zur Performance-Verbesserung haben sich schnell vermehrt; durch Informationstechnologie und die wachsende Zahl von Beratern ist es zudem leichter geworden zu erfahren, welche Methode von wem eingesetzt wird
- Für die meisten Manager besteht die größere Hürde nicht darin, neue Methoden zu kennen, sondern sie erfolgreich im Arbeitsalltag zu implementieren
- Fähigkeiten wie ein Six-Sigma-Qualitätsprogramm lassen sich nicht wie ein schlüsselfertiges Produkt kaufen, sondern müssen innerhalb der Organisation entwickelt werden
- Über rund zehn Jahre wurden mehr als 12 vertiefende Fallstudien in den Branchen Telekommunikation, Halbleiter, Chemie, Öl, Automobil und Freizeitprodukte durchgeführt
- Dabei wurden Beobachtungen, Interviews mit Beteiligten, Archivmaterial und quantitative Kennzahlen genutzt
- Zusätzlich wurden Modelle entwickelt, um die Dynamik von Implementierung und Verbesserung zu erfassen
- Dass die meisten Organisationen den Nutzen von Verbesserungsinnovationen nicht vollständig realisieren, hat kaum mit der Wahl eines bestimmten Verbesserungstools zu tun
- Neue Verbesserungsprogramme wirken an Stellen, an denen Tools, Anlagen, Mitarbeitende, Manager sowie physische, wirtschaftliche, soziale und psychologische Strukturen ineinandergreifen; dadurch werden sie zu einem systemischen Problem
Die grundlegende Physik der Verbesserung: Zeit und Fähigkeiten
- Die tatsächliche Performance eines Prozesses wird durch die für Arbeit aufgewendete Zeit (Time Spent Working) und die Prozessfähigkeit (Capability) bestimmt, mit der diese Arbeit ausgeführt wird
- In der Fertigung ergibt sich der netto nutzbare Output aus dem Produkt von täglicher Arbeitszeit und Produktivität, also dem nutzbaren Output pro Arbeitsstunde
- Performance lässt sich erhöhen, indem man mehr arbeitet oder mehr in Verbesserung investiert; die Ergebnisse beider Ansätze unterscheiden sich jedoch
- Wenn die Wochenarbeitszeit um 20 % steigt, kann der Output um 20 % steigen, solange die Überstunden anhalten
- Verbesserungen der Prozessfähigkeit erhöhen den Output aller später eingebrachten Arbeitsstunden
- Überstunden zur Nacharbeit fehlerhafter Produkte erhöhen den Output nur, solange weiter Überstunden geleistet werden; das Beseitigen der Ursachen von Fehlern senkt hingegen dauerhaft den Bedarf an Nacharbeit
- Fähigkeit wird als Bestand (stock) behandelt, der sich im Zeitverlauf aufbaut
- Zeit, die für Verbesserung eingesetzt wird, erhöht die Investition in Fähigkeiten
- Da es Zeit braucht, Grundursachen zu finden sowie Lösungen zu entdecken, zu testen und zu implementieren, gibt es eine Verzögerung zwischen Verbesserungsaktivitäten und Veränderungen der Fähigkeiten
- Durch Maschinenverschleiß, Prozessdrift, veraltende Designs und überholte Verfahren nehmen Fähigkeiten ab, wenn sie nicht regelmäßig gepflegt werden
- Die Verzögerung von Verbesserungen hängt von der technischen und organisatorischen Komplexität des Prozesses ab
- Bei relativ einfachen Prozessen, etwa der Maschinenausbeute in einem Job Shop, liegen Verbesserungsverzögerungen im Bereich einiger Monate
- Bei komplexen Prozessen wie der Produktentwicklung können Verbesserungsverzögerungen mehrere Jahre oder länger betragen
- In Organisationen mit hoher Änderungsrate bei Produkten und Personal ist auch die Lebensdauer verbesserter Fähigkeiten kürzer
Die Spannung zwischen Work Harder und Work Smarter
- Das Management legt Ziele wie Kundennachfrage, Durchsatz bei der Bearbeitung von Versicherungsansprüchen oder die Zahl vierteljährlich veröffentlichter neuer Produkte als Desired Performance fest
- Die Differenz zwischen tatsächlicher Performance und Ziel wird zur Performance Gap; in den untersuchten Organisationen waren Prozesse, die die Erwartungen übertrafen, selten zu finden
- In Organisationen, die zusätzliche Ressourcen oder Neueinstellungen scheuen, gibt es zwei grundlegende Optionen, um eine Performance-Lücke zu schließen
-
Work-Harder-Schleife
- Manager erhöhen bei einer Performance-Lücke den Arbeitsdruck, etwa durch höheres Arbeitstempo, Überstunden, aggressivere Ziele oder Strafen bei Zielverfehlung
- Auch subtilere Faktoren wie Häufigkeit von Performance-Reviews, Detailgrad der Reviews und Hierarchieebene der prüfenden Personen gehören zum Arbeitsdruck
- In einem Unternehmen überprüfte ein Senior Vice President die Performance einzelner Maschinen in der Fabrikhalle; das wurde als Botschaft verstanden, die Maschinen um jeden Preis weiterlaufen zu lassen
- Als der Zeitplan für ein Subsystem eines Projektmanagers in Verzug geriet, musste dieser stündliche Statusberichte per Telefon liefern, bis der Prototyp die Spezifikationen erfüllte
-
Work-Smarter-Schleife
- Manager können versuchen, die Prozessfähigkeit zu erhöhen, indem sie Verbesserungsprogramme starten, Experimente mit neuen Ideen fördern und in Schulungen investieren
- Gelingt dies, verbessern sich mit der Zeit die Fähigkeiten, der Durchsatz steigt und die Performance-Lücke schrumpft
- Investitionen in Verbesserung können langfristig eine größere Wirkung haben, doch bis sich Effekte zeigen, gibt es erhebliche Verzögerungen; zudem besteht das Risiko, dass die Suche nach Grundursachen oder die Anwendung neuer Tools scheitert
- Bei dringenden Problemen wird häufig Work Harder gewählt
- Wenn eine Fertigungslinie für einen wichtigen Kunden stillsteht, ist es für Manager naheliegender, die Linie wieder anzufahren und Überstunden bis zum Ende der Auslieferung durchzusetzen, als Schulungen zur Zuverlässigkeitsverbesserung anzusetzen
- Wenn man nach der Ad-hoc-Reaktion nicht zu Verbesserungsaktivitäten zurückkehrt, wird härteres Arbeiten zum Standard Operating Mode
Reinvestitionsschleife und Capability Trap
- Da Organisationen kaum freie Ressourcen haben, reduzieren Menschen bei steigendem Arbeitsdruck nicht arbeitsbezogene Aktivitäten wie Pausen und machen mehr Überstunden
- Überstunden von Wissensarbeitern sind oft unbezahlt und reichen bis in Nächte und Wochenenden, wodurch Zeit für Familie und Gemeinschaftsaktivitäten verloren geht
- Wenn sich die verfügbare Zeit nicht weiter ausweiten lässt, bleibt nur, die Verbesserungszeit zu reduzieren, um die weiter wachsende Performance-Lücke zu schließen
-
Reinvestitionsschleife
- Wenn Investitionen in Verbesserung erfolgreich sind, steigt die Performance, die Performance-Lücke schrumpft und mehr Zeit kann für Verbesserung eingesetzt werden; so entsteht ein positiver Kreislauf
- Reagiert man auf eine Durchsatzlücke dagegen mit Arbeitsdruck, sinkt die Verbesserungszeit, Fähigkeiten verfallen und die Performance-Lücke wächst weiter; daraus entsteht ein Teufelskreis aus noch stärkerem Arbeitsdruck und noch weniger Verbesserung
- In erfolgreichen Verbesserungsfällen wurden die durch Produktivitätssteigerungen frei gewordenen Ressourcen ausdrücklich wieder Verbesserungsaktivitäten zugewiesen, um den Reinvestitionsprozess zu stärken
- In vielen Organisationen führen Kosten- und Termindruck zu Downsizing oder höheren Performance-Zielen, entziehen der Verbesserung Ressourcen und lassen Fähigkeiten stagnieren oder sinken
-
Shortcuts-Schleife
- Abkürzungen wie das Auslassen von Verbesserungsmeetings, das Verschieben geplanter vorbeugender Wartung oder das Ignorieren von Dokumentationsanforderungen erhöhen unmittelbar die Arbeitszeit
- Da der Fähigkeitsverlust nicht sofort sichtbar wird, erscheinen Shortcuts kurzfristig wirksam und attraktiv
- Ein Manager, der vorbeugende Wartung aufschiebt, gewinnt eine Schonfrist, in der geplante Ausfallzeiten vermieden und Wartungskosten gespart werden; später sinken jedoch durch Alterung und Verschleiß der Anlagen Ausbeute und Verfügbarkeit
- Ein Software Engineer, der auf Dokumentation verzichtet, kann das Projekt rechtzeitig abschließen, zahlt den Preis aber Wochen oder Monate später, wenn in Tests gefundene Bugs behoben werden müssen
-
Capability Trap
- Work Harder erhöht anfangs unmittelbar den Gesamtdurchsatz, während die Kosten geringerer Verbesserungszeit erst später sichtbar werden; dadurch entsteht eine better-before-worse-Situation
- Work Smarter senkt kurzfristig den Output, hat aber eine worse-before-better-Dynamik: Mit der Zeit gleicht der Anstieg der Fähigkeiten den geringeren Arbeitseinsatz aus und erhöht die Performance
- Das Zusammenspiel von Shortcuts und Reinvestment kann eine Capability Trap erzeugen, die Organisationen in einem Teufelskreis sinkender Fähigkeiten festhält
2 Kommentare
Kommentare auf Hacker News
Meine Erinnerung ist etwas verschwommen, aber es gibt ein gutes Beispiel.
In einer Organisation gab es eine wichtige Auftragsverarbeitung, bei der man nicht davon ausgehen konnte, dass alle nötigen Informationen vollständig oder korrekt eintreffen. Also wurde Validierungslogik gebaut, die Eingaben bereinigte und die Verarbeitung anpasste, und es wurden Metriken dazu erfasst, welche Validierungen bei jedem Auftrag getriggert wurden. Wenn eine neue Validierung hinzukam, wurde auch das Datum vermerkt.
Weil diese Metriken veröffentlicht und gelegentlich geteilt wurden, konnte man, wenn jemand fragte: „Was passiert bei XYZ?“, antworten: „Das ist bereits abgedeckt, und wir haben verhindert, dass wegen XYZ #### Aufträge blockiert werden.“
Dadurch wurde sichtbar, dass das Team sorgfältig arbeitete, dass solche Arbeit nötig ist, damit das System dauerhaft gut läuft, und dass man das mit Daten belegen kann. Das veränderte die Gespräche in der Organisation von „Warum habt ihr daran nicht gedacht?“ zu „Was tun wir als Nächstes?“, und die Anerkennung für präventive Qualität wanderte auch nach oben.
Die meisten Teams hätten wohl nur auf Metriken wie die Erfolgsquote bei Aufträgen geschaut und es dabei belassen. Wenn man aber die Anzahl der verarbeiteten fehlerhaften Datensätze als Metrik nimmt, entkommt man der Falle, dass gute Arbeit unsichtbar bleibt.
Ich habe kürzlich am Arbeitsplatz genau dasselbe erlebt.
Als Tech Lead/Architekt der Organisation habe ich kürzlich veröffentlichte Projekte überprüft und Stellen gefunden, die wegen schwerwiegender Zuverlässigkeits-/Performance-Probleme unbedingt verbessert werden mussten. Mehrere Releases eines Teams standen ganz oben auf der Liste, aber der PM und der Engineering Manager dieses Teams sowie die höheren Ebenen ignorierten alle Bedenken mit der Begründung, Feature-Updates hätten Vorrang.
Ein paar Monate später, während ich im Urlaub war, krachte es: Es gab eine Sev-1-Eskalation, mehrere Kunden waren verärgert, und sogar CEO/CTO wurden einbezogen. Genau das Team, das den schlampigen Code geschrieben und die Warnungen ignoriert hatte, arbeitete Tag und Nacht, um den Dienst wiederherzustellen, und jetzt sind sie die Helden. Insbesondere der Manager hat im Unternehmen an Ansehen gewonnen, weil er während des Ausfalls aktiv kommunizierte und Führungsstärke zeigte.
Beeindruckender ist es, Probleme zu beheben, die andere verursacht haben. Ich möchte jemanden nicht mit Lob überschütten, weil er seinen eigenen Fehler behoben hat, und ich erwarte auch kein Lob, wenn ich meinen eigenen Fehler behebe. Ich würde mich zuerst bei allen dafür entschuldigen, dass ich es überhaupt verbockt habe.
Die Frage aus dem Titel lässt mich immer wieder über meinen eigenen Wert nachdenken.
Wenn ich jemandem in 40 Minuten bei etwas helfe, woran er drei Monate festhing, ist mein Wert für alle offensichtlich. Wenn ich aber die ganze Zeit mitarbeite und dadurch niemand drei Monate lang festhängt, ist mein Wert unklar. Ich weiß nicht, wie man mit diesem Paradox umgehen soll.
Wenn man mehr Aufwand und Zeit investiert, bleibt die Belohnung oft zurück, während noch mehr Aufwand und Zeit erwartet werden. Wert und Chancen sind im Verhältnis zu Aufwand und Zeit eher ein chaotischer Prozess.
Am Ende sollte man versuchen, die Arbeitslast so zu halten, dass der Kopf klar genug bleibt, um Chancen zu ergreifen, wenn sie auftauchen. Ehrliche, ausgeglichene Kolleginnen und Kollegen helfen dabei, aber letztlich ist es etwas, das man selbst tun muss.
Selbst wenn der eigene Chef versucht, das zu erklären, kann es sein, dass beim nächsten Stellenabbau der eigene Kopf rollt.
Sie erzählten zwar anderen Firmen, dass ich gut in solchen Dingen sei, aber daraus ergab sich nichts. Das war mein erster und letzter Tag als Auftragnehmer für kleine Unternehmen.
Dadurch wird die Moral im Team nicht untergraben. Teammitglieder brauchen psychologisch die Anerkennung ihres individuellen Beitrags.
Solche Vorgesetzten waren oft selbst fähige Individual Contributors, bevor sie Team Leads wurden, und weil sie das Fach selbst beherrschen, sind sie am besten in der Lage, die Individual Contributors zu beurteilen, die sie managen.
Man sollte die vermiedenen Katastrophen so anschaulich schildern, dass die Leute ein klares Bild vor Augen haben.
Eine weitere Variante besteht darin, übermäßig viele Ressourcen darauf zu verwenden, ein Problem zu verhindern, das tatsächlich einmal aufgetreten ist, während man sich weniger um schwerwiegendere Probleme kümmert, die noch nicht eingetreten sind.
Das ist ein Managementproblem. Denn selbst wenn es vernünftig gewesen wäre, etwas anderes, Wichtigeres zu tun, will niemand verantwortlich sein, wenn sich derselbe Vorfall wiederholt.
Eine kleine Wunde wird durch eine harte, unflexible Organisation ersetzt. Nur weil etwas einmal passiert ist, muss man nicht zwingend alles so ändern, dass es nie wieder passieren kann; eine solche Überreaktion kann in Zukunft zu einer großen Belastung werden.
Es kann besser sein, den Verlust hinzunehmen und anzuerkennen, dass er erneut eintreten könnte, als ihn mit übertriebener Vorsorge unbedingt verhindern zu wollen.
Eine Politik, Präventionsressourcen erst dann zuzuweisen, wenn tatsächlich etwas passiert ist, ist bis zu einem gewissen Grad vernünftig.
Ich habe ein elendes Jahr damit verbracht, Leute davon zu überzeugen, dass wir auf einen Ausfall überreagieren und dass es für das tatsächlich aufgetretene Problem eine sehr einfache Lösung gibt. Wenn für einen Senior Manager wegen einer Wiederholung aber der eigene Posten gefährdet aussieht, weist er die gesamte Abteilung an, Code auf ähnliche Probleme zu prüfen und zu korrigieren. Und seltsamerweise hört man dann auf die lautesten Stimmen, die eine extrem überentwickelte Lösung vorschlagen.
Ein anderes Mal fiel wegen eines abgelaufenen Passworts der Trading-Stack aus. Der Aufwand, der in eine lächerlich komplizierte, selbst gebaute Lösung gesteckt wurde, um dafür zu sorgen, dass das „nie wieder passiert“, war absurd. Nach mehr als einem Jahr Arbeit wurde schließlich alles verworfen und durch die viel einfachere zentrale Lösung ersetzt, die man von Anfang an hätte bauen sollen.
Das erinnert mich an eine frühere Arbeitsstelle. Jedes Mal, wenn ich um Feedback bat, wurde wiederholt: „Hier wird ohne PIR (post-incident response) nichts priorisiert.“
Gegen Ende markierte ich bei PIR-Tickets den jeweiligen Vorfall als Duplikat des eigentlichen Tickets, das ihn hätte verhindern können, aber im Backlog vor sich hin starb. Dass wir in unserem Zuständigkeitsbereich keinerlei Einfluss darauf hatten, vorhersehbare Probleme zu verhindern, hat die Moral im Team stark beschädigt.
Die meisten Teammitglieder hörten ganz auf, Verbesserungsvorschläge zu machen. Das Management erlaubte uns nämlich nicht, Tickets eigenständig hereinzuziehen.
Das beschreibt sehr gut, in welche Hölle sich unternehmensmäßiges Scrum verwandelt.
Agile bedeutete wörtlich, schnell zu arbeiten und Fähigkeiten in schnellen Zyklen zu verbessern. Scrum ist jedoch zu einer schlechteren Version des Planungsprozesses geworden, den es ersetzen sollte.
Die Art, wie Scrum Arbeit in unmittelbar vor einem liegende Probleme zerlegt, verschlimmert diesen Kreislauf eher noch. Langfristig wird es zu einem Ticketsystem, in dem Brände nach oben geschoben werden und technische Schulden nach unten.
Außerdem spuckt es leicht nachverfolgbare, aber bedeutungslose Effizienzzahlen aus, mit denen Consultants und Führungskräfte Optimierung spielen können.
Ich darf das sagen. Einige meiner besten Freunde sind Scrum Master.
Ich verstehe, warum das so ist. Unter den vielen Dingen, die man tun könnte, muss jemand entscheiden, was getan wird. Wird dieses Feature Geld einbringen? Was ist mit Arbeit, die kein Feature ist, aber Ressourcenkosten senkt? Was ist mit technischen Schulden, die die Geschwindigkeit der Feature-Auslieferung bremsen?
Ich bin kein Senior Manager, aber irgendjemand weiter oben ist letztlich dafür verantwortlich, dass das Unternehmen überlebt, Geld verdient und unsere Gehälter zahlt. Auch diese Leute müssen mit den wenigen Informationen entscheiden, die sie bekommen können, genau wie wir. Deshalb brauchen sie eine Möglichkeit, „Was kostet das und welchen Wert hat es?“ mit „Was kostet jenes und welchen Wert hat es?“ zu vergleichen.
Man brauchte eine Methode, das zu schätzen, und als die Tech-Branche Agile als dieses Mittel vermarktete, klammerte man sich daran. Wessen Schuld ist das?
Daraus folgten häufige Schätzungen, Terminverfolgung und Rituale. Manche glauben nicht, dass das zwangsläufig daraus folgen muss, und ich stimme dem zu. Trotzdem wurden diese Rituale Teil des Kults.
Wir haben Scrum aufgegeben, ebenso Refinement-Meetings, Story-Schätzungen und Story Points. Jetzt treffen wir uns einmal im Monat formell mit dem PM und betrachten auf Teamebene nur per T-Shirt-Größenschätzung, wo wir stehen. Ansonsten geben wir Updates, wenn der PM danach fragt oder wenn wir es für nötig halten. Dadurch liegt die Autorität bei uns, aber entsprechend tragen wir auch Verantwortung und geben rechtzeitig Bescheid, wenn die Lage unsicher aussieht. „Schätzen“ müssen wir weiterhin. Schließlich müssen Senior Manager Entscheidungen treffen. Insgesamt ist es aber ziemlich schlank und fühlt sich wirklich befreiend an.
Alle waren dem Prozess verpflichtet, und das Scrum-Team priorisierte 20 % des Aufwands für den Abbau von Schulden. Die jeweilige Velocity war ebenfalls ziemlich genau, sodass zusätzlich 20 % für persönliche Interessenarbeiten berücksichtigt werden konnten, und die Prioritäten der Stakeholder füllten die übrigen 60 %.
In manchen Sprints änderte man die Richtung, wenn man nachlegen musste, um ein Epic oder Teamziel abzuschließen, oder wenn Notfälle/Bugs eine Umpriorisierung erforderten.
Jede Menge Prozess hinzuzufügen, nur weil man Prozess hinzufügen will, schafft keinen Wert.
Das erinnert mich an diesen Comic, den ich im Büro hängen hatte: https://naksecurity.medium.com/the-detriments-of-hero-cultur...
Deshalb ist es in vielen Unternehmenskulturen karriereförderlicher, ein Problem nicht proaktiv zu verhindern, wenn es nicht im eigenen unmittelbaren Zuständigkeitsbereich liegt, selbst wenn man weiß, wie man es beheben könnte. Man lässt das Problem sichtbar werden, wartet, bis es zum Notfall von jemandem wird, und behebt es dann.
Natürlich kann eine solche Organisation langfristig nicht gut funktionieren, also sollte man auch planen zu gehen.
„Niemand bekommt Anerkennung dafür, ein Problem behoben zu haben, das nie eingetreten ist“ (2001) [PDF] kommt mir in den Sinn
Daran muss ich jedes Mal denken, wenn YouTuber oder Social-Media-Clickbait behaupten, der Y2K-Bug sei keine große Sache gewesen
Der Grund, warum es keine große Sache war, ist, dass zahllose Veteranen wie ich schon Monate vorher Nächte durchgemacht haben, damit alles funktioniert
Ich erinnere mich noch an die Anspannung beim Countdown zu Mitternacht UTC. Dann wieder beim Countdown für Eastern Time, und zur lokalen Zeit noch einmal. Erst als die Pazifikzeit im Jahr 2000 angekommen war, konnte ich endlich durchatmen
Das werden wir 2038 herausfinden
Aus derselben Zeit ist auch Y2K ein sehr gutes Beispiel. Sichtbar passiert ist kaum etwas, aber wenn die Leute es einfach ignoriert hätten, wäre wahrscheinlich eine Menge passiert
Nicht, weil mein Gehalt davon abhing. Es gab natürlich genug andere Arbeitsmöglichkeiten. Es war ein Problem, das die Energiebranche tatsächlich hätte lahmlegen können und große Unternehmen samt unzähligen abhängigen Organisationen betroffen hätte. Nach dieser Erfahrung gehe ich davon aus, dass mehrere Branchen wie Finanzwesen oder Rohstoffförderung direkt oder indirekt ähnlich getroffen worden wären
Deshalb ist es ein gutes Beispiel. Ich treffe immer noch Leute, die Y2K als Aufregung um nichts in Erinnerung haben. War es nicht. Dass es für dich kein Problem war, lag daran, dass viele Menschen hart daran gearbeitet haben, es zu verhindern
Die Probleme waren nicht extrem kompliziert, aber weit verbreitet, wichtig und erforderten eine Menge Arbeit. Es war weniger ein Mondlandungs-Engineering-Problem, das man als Menschheitsleistung herausstellen würde, sondern eher so, als würde man vor der Explosion massenhaft dumme Challenger-O-Ring-Probleme beheben
Deshalb blieben am Stichtag nur noch ein paar kleinere Restbugs übrig. In den Zeitungen gab es ein paar Witze, aber die Öffentlichkeit ging im Großen und Ganzen einfach darüber hinweg
Ich arbeite im Klimabereich und hatte gehofft, beziehungsweise hoffe immer noch, dass dasselbe passiert. Aber es sieht so aus, als würde es bald zwangsläufig die Aufmerksamkeit aller auf sich ziehen
Wenn man vorbereitet ist, passiert nichts Interessantes, das Leben geht weiter, und die Leute erinnern sich daran, dass jemand einen Laptop aufgeklappt und ein paar Tasten gedrückt hat
Wenn man nicht vorbereitet ist, friert das texanische Stromnetz ein, Menschen sterben, verlieren ihre Ersparnisse, und es heißt: „Niemand hätte sich vorstellen können, dass es so schlimm wird“
Ich gebe zu, ich war an dieser Arbeit beteiligt. Das Lustige ist, dass ich zu einem früheren Kunden zurückgerufen wurde und ein Problem behoben habe, das meine frühere Arbeit buchstäblich verursacht hatte. Sobald ich es sah, hatte ich es in 20 Minuten repariert. Dann kam: „Wenn Sie schon hier sind, könnten Sie sich das auch noch ansehen …“, und das ging etwa zwei Jahre so weiter, bis die Abteilung geschlossen und nach New York verlegt wurde
Zumindest wurde es als abrechenbare Zeit anerkannt
Da dieser Text direkt danach geschrieben wurde, dachte ich, es ginge um Y2K
In den späten 90ern habe ich einige Jahre an Y2K-Projekten gearbeitet und geholfen, dafür zu sorgen, dass kritische Infrastruktur im Vereinigten Königreich um Mitternacht nicht stehenbleibt. Ohne unsere Anstrengungen hätte Wales zum Beispiel kein Wasser oder Gas gehabt
Danach hörte ich dann Dinge wie: „Es ist doch nichts passiert, also war es offensichtlich kein Problem — warum hat man so viel Geld für Y2K ausgegeben?“ oder „Y2K war ein Betrug der IT-Branche“
Wir haben gewonnen. Wir haben den Y2K-Bug erfolgreich verhindert, es war harte Arbeit, und wir waren uns bis Mitternacht nicht einmal sicher, ob wir alles erwischt hatten. Aber statt gefeiert zu werden, sahen manche das als Beweis dafür, dass wir überteuert abkassiert hatten. Menschen sind seltsam
Das Nervige ist, dass das Best-Case-Szenario beim Klimawandel genauso aussieht. Wenn es uns tatsächlich gelingt, die Apokalypse zu vermeiden, werden sich alle „Klimawandelleugner“ bestätigt fühlen
Hacker-News-Kommentare
Beim Titel fällt mir eine interessante altchinesische Anekdote ein. Dass Toyota kürzlich in einen Skandal verwickelt war, ist auch ein wenig ironisch: https://www.bbc.com/news/articles/c1wwj1p2wdyo
Als König Wen von Wei Bian Que fragte: „Wenn alle drei Brüder Ärzte sind, wer ist dann der beste?“, antwortete Bian Que: „Mein ältester Bruder ist der beste, mein zweiter Bruder kommt danach, und ich bin der schlechteste.“
Der älteste Bruder erkennt eine Krankheit, bevor sie überhaupt Gestalt annimmt, und beseitigt sie unbemerkt, daher ist sein Name nur in der Familie bekannt. Der zweite Bruder behandelt sie, wenn sie sich gerade erst zu zeigen beginnt, daher reicht sein Ruf nicht über die Gassen des Dorfs hinaus. Bian Que selbst hingegen sticht in Blutgefäße, setzt starke Medikamente ein und schneidet ins Fleisch, und gerade wegen dieser sichtbaren Handlungen wurde er unter den Fürsten berühmt.
Ich habe ein Unternehmen erlebt, in dem die „leidende Abteilung“ im nächsten Quartal Lob und mehr Budget bekam, weil sie Probleme, die sie selbst verursacht hatte, heroisch wieder eingefangen hat
Währenddessen hatte meine Abteilung, die still und zuverlässig funktionierte, schon Mühe, überhaupt das Licht anzulassen
Die Kluft zwischen nichttechnischen Führungskräften, die gerade so einen Doppelklick verstehen, und dem Engineering, das die Firma tatsächlich trägt, ist in dieser Branche ein ernstes Problem. Außer dass das Management selbst aus dem Engineering kommen müsste, fällt mir keine gute Lösung ein
Manche Probleme sollten erst ein Schmerzsignal nach oben senden, bevor sie behoben werden, damit die Führung daraus lernen kann
Allerdings ist das Design der Anreize schwierig, und die Struktur darf nicht dazu führen, dass das Top-Management Untergebene und Abteilungen dazu bringt, Schmerz und Probleme nicht sichtbar zu machen. Viele verdecken Signale auch in guter Absicht, daher muss man in großen Organisationen wohl vermitteln, dass es effizienter sein kann, manche Probleme sich entfalten zu lassen und nicht zu reaktiv zu handeln
Während alle unter normalen Bedingungen und perfektem Betrieb entwerfen, ist jemand wichtig, der herausfindet, wie man Design, Services, Infrastruktur und Apps kaputtmachen kann
Ein Kollege aus der IT hätte etwas mehr als 2.000 Euro bekommen können, wenn er kommerzielle Zertifikate durch Let’s Encrypt ersetzt und die EV-Anforderung entfernt hätte, bekam das Geld am Ende aber nicht. So etwas sei schließlich „Teil der normalen Arbeit“
Die Teams, die tatsächlich funktionierende Services gebaut hatten, bekamen eingefrorene Budgets und wurden sogar verkleinert
Wenn es bei anderen Teams kracht, kann unser Team anhand der Liste abgeschlossener Arbeiten zeigen, warum wir nicht dasselbe Problem hatten. Die Arbeit wurde bereits gemacht, nur zu einem besseren Zeitpunkt, an dem sich Downtime vermeiden ließ
Das passiert oft. Besonders gefällt mir daran, dass elegante Lösungen im Nachhinein meist einfach wirken
Wenn man lange grübelt, dann eine clevere Lösung findet und sie erklärt, reagieren andere mit „Ja klar, logisch“
Die Person am Nebentisch, die das Problem unnötig verkompliziert hat, wird dagegen dafür gelobt, etwas so Schwieriges gebaut zu haben
Große Unternehmen mögen noch immer darin hinterherhinken und Komplexität bewundern, aber aus der Perspektive von Menschen, die direkt oder indirekt AI-Output entgegennehmen, wirkt Komplexität nicht mehr so beeindruckend wie früher
Bei fast wundersamen Reparaturen erzählen sie dann eher Geschichten wie „mein Neffe hat ein kleines Problem sofort gelöst“, was sich so anfühlt, als würden sie gerade hervorheben, dass ich das nicht getan habe
Der Verantwortliche habe zu der komplizierten Variante geraten, weil sie so eher veröffentlicht werde. Nicht weil sie klüger sei, sondern weil eine Lösung komplex klingen müsse, um anerkannt zu werden
Das trifft genau den Punkt, dass in der Realität komplexe Prozesse mehr Lob bekommen als schöne Lösungen, und vermutlich ist auch Bürokratie auf diese Weise entstanden
Der Code war 15 Minuten nach dem Release vergessen und wurde nie wieder gelesen, lief aber über Jahre weiter. Deshalb glaube ich, dass AI Jobs viel schneller übernehmen könnte, als viele denken
Dinge wie sauberer Code, Separation of Concerns und Wartbarkeit, in die wir die meiste Zeit investieren, wurden in Wirklichkeit nie bewertet. Wenn es „gut genug“ ist, sind Manager zufrieden, und wenn Probleme auftauchen, kann AI auch eine Spaghetti-Lösung daraufpatchen
In einem früheren Job hatte ich ein ähnliches Problem. Ich habe fast meine ganze Zeit für administrative Arbeit im Hintergrund aufgewendet, etwa um Meetings zu terminieren und sicherzustellen, dass die Leute vor dem Meeting die nötigen Informationen hatten.
Bei der Leistungsbeurteilung hieß es dann aber nur, wichtig sei, dass ich nicht viele Story Points abgeschlossen hätte, weil ich zu beschäftigt damit gewesen sei, alles am Laufen zu halten.
Also habe ich die gesamte administrative Arbeit eingestellt und mich nur noch darauf konzentriert, Story Points abzuschließen, und 1–2 Wochen später fragte mein Manager das Team: „Warum laufen alle Meetings komplett schief? Wenn man in ein Meeting geht, weiß niemand, worum es überhaupt geht.“
Wegen Y2K habe ich fast zwei Jahre lang extrem viel an Netzwerken, Hardware und IT gearbeitet und bin danach in das Marketing gewechselt. Am Ende hielten fast alle Unternehmen diese Zeit und dieses Geld für verschwendet, „weil ja nichts passiert ist“.
Ein Unternehmen verlangte sogar eine vollständige Rückerstattung, und als ich sagte, ich würde erstatten, wenn ich meine Arbeit rückgängig machen dürfe, stimmten sie zu. Am nächsten Tag brach das gesamte System des Unternehmens zusammen.
Auch die Netzwerkbetreuung für die Firma meines Vaters war schwer zu übernehmen, weil er meine Gebühren auf keinen Fall zahlen wollte. Nachdem zwei andere Leute das Problem nicht lösen konnten, habe ich es in 15 Minuten behoben, woraufhin er noch weniger zahlen wollte, weil es ja nur 15 Minuten gedauert hatte.
Die Fähigkeit, Dinge davor zu bewahren kaputtzugehen, wurde nicht anerkannt, nur das Reparieren, nachdem sie kaputt waren. Marketing war besser bezahlt, und ich konnte mein Gehalt jeden Tag mit echten Zahlen rechtfertigen. Es gefiel mir deutlich weniger, aber es wurde mehr respektiert als jede IT-Arbeit, die ich je gemacht habe.
Anerkennung bekommt man für simple Dinge wie das Reparieren von Druckern, das Beheben von Computerproblem A/B/C oder eine werbefreie Android-Sudoku-App, die man für Freunde gebaut hat.
Die eigentliche Kernarbeit, für die man bezahlt wird, wird nicht anerkannt. In vielen Branchen scheint es so zu sein, dass Dankbarkeit abnimmt, sobald Geld im Spiel ist und es als selbstverständlich gilt, die vertragliche Rolle zu erfüllen.
Leute, die sich mit Technik nicht auskennen, glauben, Entwickler arbeiten im Homeoffice und tun am Tag nur 30 Minuten etwas, und AI hat dieses Bild noch verschlechtert.
Ian Rush hat es gut formuliert: „Ein Stürmer ist am besten dran. Er kann fünf Chancen vergeben, aber wenn er das Siegtor schießt, ist er ein Held. Ein Torwart kann brillant halten, aber wenn er nur ein Tor kassiert, ist er der Bösewicht.“
Überall, wo ich gearbeitet habe, wurden eher die Feuerwehrleute belohnt als die Menschen, die dafür sorgten, dass es gar nicht erst brannte. Noch schlimmer ist, dass das offensichtlich fast alle verstehen, außer den Leuten, die die Anreize festlegen.
Es gibt auch die andere Seite. Manche verbringen ihre gesamte Zeit damit, sich über Dinge Sorgen zu machen, die nie eintreten werden, daher lässt sich das Problem auch nicht einfach durch die Belohnung einer rein defensiven Haltung lösen.
So laufen Beförderungen am Arbeitsplatz. Man macht etwas kaputt, es wird eskaliert, dadurch sichtbar, und eine E-Mail geht an die Führungsebene. Wenn man es dann „repariert“, danken einem alle und sagen, man habe gute Arbeit geleistet.
Eine andere Variante ist, die Dinge, die man eigentlich tun sollte, lange hinauszuzögern, um die Sichtbarkeit zu erhöhen. Führungskräfte sehen nicht die Arbeit der Leute, die Verantwortung übernehmen und etwas erledigen, bevor es zu einem großen Problem wird.
Stattdessen merken sie sich den Namen der Person, die etwas kaputtgemacht und dann den Tag „gerettet“ hat.
Gleichzeitig schmeichelt er den Führungskräften und sagt Dinge wie „Es ist besser, das nicht doublerabbit zu überlassen“ oder „Ich glaube nicht, dass er ein Teamplayer ist.“ Dabei war das alles meine Infrastruktur.
Das ist der Grund, warum die Leute mich fragen, warum ich Menschen hasse.
Das lernt man schon in der ersten Klasse der Grundschule. Kinder, die im Unterricht ruhig sitzen und ihre Hausaufgaben machen, beanspruchen nicht viel Zeit und Mühe der Lehrkraft.
Die Problemkinder, die sich nicht an Regeln halten und ständig gelobt werden müssen, sobald sie auch nur ein bisschen Anstrengung ins Lernen stecken, ziehen die Aufmerksamkeit der Lehrkraft auf sich.
Meine Zeit in der IT schwankte zwischen zwei Extremen.
„Alles läuft hier rund. Warum zahlen wir eigentlich für IT?“
„Alles ist kaputt. Warum zahlen wir eigentlich für IT?“
Persönlich bevorzuge ich Ersteres gegenüber Letzterem. Ich habe immer gesagt: „Wenn ich meinen Job richtig mache, merkt niemand, dass ich überhaupt da bin.“ Aber genau deshalb wurde ich entlassen.
Aus Karma-Gründen halte ich noch Kontakt zu Leuten aus der früheren Firma, und inzwischen ist dort alles ein völliges Chaos. Das ist immerhin ein kleiner Trost.
Wenn man die Kompetenzfalle einmal kennt, sieht man sie überall.
Sterman, Repenning und andere Mitautoren haben nach diesem Aufsatz noch mehrere weitere geschrieben, alle interessant, aber fast alle deprimierend.
Besonders bedrückend ist, dass MIT Sloan, wo sich System Dynamics erstmals als akademische Disziplin etablierte, ganz in der Nähe der Harvard Business School liegt, wo System Dynamics zuerst ignoriert wurde.