Die gescheiterte Kommodifizierung technischer Arbeit

Die gescheiterte Kommodifizierung technischer Arbeit

• Die Leidenschaft fürs Kochen eines Mannes, der im Bereich Data Engineering außergewöhnlich talentiert ist und als erster Manager tätig war.
• Eine sehr starke Leidenschaft fürs Kochen, die sich etwa darin zeigt, Analysen zur Wärmeverteilung eines Hähnchens im Ofen zu teilen.
• Er drückt Respekt für die Komplexität des Kochens und für die Komplexität des Betriebs von McDonald’s aus.

Kurze Einblicke in die Denkweise von C-Level-Führungskräften

• Um den aktuellen Zustand der Technologiebranche zu verstehen, liest er das Buch The Phoenix Project.
• Das Buch erklärt, dass IT-Betrieb der Arbeit in einer Fertigungsfabrik ähnelt, was Implikationen für das Management von Arbeitsabläufen innerhalb einer Organisation liefert.
• Es gibt viele Bücher zu ähnlichen Themen wie The Unicorn Project und Investments Unlimited, und diese Bücher geben Ratschläge für den effizienten Betrieb von Organisationen.

McData

• Unternehmen, die technische Produkte verkaufen, vermarkten ihre Produkte mit Fokus auf die Reproduzierbarkeit konsistenter Arbeit statt auf technische Details des Produkts.
• Die Produkte versprechen, ausreichend gute Ergebnisse bei der Lösung technischer Probleme zu liefern, ohne von den Fähigkeiten eines bestimmten Engineers abhängig zu sein.
• Viele Unternehmen ignorieren technische Details und versuchen, Probleme einfach durch den Kauf eines neuen Systems zu lösen.

It's Fucking Raw

• Viel technische Arbeit ist noch nicht kommodifiziert, und das ist ein wichtiges Problem.
• Die Kommodifizierung technischer Arbeit scheitert oft, was dazu führt, dass Unternehmen Produkte verkaufen und kaufen, die nicht richtig funktionieren.
• Die Kommodifizierung technischer Arbeit ist weiterhin mit individueller Kreativität verbunden, was wiederum mit dem menschlichen Faktor innerhalb von Organisationen zusammenhängt.

Meinung von GN⁺

• Das Wichtigste an diesem Artikel ist, dass die Kommodifizierung technischer Arbeit noch nicht vollständig gelungen ist.
• Die Komplexität und Kreativität technischer Arbeit zu verstehen und effektiv zu managen, bleibt für viele Unternehmen eine anspruchsvolle Aufgabe.
• Interessant an diesem Artikel ist, dass er zeigt, wie komplex der Versuch tatsächlich ist, technische Arbeit als bloße Ware zu betrachten.

[GN⁺]

Hacker-News-Kommentare

• Ich denke, der Autor übersieht, dass ein erheblicher Teil der technischen Arbeit inzwischen zur Commodity geworden ist. Dinge, die früher technische Arbeit waren, sind heute zu einfachen Tätigkeiten geworden. Zum Beispiel wurden Serienbriefe oder doppelte Buchführung heute durch einfaches Barcode-Scannen und Bezahlen per Tippen ersetzt. Schwieriger als die technische Arbeit selbst ist die Erhebung der Anforderungen.
• Ich stimme zu, dass die vollständige Commodityisierung technischer Arbeit eine schlechte Idee ist und weiterhin scheitern wird. Ich glaube jedoch nicht, dass The Phoenix Project das befürwortet. Die Kernaussage von The Phoenix Project ist, ein klares System zu haben, um wiederkehrende Arbeit zu verwalten und zu automatisieren, die Durchlaufzeit von Aufgaben zu minimieren, Informationen breit zu teilen, tatsächlich für das Business notwendige Arbeit zu erledigen und ungeplante Arbeit sowie Störungen zu reduzieren, damit Mitarbeitende wertvollere Arbeit leisten können.
• Es wird darauf hingewiesen, dass die Begriffe „Commodityisierung“ und „Kommodifizierung“ verwechselt werden. „Commodityisierung“ bedeutet, dass ehemals proprietäre Dinge allgemein werden, während „Kommodifizierung“ bedeutet, dass Dinge, die nicht verkauft wurden, in verkaufbare Güter verwandelt werden.
• Entwickler sind nicht mit jugendlichen McDonald’s-Mitarbeitern vergleichbar, sondern eher mit den Ingenieuren, die die Maschine entworfen haben. Programmierung ist nicht die Ausführung der Arbeit, sondern Meta-Arbeit: Man schreibt einmal eine Liste von Anweisungen, und der Computer führt die Arbeit unbegrenzt aus.
• Es gibt die falsche Vorstellung, dass Softwareentwicklung bereits „commodityisiert“ sei und deshalb kein Code mehr geschrieben werden müsse. Tatsächlich ist es nicht einfach, Systeme zu bauen, die neue Probleme lösen; dafür braucht man Text, der logische Regeln und Abläufe ausdrückt, Versionsverwaltung, Rollbacks und mehr — daher braucht man Programmierer.
• Man kann kein wertvolles Selbsthilfebuch hervorbringen, ohne dem menschlichen Faktor Raum zur Entfaltung zu geben. Dennoch braucht man weiterhin eine Fabrik, die Bücher drucken kann, und schöne Bindungen entstehen nur, wenn Menschen sie betreiben, die eine Verbindung zur Arbeit haben.
• Die Tech-Industrie versucht seit Langem, Entwickler zu kommodifizieren. Trotz scheinbar einfacher Anforderungen zusammen mit High-Level-Frameworks funktioniert noch immer viel Software nicht gut. Wie der Autor anmerkt, besteht die eigentliche Lösung aus fähigen Entwicklern, denen die Sache wichtig ist.
• In Business-Intelligence-/Analyse-Rollen gibt es Versuche, Menschen, die SQL schreiben, durch Personen zu ersetzen, die Tools wie Tableau bedienen können. Das bringt jedoch einige Probleme mit sich: Man muss mehr (niedrig bezahlte) Leute einstellen, die Business-Logik wird in der UI versteckt und dadurch komplexer, und die Lösung liegt nun in einer Tableau-Arbeitsmappe gespeichert vor und kann nicht als Eingabe für andere Dinge verwendet werden.
• Es erscheint passender, Software mit Stadtplanung zu vergleichen, und es entstehen verschiedene Fachrichtungen. Mit der Weiterentwicklung von Standards könnten konkrete Zertifizierungen nötig werden, um in bestimmten Bereichen arbeiten zu dürfen. Software ist in vielen Fällen nicht das Endergebnis, sondern etwas, das eigene Möglichkeiten eröffnet.
• Ich habe in einem Unternehmen gearbeitet, das die Ideen aus The Phoenix Project auf Entwickler angewandt und sie wie Maschinenteile in einer Fabrik behandelt hat; dieses Unternehmen landete schließlich dabei, eine wichtige Tochtergesellschaft zu schließen und den Großteil der Belegschaft zu entlassen.