Technik
- Fordere, dass Kernsysteme 6–18 Monate lang neu geschrieben werden. Gib dem vorherigen CTO die Schuld.
- Ermutige dazu, dass alle unterschiedliche Sprachen und Frameworks verwenden.
- Teile das System entlang willkürlicher Grenzen auf, sodass viele Systeme an einer Funktion beteiligt sind.
- Schaffe eine komplexe Entwicklungsumgebung. Lass ein Service Mesh mit mindestens 12 Services laufen.
- Sorge dafür, dass sich Produktionsumgebung und Entwicklerumgebung so stark wie möglich unterscheiden.
- Führe Deployments so selten wie möglich durch. Empfiehl extreme Vorsicht bei Deployments.
- Führe für Codeänderungen und allgemeine Workflows sehr komplexe Prozesse ein. Begründe das mit "Sicherheit" oder "Compliance".
- Sorge dafür, dass jede Aufgabe im Task-Tracker erfasst wird und von einer Gruppe von mindestens 5 Personen geprüft, priorisiert und genehmigt wird.
- Verbiete alles außerhalb des ursprünglich definierten Arbeitsumfangs. Verbiete zum Beispiel Code-Aufräumen oder andere Verbesserungen.
- Baue fast alles, was nicht zur Kernkompetenz gehört, intern. Begründe das damit, dass man "Vendor Lock-in vermeiden" wolle.
- Bestehe darauf, für alles Abstraktionsschichten hinzuzufügen. Nutze abstrahierte Vendoren und füge zusätzliche Abstraktionsschichten hinzu.
- Empfiehl technische Entscheidungen für unrealistisch optimistische Skalierung. Plane mindestens die dreifache Last der aktuellen Situation ein.
- Fördere gemeinschaftliches Eigentum am System. Sorge dafür, dass sich niemand für die Wartbarkeit verantwortlich fühlt.
- Bestehe darauf, fast alles als "Plattform" zu zentralisieren. Halte das Plattform-Team personell unterbesetzt und verhindere, dass andere Teams etwas bauen, das der Plattform gehören könnte.
- Lass das Plattform-Team APIs häufig verändern und zwinge andere Teams dazu, ihren Code auf die neueste Version zu refaktorieren.
- Stelle "Architekten" ein und verlange selbst für kleine Änderungen ein "Architektur-Review".
- Verlange selbst für kleine Änderungen ein "Security-Review".
Produkt
- Ignoriere nützliche Metriken aus akademischen Gründen. Nenne sie zum Beispiel "verzerrt" oder "nachlaufende Indikatoren".
- Wähle Vanity-Metriken, die nichts mit geschäftlichem Wert zu tun haben. Wähle verrauschte Metriken.
- Betrachte alles als "große Wette" und bestehe darauf, nichts auszurollen, bevor nicht alles vollständig fertig ist.
- Betrachte jedes Feature als "essenziell" und als wichtigen Teil von "Version Zero". Mache niemals Zugeständnisse.
- Erarbeite sehr detaillierte "strategische" Pläne.
- Wechsle häufig die Richtung.
- Tue offensichtliche Verbesserungen als "lokale Optimierung" ab.
- Binde Ressourcen an den neuesten Trend. Starte eine oberflächlich plausible "AI-Strategie". Gib dafür viel Geld für Vendoren und Berater aus.
- Ermutige Produktmanager dazu, den Großteil ihrer Zeit mit "Strategie" und "Planung" zu verbringen.
- Mache es für Ingenieure und Produktmanager schwierig oder unmöglich, das Produkt intern zu nutzen.
- Behandle Nutzer intern geringschätzig als "Idioten".
Führung
- Kopple Vergütung an Titel und Teamgröße, um Aufblähung zu fördern.
- Rede groß über Strategie, Features oder technische Komplexität.
- Tätige teure Übernahmen, um in neue Produktbereiche vorzudringen. Erwähne "Synergien". Stelle das übernommene Produkt ein.
- Verwende viele gestrichelte Berichtslinien in der Organisationsstruktur.
- Sorge dafür, dass möglichst viele Menschen an Manager in anderen Teams, Standorten oder Funktionen berichten. Sorge dafür, dass Manager ihre Reports nicht effektiv betreuen können.
- Versetze leistungsschwache Personen regelmäßig in andere Teams.
- Setze High Performer auf hochspekulative R&D-Projekte mit ungewissem Ergebnis an.
- Verlange für triviale Entscheidungen immer Meetings.
- Bestehe darauf, dass alle "Stakeholder" an Meetings teilnehmen müssen.
Recruiting
- Schaffe einen Einstellungsprozess, der oberflächlich objektiv wirkt, in Wirklichkeit aber subjektiv ist.
- Lehne Top-Talente wegen "mangelndem Cultural Fit" oder anderer vager Kriterien ab.
- Stelle die schwächsten Kandidaten wegen "Potenzial", "Einstellung" oder anderer vager Kriterien ein.
- Stelle sehr teure Senior-Führungskräfte mit großen Headcount-Zusagen ein.
- Nutze aufgeblähte Titel und künstlich geschaffene Rollen, um Opportunisten anzuziehen.
- Stelle hochspezialisierte "Experten" ein und schaffe dann künstliche Projekte, damit sie nicht kündigen.
- Nutze Spezialisierung als Rechtfertigung, weitere komplementäre Personen einzustellen.
Projektmanagement
- Verlange für jedes Projekt sehr detaillierte Schätzungen.
- Fördere Projekte über möglichst viele Teams hinweg, idealerweise über Teams an verschiedenen Standorten.
- Füge neue Anforderungen hinzu, die von Arbeit anderer Teams abhängen.
- Nutze häufig teure Agenturen. Halte den Scope vage und übergib unfertige Prototypen an interne Teams, damit sie sie fertigstellen.
- Baue komplexe "Self-Service"-Systeme für Stakeholder anderer Teams.
Ergebnis
- Produktivität zu senken ist schwer. Aber wenn man hinter den feindlichen Linien per Fallschirm als CTO landet, kann man es schaffen.
- Für nicht-destruktive Menschen: Das ist eine Geschichte darüber, wie man die Produktivität eines Teams maximal freisetzt. Produktivität entsteht aus vielen kleinen Dingen.
- Wenn 100 kleine Dinge jeweils 5 % Produktivitätssteuer verursachen, wird alles 131-mal langsamer. Wer Ingenieure glücklich halten will, muss 100 kleine, plausibel klingende Dinge ablehnen.
Meinung von GN⁺
- Dieser Artikel beschreibt auf humorvolle Weise verschiedene Methoden, die Produktivität in der Softwareentwicklung zu sabotieren. Dadurch wird klar, welches Verhalten man in der Praxis vermeiden sollte.
- Es ist wichtig, technische Schulden zu reduzieren und eine effiziente Entwicklungskultur aufrechtzuerhalten. Entscheidend ist, unnötige Komplexität und Bürokratie zu vermeiden.
- Es ist wichtig, ein Umfeld zu schaffen, das die Moral im Team stärkt und Zusammenarbeit fördert. Das wirkt sich direkt auf die Produktivität aus.
- Dieser Artikel hilft dabei, die Komplexität von Software Engineering und Management besser zu verstehen. Besonders für Junior Engineers bietet er nützliche Einsichten.
- Ähnliche Projekte mit vergleichbarer Funktion sind Bücher wie "The Phoenix Project", die sich damit beschäftigen, wie sich Effizienz in IT und DevOps steigern lässt.
11 Kommentare
Gibt es überhaupt Firmen, die das nicht so machen? schnief
Selbst kleine und erfolgreiche Firmen scheinen, sobald sie wachsen, am Ende alle so zu werden ...
Da ist so ziemlich alles dabei, was mir in früheren Firmen aufgetragen wurde: die erzwungene Nutzung einer Plattform, die man nicht einmal sinnvoll einsetzen kann ... standardisierte Leistungskennzahlen ignorieren ... Aufgaben noch einmal machen lassen usw.
Äh..?
Das ist komplett wie „Wie man so codet, dass die Wartung schwer wird: Auch du kannst als Entwickler ein Leben lang auf der faulen Haut liegen“...
Ich entscheide mich für Letzteres.
Ach … ach! .. aaah!! .. ach! … aaah ……
Es ist schade, dass sich einige dieser Dinge auch in unserer Organisation zeigen. schluchz schluchz
Das erinnert mich an das legendäre Buch "Wie man so programmiert, dass der Code schwer zu warten ist".
Ich auch dieses Buch!
Man könnte zwar denken: Wirklich so viel? Aber ich habe das Gefühl, dass all das von einer einzelnen Person oder einer einzelnen Organisation erreicht werden könnte.^^
Hacker News-Kommentare
Zweifel daran, ob der Vorschlag der CIA tatsächlich wirksam war: Ich habe nie einen überzeugenden Grund gesehen, warum der ursprüngliche Vorschlag der CIA tatsächlich funktioniert haben soll, und Organisationen neigen ohnehin dazu, solche Leute von selbst zu ignorieren.
Wie man ein Unternehmen ruiniert: Schlechte Leute in Managementpositionen zu befördern und sie Unrentables optimieren zu lassen, kann einem Unternehmen schweren Schaden zufügen.
Wie man ein destruktiver CTO wird: Es ist leicht, fast nichts zu tun, fähige Leute aus dem Weg zu räumen und eine Kultur zu schaffen, in der Verantwortung nach unten weitergereicht wird.
Arbeit über offizielle Kanäle und die Forderung nach schriftlichen Anweisungen: Für manche Menschen kann Arbeit über offizielle Kanäle und die Forderung nach schriftlichen Anweisungen produktiver sein.
Unterschied zwischen OSS und CIA: Das OSS (Office of Strategic Services) hat während des Zweiten Weltkriegs ein großartiges Buch erstellt, und die CIA wurde 1947 gegründet.
Die Bedeutung von Vision: Der wichtigste Schritt ist, Menschen zu entfernen, die eine konsistente Vision davon haben, wie das Produkt als Ganzes funktionieren sollte oder wie eine bessere Zukunft aussehen könnte.
Der Recruiting-Abschnitt muss aktualisiert werden: Man sollte verlangen, dass schwierige Leetcode-Probleme in 30 Minuten gelöst werden, und keine Unsicherheit oder Zweifel dulden.
Unterschied zwischen Produktions- und Entwicklerumgebung: In modernen Architekturen gibt es so viele externe Services, dass sich Produktions- und Entwicklerumgebung zwangsläufig unterscheiden, was bedeutet, dass Entwickler ständig mit dem Internet verbunden sein müssen.
Entscheidungen zum Selbstschutz: Viele Entscheidungen zur "Sabotage" hängen damit zusammen, Menschen davon zu überzeugen, dass man lediglich versucht, eigene Fehler zu verdecken.
"Best Practices" im Unternehmen: Die acht Regeln, die am Anfang des Artikels vorgestellt werden, werden im Unternehmen strikt als "Best Practices" befolgt.
Verhalten von Beratern: Viele Berater zeigen die meisten dieser Verhaltensweisen, wenn nicht sogar alle.
Probleme in der Tech-Branche: In der Tech-Branche gibt es viele Menschen, die sich so verhalten, und sie glauben, dass sie helfen.
Erfahrungen in Großunternehmen: Meine begrenzte Erfahrung in Großunternehmen deckt sich sehr stark mit dem Inhalt dieses Textes.