Wie ein Softwareunternehmen denken

• Der Kerngedanke von James C. Scotts „Seeing Like A State“ ist, dass Organisationen die „Lesbarkeit (legibility)“ ihrer Systeme erhöhen wollen, damit alles messbar und berichtbar wird.
• In der Praxis ist jedoch „unlesbare Arbeit“, die sich weder nachverfolgen noch vorhersagen lässt, unverzichtbar, und ein einseitiger Fokus auf Lesbarkeit kann die Effizienz sogar senken.
• Vor allem große Unternehmen machen Arbeit durch Prozesse wie Quartalsplanung, OKRs und Jira lesbar, doch paradoxerweise mindert das die Effizienz, sodass kleine Unternehmen 20-mal effizienter sein können als große.
• Um auf Notfälle reagieren zu können, erlauben Organisationen temporäre unlesbare Bereiche wie „Tiger Teams“, und informelle Zusammenarbeit über Backchannels zwischen Engineers spielt eine ebenso wichtige Rolle wie formale Prozesse.
• Der Erfolg von Technologieunternehmen hängt davon ab, das Gleichgewicht zwischen lesbaren Prozessen und unlesbarer praktischer Arbeit zu bewahren; mit nur einer von beiden Seiten funktioniert eine Organisation nicht richtig.

---

Einleitung: Die Kernidee von „Seeing Like A State“

• Die Kernaussage von James C. Scotts Buch „Seeing Like A State“ lässt sich in drei Punkten zusammenfassen:
  • Moderne Organisationen verwandeln Systeme in Formen mit maximaler „Lesbarkeit (legibility)“, damit alle Teile kontrolliert werden können und mess- sowie berichtbar sind.
  • Gleichzeitig sind diese Organisationen auf umfangreiche „unlesbare (illegible)“ Arbeit angewiesen. Es gibt also viele unverzichtbare Tätigkeiten, die sich weder nachverfolgen noch planen lassen.
  • Eine stärkere Lesbarkeit behindert oft die Effizienz, doch andere Vorteile wie Kontrolle, Planung und Transparenz werden als großer Gewinn betrachtet.
• Lesbarkeit meint Arbeit, die vorhersehbar ist, deren Output nachverfolgt werden kann und die nicht von bestimmten Einzelpersonen abhängt. Beispiele: Terminplanung, OKRs, Jira.
• Unlesbarkeit meint improvisierte oder auf implizitem Wissen beruhende Arbeit, also Zusammenarbeit, plötzliche Änderungen oder beziehungsabhängige Tätigkeiten, die sich nicht schriftlich festhalten oder formalisieren lassen.

Beispiele für „Seeing Like A State“

• Scott erklärt anhand des Falls des „geordneten Waldes“ im Deutschland des 19. Jahrhunderts, wie Organisationen versuchen, aus Effizienzgründen zu kontrollieren und zu standardisieren.
  • Die Bewirtschaftung sollte so erfolgen, dass alle Bäume des Waldes auf einen Blick erfasst werden konnten, in der Erwartung, Planung, Handel und Ressourcenzuteilung effizienter zu machen.
  • Tatsächlich wurden jedoch die Vielfalt des Waldes und die Rolle des Unterwuchses übersehen, was die Produktivität verringerte und den Wald anfälliger für Krankheiten und Parasiten machte.
• Man wollte also sowohl Effizienz als auch Transparenz erreichen, doch das übermäßige Streben nach Lesbarkeit führte paradoxerweise zu geringerer Effizienz.

Lesbarkeit und Unlesbarkeit in Softwareunternehmen

• Auch in Softwareunternehmen kann ein kleines Team oder sogar eine Einzelperson effizienter sein.
  • Dass ein einzelner Engineer allein effizienter arbeiten kann als als Teil eines Teams, gilt unter Software-Engineers fast als Allgemeinwissen.
  • Engineer-getriebene Arbeit schreitet viel schneller voran als von oben zugewiesene Arbeit, weil sie nicht in eine für andere sinnvolle Form übersetzt oder in alle Richtungen aktiv kommuniziert werden muss.
• Kleine Softwareunternehmen sind bei der Bereitstellung von Software großen Unternehmen oft weit überlegen, weil es kein Problem ist, wenn ein Großunternehmen zehnmal so viele Engineers einsetzt, ein kleines Unternehmen aber 20-mal effizienter ist.
• In großen Unternehmen werden verschiedene Verfahren und Werkzeuge eingeführt, um die Arbeit von Engineers „lesbar“ zu machen.
  • Das ist nützlich für Planung, Messung und Reporting der Arbeit, kann aber die tatsächliche Softwareproduktivität senken.
• Kleine Unternehmen können sofort auf Probleme reagieren oder Veränderungen schnell aufnehmen – also über eine unlesbare Fähigkeit verfügen.
• Dass große Unternehmen diese Effizienz gegen komplexe Verfahren eintauschen, hängt mit großen Enterprise-Verträgen zusammen. Große Kunden verlangen von Anbietern Vorhersehbarkeit und Zuverlässigkeit.
• Um mit solchen Kunden zusammenzuarbeiten, ist Lesbarkeit unverzichtbar, etwa durch langfristige Planung, Funktionszusagen und Dokumentation des Fortschritts.
• Die Prozesse bleiben bestehen, weil der in Dollar messbare Wert von Lesbarkeit größer ist als die Fähigkeit, Software effizienter zu produzieren.

Der praktische Wert von Lesbarkeit für große Unternehmen

• In großen Softwareunternehmen bedeutet Lesbarkeit, dass
  • bis hinunter zum einzelnen Engineer alle laufenden Projekte erfasst werden können,
  • eine Liste der im letzten Quartal abgeschlossenen Projekte sofort erstellt werden kann,
  • Arbeit mindestens ein Quartal im Voraus (oder länger) geplant werden kann,
  • in Krisensituationen die gesamten Ressourcen einer Abteilung mobilisiert und sofort auf dringende Arbeit angesetzt werden können.
• Kleine Softwareunternehmen erfüllen diese Anforderungen fast nie – abgesehen von ihrer Fähigkeit, flexibel und sofort zu reagieren.
• Große Unternehmen sind stark bei Dokumentation, Kategorisierung und langfristiger Planung, doch ihre Reaktionsgeschwindigkeit – also der unmittelbare Einsatz organisatorischer Ressourcen – kann gerade dadurch geschwächt werden.
• Diese Sicherstellung von Lesbarkeit spielt vor allem bei Vertrauen, Verträgen und langfristiger Zusammenarbeit mit Enterprise-Kunden eine zentrale Rolle.

Annahmen zur Herstellung von Lesbarkeit – und ihre Grenzen

• Große Unternehmen treffen beim Streben nach Lesbarkeit die folgenden vereinfachenden Annahmen:
  • Alle Engineers derselben Karrierestufe leisten ungefähr dasselbe.
  • Das Umsetzen oder Umorganisieren von Engineers verursacht keinen Produktivitätsverlust.
  • Wenn die Zahl der Engineers im Team gleich bleibt, bleibt auch die Produktivität über die Zeit stabil.
  • Projekte lassen sich im Voraus schätzen, mit einer gewissen Fehlerspanne.
• In der Realität gilt jedoch:
  • Selbst auf derselben Stufe gibt es große Leistungsunterschiede, und Spezialisierung und Interessen machen für die Produktivität eines Projekts einen erheblichen Unterschied.
  • Zwischen Teamgröße und Produktivität besteht nur ein schwacher Zusammenhang.
  • Projektaufwände zu schätzen ist fast eine Illusion; in der Praxis wird oft sogar die Arbeitsweise geändert, um zu den Schätzungen zu passen.
• Trotzdem sind diese Annahmen für die Kommunikation im Unternehmen, Vereinbarungen mit großen externen Unternehmen und die Geschäftsplanung nützlich.

Vorübergehend erlaubte unlesbare Bereiche

• In großen Unternehmen führen Prozesse zur Herstellung von Lesbarkeit zu erheblichen Verzögerungen.
  • Produktidee → Planungsphase der Produktorganisation → technische Prüfung durch die Engineering-Organisation → Verhandlung zwischen VPs und Senior Managern über Teamzuweisungen → Aufnahme in den Team-Planungs-Backlog → Team-Ticket-Backlog → Sprint → tatsächlicher Arbeitsbeginn
• Diese Struktur ist mit Arbeit, die sofort erledigt werden muss, völlig unvereinbar.
• Um dieses Problem zu lösen, werden temporäre unlesbare Bereiche wie „virtuelle Teams“, „Strike Teams“ oder „Tiger Teams“ zugelassen.
  • Sie bestehen aus ausgewählten Engineers, denen die Organisation vertraut.
  • Oft wird gar kein Manager zugewiesen, und ein sehr erfahrener Engineer führt das Projekt.
  • Sie erhalten einen losen Auftrag und dürfen im Grunde alles tun, was nötig ist, um das Ziel zu erreichen.
• Das ist ein kluger Kompromiss zwischen vollständiger Unlesbarkeit und vollständiger Lesbarkeit.
• Solche Teams umgehen formale Prozesse, werden aber nicht dauerhaft betrieben, sondern nur vorübergehend aufrechterhalten.
• Auch genehmigte Unlesbarkeit koexistiert nur unbeholfen mit dem Rest der Organisation; andere Engineers sehen die Freiheit, ohne Prozesslast zu arbeiten, und reagieren darauf mit Neid oder halten sie für riskant.

Dauerhafte und nicht genehmigte unlesbare Bereiche

• Der formale Weg, auf dem ein Engineer aus Team A Arbeit bei Team B anfragt, besteht darin, ein Issue im „Planungs“-Backlog anzulegen und dann den 12-stufigen Prozess abzuwarten, bis die Arbeit in einen Sprint aufgenommen wird – was Wochen bis Monate dauern kann.
• Die formale Lösung lautet, dass Team A die Arbeit von Team B bereits im Planungsprozess antizipieren soll, was absurd ist, weil niemand Monate vor dem Schreiben des Codes alle Änderungen vorhersehen kann.
• Die tatsächliche Lösung ist ein unlesbarer Backchannel.
  • Ein Engineer aus Team A bittet einen Engineer aus Team B: „Kannst du diese eine Zeile ändern?“
  • Der Engineer aus Team B erledigt das sofort, und ob dafür ein Ticket angelegt wird, ist optional.
  • Das ist unlesbar, weil es von zwischenmenschlichen Beziehungen zwischen Engineers abhängt.
• Backchannels existieren auf allen Ebenen des Unternehmens dauerhaft.
  • Teamübergreifende Backchannels zwischen Engineers, Backchannels innerhalb von Teams, zwischen Managern und zwischen Produktmanagern
  • Wenn in einem offiziellen Raum eine Frage gestellt wird, ist die Antwort häufig bereits privat mit der antwortenden Person geprobt und abgestimmt worden.
• Backchannels können schieflaufen und werden manchmal genutzt, um sich Vorteile zu verschaffen – auf Kosten naiver Engineers.

Soziopathen, Ahnungslose und Verlierer

• Venkatesh Raos „Gervais Principle“ teilt Organisationen in drei Gruppen ein:
  • Die „Soziopathen“ an der Spitze nutzen die Regeln der Organisation zynisch zu ihrem eigenen Vorteil.
  • Die „Ahnungslosen (clueless)“ im mittleren Management glauben an die offiziellen Regeln der Organisation und erkennen nicht, dass darunter ein tieferes Spiel läuft.
  • Die „Verlierer (losers)“ darunter erkennen zwar, dass ein Spiel läuft, möchten daran aber nicht teilnehmen.
• Diese Kategorien lassen sich unter dem Gesichtspunkt der Lesbarkeit lesen.
  • Soziopathen und Verlierer sind beide in die unlesbare Welt der Organisation eingebunden.
  • Die „Ahnungslosen“ befassen sich nur mit lesbaren Prozessen; wenn sie befördert werden wollen, schauen sie sich die offizielle Karrierelaufbahn an und planen, wie sie die einzelnen Werte der nächsten Stufe erfüllen können.
• Sie als „Ahnungslose“ zu bezeichnen, ist übermäßig zynisch.
  • Lesbare Prozesse sind weiterhin sehr wichtig und machen einen großen Teil dessen aus, was eine Organisation tut.
  • Die Verbesserung formaler Prozesse ist weiterhin Arbeit mit sehr hohem Hebel.
• Diese Kategorien helfen zu verstehen, dass häufige Konfliktzonen in Softwareunternehmen aus der Reibung zwischen diesen Gruppen entstehen.

Schlussgedanken

• Es ist wichtig, die unlesbare Welt innerhalb von Organisationen zu erkennen und zu nutzen.
• Ich habe viel darüber geschrieben, wie man Unlesbarkeit in Technologieunternehmen erkennt und einsetzt.
  • Offizielle und lesbare Regeln zu brechen, ist manchmal das Richtige.
  • Produktmanager missbrauchen unlesbare Kanäle, daher sollte man sich davor hüten, naiven Engineers Arbeit abzunehmen.
  • Gute Engineers sollten an „Side Bets“ außerhalb des normalen Planungsprozesses arbeiten.
  • Eine Beförderung auf Staff oder höher hat fast nichts mit der offiziellen Karrierelaufbahn zu tun.
• Ratschläge zu unlesbaren Prozessen sind „gefährliche Ratschläge“.
  • Wer öffentlich verkündet, Arbeit statt über formale Prozesse über Backchannels zu erledigen, wird von der Organisation bestraft.
  • Und zwar auch dann, wenn die Managementkette genau das wollte.
• Es gibt viel negatives Feedback auf die Ansicht, dass formale Prozesse manchmal umgangen werden sollten, doch der Autor hält diese Sichtweise für naiv.
• Jede Organisation hat sowohl eine lesbare als auch eine unlesbare Seite.
  • Die lesbare Seite wird ab einer gewissen Größe wichtig und ermöglicht langfristige Planung sowie Koordination mit anderen großen Organisationen.
  • Die unlesbare Seite ist genauso wichtig: Sie ermöglicht hocheffiziente Arbeit, dient als Sicherheitsventil für Prozesse, die nicht zur aktuellen Lage passen, und erfüllt das natürliche menschliche Bedürfnis nach Klatsch und stillschweigender Einigung.

[GN⁺]

Hacker-News-Kommentar

• Ich stimme dem meiste zu, würde aber widersprechen, dass die Führung automatisch annimmt, legibility sei jeden Preis wert. Wenn ein CEO sich um alle Detailaufgaben kümmern müsste, etwa die Parallelisierung von Unit-Tests, wäre das so, als müsste das Gehirn jede einzelne Fingerbewegung bewusst steuern und könnte am Ende gar nichts mehr tun. Realistisch kann ein CEO, also der Kopf eines Unternehmens, vielleicht etwa 7 % des Ganzen kontrollieren. Den Rest füllen die einzelnen Mitarbeitenden aus; er ist nur das Gehirn, nicht der ganze Körper. Führungskräfte neigen jedoch leicht zu dem Irrglauben, sie seien am wichtigsten, und winken Dinge durch, für die ihnen Zeit oder Fachwissen fehlt, etwa den Unterschied zwischen einem exzellenten MIT-Absolventen und einem durchschnittlichen Engineer aus einem Bootcamp. Wenn man über Googles Erfolg spricht, wird die Leistung außerdem oft eher den zwei Gründern oder dem CEO zugeschrieben als den Dutzenden hervorragenden Mitarbeitenden an der Front

  • Das Beispiel mit dem „Gehirn, das jeden Atemzug bewusst wahrnimmt“ ist meines Erachtens etwas strohmannartig. Ein kompetenter CEO weiß, dass er sich nicht persönlich um das Unit-Test-Management im Entwicklungsteam kümmern muss. Das Maß an legibility, das Unternehmen tatsächlich anstreben, liegt in der Praxis in einem deutlich vernünftigeren Rahmen

• Einiges daran stimmt, aber allzu extrem wirkt es auf mich nicht. Ich arbeite in einem Unternehmen mit etwa 5000 Mitarbeitenden, also nicht klein, aber auch nicht auf Amazon-Niveau. Die meisten Regeln haben ziemlich gute Gründe. Dass man zum Beispiel zwei Code-Reviewer braucht, dient der Fehlervermeidung. Ablehnungen sind selten, aber ohne Review würde man deutlich häufiger Ausfälle in Produktion sehen. Solche Regeln zwingen einen wenigstens dazu, die Checks tatsächlich zu machen. Natürlich gibt es irgendwann Situationen, in denen man Regeln brechen muss, etwa wenn der Großteil des Teams wegen eines Incidents ausfällt. Dann ist es nur sinnvoll, Ausnahmen im Sinne der Regel zuzulassen. Aber wenn ein Unternehmen nur aus unverständlichen, rein bürokratischen Regeln besteht, etwa weil jemand stur auf seinem eigenen Prozess beharrt und nur ruft „Deine Vorgehensweise ist falsch“, dann geht man besser. In einer Umgebung, die Prozesse oder das Ego Einzelner höher bewertet als echten Fortschritt und Ergebnisse, ist ein Jobwechsel die richtige Antwort

• Seit TDD ist die Versuchung groß geworden, zu sagen: „Wenn man es nicht testen kann, ist es auch nicht implementiert.“ Das Wort legibility beschreibt das erstaunlich gut. In Tritium hatten wir Hunderte von Unit-Tests, aber erst beim Aufbau eines Blogs wurden qualitative Bugs sichtbar, die die Unit-Tests nicht erfassen konnten und die sich per Test nur schwer nachweisen lassen; siehe https://tritium.legal/blog/eat. Vielleicht erklärt das auch, warum Indie-Game-Entwicklung den Marktzwängen so gut standhält. Game-Entwickler nutzen ihr eigenes Produkt direkt (Food-dogging) und erzielen dadurch qualitative Verbesserungen. Sie brauchen keine übermäßig ausgeprägte legibility-Oberfläche wie Software in Großunternehmen. Der Kernpunkt ist, dass man sowohl qualitative als auch quantitative Kennzahlen braucht

  • Tests, insbesondere Unit-Tests, sind anfällig für den „Straßenlaternen-Effekt“. Je trivialer oder weniger wichtig etwas ist, desto leichter lässt es sich testen, und so testet man am Ende nur die einfachen Dinge. Wenn sich eine Organisation nur auf leicht messbare Kennzahlen wie line coverage versteift, besteht die Gefahr, dass wirklich aussagekräftige, aber schwierige Validierung unter den Tisch fällt. Auch qualitative Beurteilungen wie Reviews durch erfahrene Engineers sind wichtig

  • In der Spieleentwicklung ist die Feedback-Schleife viel kürzer als in anderen Softwarebereichen. Wenn zum Beispiel ein Memory Leak auftritt, zeigt sich das Problem sofort hunderte Male pro Sekunde. Langsamer Code wird durch sichtbares Ruckeln unmittelbar spürbar, sodass man aus Performance-Sicht zwangsläufig auf Dinge wie Cache-Kohärenz oder den Einsatz von GC achten muss

  • Ich mag TDD, aber am Ende braucht man trotzdem unbedingt manuelle Tests. Wenn man nicht selbst testet, treten häufig unerwartete Probleme auf. Gerade Dinge wie Benutzerfreundlichkeit zeigen sich oft erst im tatsächlichen Gebrauch

• Ich lese Seans Texte gern, und auch diesem stimme ich in weiten Teilen des Produktbereichs zu. Vor ungefähr einem Jahr wollten mehrere Product-Leute und Engineers etwas bauen, das auch anderen Teams helfen würde. Über formale Kanäle (legible channel) eine Freigabe zu bekommen, war unter der damaligen Struktur unrealistisch, also haben wir es auf informellem Weg (illegible channel) auf Basis von Vertrauen und Respekt umgesetzt. Es war ein Grassroots-Vorhaben und verbreitete sich intern sogar schnell per Mundpropaganda und gewann traction. Inzwischen nutzt das Management dieses Beispiel natürlich als eigene Erfolgsgeschichte, aber jetzt, wo man alle formalen Verfahren (legible channel) und nachträglichen Begründungen umsetzt, ist der Prozess ziemlich schmerzhaft. Andererseits ist es deutlich leichter, weil das Risiko des Scheiterns stark gesunken ist. Es war eines der lohnendsten und unterhaltsamsten Projekte, an denen ich in den letzten Jahren gearbeitet habe

• Je länger ich in Unternehmen arbeite und je mehr ich office politics ausgesetzt bin, desto stärker denke ich, dass sie Geopolitik oder Diplomatie ähnelt. Wenn man noch weiter geht, sieht man Parallelen auch zu sozialen Beziehungen oder romantischen Beziehungen. Das liegt wahrscheinlich an meiner eher mathematischen Neigung, abstrakte Modelle zu bauen

  • Politik ist tatsächlich mein Lieblingsthema. Ich lese gern Bücher, Magazine und alle möglichen Materialien dazu, und ehrlich gesagt stört mich auch Unternehmenspolitik nicht besonders. Der Kern ist letztlich, dass Menschen sich menschlich verhalten. Jede Person, und ebenso jede Organisation, hat Dinge, die sie will, und Dinge, die sie fürchtet, und diese in Balance zu bringen, hat etwas Spielerisches. Es ist fast wie das Lösen eines Engineering-Problems, nur dass die Anforderungen hier „Menschen“ sind. Gerade dieser Problemlösungsprozess ist interessant

  • Das habe ich erst vor Kurzem erkannt. Anfangs sah ich Diplomatie als Ergebnis eines komplexen Systems aus Hunderten von Diplomaten, aber in Wirklichkeit ist es im Wesentlichen nur ein Geflecht menschlicher Beziehungen zwischen einigen wenigen Mächtigen. Man kann es fast ähnlich betrachten wie das, was in einer Kindertagesstätte passiert

  • Das ist instinktiv ein ganz natürliches Phänomen. Die Ähnlichkeit zeigt sich zwischen Großunternehmen und Regierungen sogar deutlicher als bei sozialen Beziehungen wie Romantik. Unternehmen sind meist viel autokratischer oder feudaler. Es gibt viele Unterschiede, aber je größer sie werden, desto mehr ähneln sie Regierungen. Eine ausgefeilte Bürokratie ist einer dieser Punkte

  • Spieltheorie-Wiki

  • Wenn man sieht, wie viele moderne Politiker ihre Laufbahn in gewöhnlichen Bürojobs begonnen haben, ist dieses Phänomen eigentlich nicht überraschend

• Ich arbeite in der IT-Sicherheit, und dort ist das noch ausgeprägter. Wenn unser Team Anfragen annehmen soll, die unseren direkten Kennzahlen nicht helfen, frage ich mich, ob es außer einem informellen Weg (back channel) noch andere Alternativen gibt. Falls jemand welche kennt, würde mich das interessieren

  • Man kann die eigenen Team-Engineers gegen Aufgaben oder Roadmap-Punkte eintauschen, die das andere Team haben will, also gewissermaßen die jeweiligen Interessen gegeneinander handeln

• Guter Text, aber ich möchte einen Punkt ansprechen, der fast nie behandelt wird. Im Text werden Software-Engineers wie Blätter an einem Baum dargestellt, also ungefähr wie Arbeiter an einem Fließband, und das finde ich schade. Wie auch im Abschnitt über „Legible assumptions“ anklingt, übernehmen Engineers in Wirklichkeit ebenfalls eine Art Managementrolle, indem sie die Verbindungen in der Organisationsstruktur durch „Code“ erweitern. Das Problem ist nur, dass der Gegenstand ein anderer ist; die zugrunde liegenden Überlegungen sind erstaunlich ähnlich

  • Um auf IC-Ebene etwa Senior Engineer zu werden, wird faktisch erwartet, dass man auch die Rolle eines Managers teilweise übernimmt. Es reicht nicht, nur gut Code zu schreiben. Man muss auch Projektmanager, Architekt, Teamleiter und Überzeuger sein und außerdem dokumentierte Begründungen hinterlassen

• Gibt es hier Leute, die dem Teil zustimmen: „Warum brauchen große Softwareunternehmen diese Fähigkeit unbedingt, kleine Firmen aber nicht? Das ist nicht mein Fachgebiet, aber vermutlich liegt es an Enterprise-Projekten“? Würde gern Meinungen dazu hören

  • Ich denke, es liegt weniger an Enterprise-Deals als an interner communication at scale. Man kann eine Organisation mit m Mitarbeitenden als m*m-Kommunikationsmatrix modellieren. Bei wenigen Leuten sind fast alle Felder 1, also enge Kommunikation, aber mit wachsender Größe werden die meisten Felder zu 0, also Trennung, oder 0.5, also informelle Kommunikation. Information ist am Ende aber das Unternehmen selbst. Deshalb braucht man Manager und formale Prozesse, die für diesen Informationsfluss verantwortlich sind. Planung, Beförderungen, Reviews und Ähnliches dienen letztlich dazu, diese legibility sicherzustellen

  • Ich arbeite in einer kleinen Firma, die große Enterprise-Projekte übernimmt, aber intern brauchen wir dafür keine strikte legibility. Gegenüber dem Kunden braucht man legibility im Projektmanagement, aber das heißt nicht, dass die interne Entwicklungsweise im Detail kontrolliert wird. Unterm Strich klammern sich große Unternehmen an legibility, weil sie bereits Großunternehmen sind oder eines werden wollen

  • Ich war lange im Bereich Medical Imaging, und die meisten Geschäftsinhaber verstehen nicht wirklich, dass sie in der IT-Services-/Solution-Branche tätig sind. IT-Service-Fähigkeiten waren in der Praxis der eigentliche Erfolgsfaktor. Viel wichtiger als die Diagnostik selbst war, dass nicht-radiologisches Personal an der Nutzbarkeit und Effizienz der Plattform gearbeitet hat

  • Egal wie groß die Organisation ist, man muss immer wieder auf interne und externe Audits vorbereitet sein. Auditoren wollen in der Regel möglichst viele Prozessdokumente sehen. Im schlimmsten Fall kann ein Auditor dem Kunden sogar „kündigen“, wie in diesem Fall

  • Dieser Punkt, dass es an Enterprise-Deals liegt, wirkt auf mich ebenfalls etwas eigentümlich. Ich komme aus Startups und bin heute mittleres Management in einem mittelgroßen Unternehmen. Je größer eine Organisation wird, desto mehr braucht sie zumindest eine minimale Struktur, die erklärt, wie Arbeit zu erledigen ist. So sehr man Prozesse auch hasst: Jenseits von Dunbar’s Number reichen Empathie und informelle Kommunikation allein nicht mehr aus. Steam ist vielleicht ein extremes Gegenbeispiel, aber dort werden auch nur ganz bestimmte Menschentypen ausgewählt, und die interne Politik ist sehr stark ausgeprägt

• Schon die Wortwahl legibility ist interessant. Es wirkt wie eine Dichotomie zwischen formalen und informellen Prozessen. Solange ein Unternehmen klein ist, funktionieren informelle Wege gut, aber ab einem bestimmten Schwellenwert kommt man um formale Regeln und Prozesse nicht herum. Langfristig führt das dazu, dass Regeln starr werden und mit Veränderungen nicht mehr Schritt halten. Nach und nach fixiert man sich mehr auf den Prozess als auf das eigentliche Ziel. Es ist nicht leicht, aus solchen Routinen auszubrechen und Neues lebendig zu halten. Man sagt in Unternehmen oft, Geld sei wie Blut, aber in Wirklichkeit ist Geld nur selten die eigentliche Motivation. Es ist eine notwendige Bedingung, aber nicht der Daseinszweck selbst

• Es ist immer eine Frage des Gleichgewichts. Ich war 25 Jahre lang Engineering Manager und habe in einem stark prozessorientierten Unternehmen gearbeitet. Das war frustrierend, hatte aber auch Vorteile: Es hat konsequent Hardware auf Weltniveau hervorgebracht, wenn auch keine Software. Dokumentation und Ähnliches sind notwendig, aber wenn man es übertreibt, besteht die Gefahr, dass Projekte erstarren. Der Kommunikations-Overhead ist das größte Problem. Deshalb können kleine, fähige Teams, die lange zusammenarbeiten, enorm produktiv sein, und tribal knowledge ist dabei tatsächlich ein sehr wichtiger Beschleuniger. Ich habe den Text Concrete Galoshes auch deshalb geschrieben, um genau diese strukturellen und verhärtenden Elemente zu behandeln. Die wichtigste Lehre lautet: „Man sollte nicht allen Projekten dasselbe Outfit anziehen.“ Unterschiedliche Projekte brauchen unterschiedliche Strukturen und unterschiedliche Overheads

  • Kommunikations-Overhead ist wirklich das Problem. Wenn man Teammitglieder hinzufügt, steigen die Kommunikationsanforderungen innerhalb des Teams exponentiell, und genauso ist es, wenn die Zahl der Teams in der Gesamtorganisation wächst. Das Geheimnis wirklich effizienter Teams sind Vertrauen und gegenseitiges Verständnis. Mit der Zeit lernt man die Stärken und Schwächen der anderen kennen und baut Vertrauen untereinander auf. Idealerweise wird dieses angesammelte tribal knowledge dann gut über Dokumentation, Mentoring, Vorträge und Ähnliches weitergegeben