Egoless Engineering: Lehren und Einsichten
Einleitung
- In der Tech-Branche sind Ego und Partikularismus (Lagerdenken) zentrale Faktoren, die Teamarbeit behindern
- Hier werden Einsichten geteilt, die aus der Frage entstanden sind, wie sich Engineering-Teams effizienter und kooperativer aufstellen lassen
Das Dilemma der Aufgabenverteilung
- Schon mit nur zwei Mitarbeitenden ist die Verteilung von Arbeit unvermeidlich
- Die Art der Verteilung kann jedoch unmittelbare und langfristige Auswirkungen haben
- Viele Unternehmen setzen sich mit diesem Problem nicht besonders tiefgehend auseinander
Die Realität der Informatik
- Viele Informatiker erkennen erst später, dass sie in ein Fach eingestiegen sind, das mit mathematisch-abstrakter Arbeit zu tun hat
- Dieser anfängliche Schock führt oft dazu, dass sie das Gelernte im weiteren Verlauf ihrer Laufbahn kaum auf Bereiche außerhalb des Computers anwenden wollen
- Würde man über das Arbeitsumfeld so tief nachdenken wie über technische Ansätze, ließe sich vieles verbessern
Organisatorische Missstände und Erfahrungen
- Selbst erfolgreiche Unternehmen können sich organisatorischen Fehlentwicklungen kaum entziehen, und man kann aus ihnen lernen
- Beispiel aus einem Startup aus der frühen Karriere:
- Obwohl das Unternehmen noch in einer kleinen Frühphase war, wurde bereits eine übermäßig bürokratische Struktur eingeführt
- Aufgrund einer falschen Theorie zur Beschleunigung von Web Requests wurde ein „Python-Middleware“-Layer eingefügt
- Das führte letztlich zu mehr Network Hops und damit zu schlechterer Performance
- Um ein einzelnes Feature auszuliefern, war komplexe Zusammenarbeit über mehrere Rollen hinweg nötig
- Datenbankverantwortliche schrieben DDL und entwickelten Stored Procedures
- Python-Entwickler arbeiteten an der ineffizienten Middleware
- PHP-Entwickler schrieben den Frontend-Code
- Durch diese Arbeitsteilung konnte über zwei Jahre hinweg kein einziges neues Feature veröffentlicht werden
- Ergebnis
- Infolge der ineffizienten Struktur und der Workflows wurden schließlich alle Mitarbeitenden entlassen
- Ich nicht. Ich habe überlebt, weil ich mich beschwert habe
Probleme der Rollendifferenzierung in großen Unternehmen
- Hintergrund: Arbeit in einem B2B-Produktunternehmen mit mehr als 1.000 Mitarbeitenden
- Anfangs gab es eine Struktur aus funktional klar getrennten Feature Teams und gemeinsamen Service-Teams (Operations, DBA usw.)
- Zunächst wirkte das wie ein ganz normales Setup
- Mit der Zeit wurden die Rollen jedoch übermäßig ausdifferenziert, und die Ineffizienz nahm zu
- Es wurde eine neue Rolle namens „Release Manager“ eingeführt, um Releases zu steuern
- Der Grund für diese zusätzliche Rolle war unklar, und die Organisationsstruktur wurde immer komplexer
- Beispiel für das Problem:
- Frontend-Ingenieure durften nur Frontend-Arbeit machen, Backend-Ingenieure nur Backend-Arbeit
- Diese Trennung war zwar irgendwie überlebensfähig, doch die Vorgabe, dass das Security-Team sämtliche Security-Arbeit übernimmt, führte zu schwerwiegenden Problemen
- Ergebnis: Die Gleichsetzung von Rolle und Aufgabe schadete der organisatorischen Effizienz
- Mangelnde Zusammenarbeit zwischen Teams und doppelte Arbeit waren die Folge
Ein fragmentiertes Produktportfolio und fehlende Aufsicht
- Arbeit in einem Unternehmen, das hauptsächlich native Client-Applikationen entwickelt
- Anfangs gab es eine erfolgreiche Kern-Client-Anwendung, doch in den 2020er Jahren liefen fragmentierte und inkonsistente Projekte parallel nebeneinander
- Probleme beim Management des Produktportfolios
- Es gab nur schwache Aufsichtsstrukturen über das Gesamtportfolio
- Zwischen den Produkten fand keinerlei Abstimmung bei Tech Stacks oder Entscheidungen statt
- Jedes Produktteam berichtete unabhängig direkt an den CEO, der keine Koordinationsanstrengungen unternahm
- Versuch, gemeinsame Operations-Funktionen aufzubauen
- Schwierigkeiten entstanden, weil die Operations-Gruppe nicht in Architekturentscheidungen eingebunden war
- Das Operations-Team war damit beschäftigt, Hunderte von Services zu verwalten, die Entwicklungsteams in der Vergangenheit aufgebaut hatten, und hatte daher keine Zeit, an wichtigen Entscheidungen mitzuwirken
- Das ist ein typisches Beispiel für organisatorische Ineffizienz
[Muster organisatorischer Probleme verallgemeinern]
Muster 1: Verwechslung von Rolle und Aufgabe
- Es gibt die Tendenz, für neue Arbeit gleich neue Stellenbeschreibungen zu schaffen
- Beispiel: Obwohl bestehende Engineers AI-bezogene Aufgaben übernehmen könnten, wird eine neue Rolle namens AI Engineer geschaffen
- Das erzeugt Konflikte in der Organisation und kann die Motivation bestehender Teammitglieder schwächen
- Diese überzogene Rollentrennung führt zu unnötiger Bürokratie
Muster 2: Die unvollständige Verbreitung der DevOps-Revolution
- Viele Unternehmen behaupten, sie hätten „DevOps eingeführt“, doch in der Praxis bestehen Arbeitsteilung und Konflikte weiter
- Klare Grenzen zwischen Operations und Entwicklung oder zwischen SRE und Entwicklung behindern die Zusammenarbeit
- Der eigentliche Zweck von DevOps ist es, Grenzen durch Kooperation und Empathie aufzulösen, doch in der Realität wird das nur selten erreicht
Muster 3: Die Grenzen strikter Arbeitsteilung
- Arbeit zu zerlegen und zu spezialisieren, kann Führungskräften ganz selbstverständlich erscheinen
- Beispiel: AI-Arbeit geht an AI-Spezialisten, Operations-Arbeit an Operations-Verantwortliche
- Doch eine solche Struktur erzeugt Engpässe
- Zusätzliche Engineers sollen durch neue Arbeit das Tempo erhöhen, doch stattdessen steigen die Wartezeiten für Analysen nichtlinear an
- Wenn Data Scientists oder Analyse-Ressourcen an ihre Grenzen kommen, verlangsamt sich der gesamte Prozess
Muster 4: Falsche Organisationsstrukturen erzeugen zusätzliche Arbeit
- Wenn organisatorische Grenzen unklar oder falsch gezogen sind, nimmt die unnötige Arbeitsmenge zu
- Beispiel: Das Security-Team bearbeitet alle Security-Probleme, wodurch eine Queue aus Security-Tickets entsteht
- Entwicklungsteams arbeiten, ohne Security mitzudenken, und dadurch wächst die Menge an Security-Arbeit weiter
- Kurzfristig lässt sich das vielleicht ignorieren, langfristig entwickelt es sich jedoch zu einem ernsten Problem
Muster 5: Hartnäckige menschliche Vorurteile
- Menschen neigen dazu, die eigene Rolle zu überschätzen und die Rolle anderer zu unterschätzen
- Manche halten Server-Arbeit fälschlicherweise für „nicht technisch“
- Umgekehrt ist auch die Annahme verbreitet, Produktarbeit sei weniger technisch
- Solche Haltungen schwächen das Vertrauen zwischen Teams und behindern Zusammenarbeit
- „Brillante schwierige Charaktere“ liefern aus systemischer Sicht oft keinen echten Wert
- Führungskräfte und Organisationen bewerten solche Haltungen dennoch häufig fälschlich als „klug“ oder „wertvoll“
[Partikularismus und Ego]
- Partikularismus und Ego sind Hauptursachen organisatorischer Ineffizienz
- Partikularismus: die Haltung, sich nicht in die Domäne anderer einzumischen, oder ein Mangel an Neugier
- Ego: Stolz auf die eigene Arbeit kann positiv wirken, zeigt sich aber auch negativ als Revierdenken oder als Unterschätzung der Fähigkeiten anderer
- Diese instinktiven Verhaltensweisen führen zu mangelnder Empathie und behindern Zusammenarbeit
Das bessere Beispiel: Erfahrungen mit erfolgreichen Engineering-Teams
- In einem früheren Startup wurde eine horizontal getrennte „Fiefdom“-Struktur vereinfacht und in kleinere Teams umgebaut
- Führungskräfte, die DevOps ernsthaft einführten, rissen Barrieren ein und förderten Zusammenarbeit
- Durch etwa zwei Jahre „schöpferischer Zerstörung“ wurden alle Teammitglieder in unterschiedliche Aufgaben einbezogen
- Dadurch wurden sowohl die Stabilität der Infrastruktur als auch die Fähigkeit zur Software-Auslieferung wiederhergestellt
- Nach der Umstrukturierung gewann das Engineering-Team Zeit und Autonomie
- Auf dieser Grundlage wurde diskutiert, wie die zusätzlichen Kapazitäten des Teams sinnvoll eingesetzt werden könnten
Vorschlag 1: Groß angelegtes Refactoring (Proposition 1: Boil the Ocean)
- Teams nutzen freie Ressourcen oft dafür, ungeliebte Bereiche umfassend zu refaktorieren
- Das war jedoch ein bereits erprobter und unbeliebter Ansatz
Vorschlag 2: Aktivitäten zur „Selbstdarstellung“ (Proposition 2: Dress Like Big Dorks)
- Es wurde versucht, die freie Zeit des Teams für Dinge wie Merchandise zu nutzen, das die Teamkultur betont
- Als Hauptstrategie eignete sich das jedoch nicht
- Der entscheidende Vorfall: ein Build-Fehler durch eine Designerin
- Mitten in der Nacht zerstörte eine Designerin den Build, und das Team musste ihn wiederherstellen
- Zunächst wurde vorgeschlagen, die Rollen von Designern und Codern noch klarer zu trennen
- Stattdessen traf eine Person im Team die mutige Entscheidung, der Designerin direkt den Deployment Key zu geben
- Ergebnis:
- Die Designerin beteiligte sich an der Code-Arbeit, und das Niveau der Zusammenarbeit stieg
- Das Team baute Monitoring, eine Test Suite und weitere Mechanismen auf, um eine sichere Arbeitsumgebung zu schaffen
- Arbeitseffizienz und Produktivität verbesserten sich deutlich
Vorschlag 3: Die Fähigkeiten anderer Teams stärken (Proposition 3: Empower Everybody Else)
- Es wurde die Strategie gewählt, freie Kapazitäten des Teams dafür einzusetzen, andere Teams zu unterstützen und zu befähigen
- Das galt sowohl für technische als auch für nichttechnische Teams
- So wurden Zusammenarbeit in der gesamten Organisation gefördert und effektivere Umsetzung ermöglicht
Umsetzungswille
- Nach dem Fall mit der Designerin wurden in der Zusammenarbeit mit verschiedenen Gruppen ähnliche Erfolge erzielt
- Die freie Zeit des Teams und seine organisatorische Handlungsfreiheit wurden genutzt, um andere Teams bei effektiver Zusammenarbeit zu unterstützen
- Erfolgreiche Umsetzung beruhte auf unternehmensweiter Kooperation und Empathie
[Wie sich erfolgreiche Umsetzung anfühlt]
- Experten vs. Eigentümer
- Teams haben Domain Experts, aber keine „Eigentümer“ bestimmter Aufgaben oder Domänen
- Security-Beispiel: Statt dass das Security-Team alle Probleme bearbeitet, trägt das gesamte Team Verantwortung für Security, während das Security-Team die Fähigkeiten der anderen Teammitglieder stärkt
- Dieses Modell hätte auch in anderen Bereichen angewendet werden sollen, wurde aber von den meisten Teams nicht umgesetzt
- Negativbeispiel
- Strikte Trennung von Frontend- und Backend-Ingenieuren
- Mangelnde Zusammenarbeit führte zu unnötiger Komplexität wie GraphQL
- Spezialisten für bestimmte Rollen sind nötig, aber Titel strikt in „Frontend“ und „Backend“ zu trennen, ist ineffizient
- Kernprinzip:
- „Domain Experts, nicht Eigentümer“
- Spezialisten sollten dazu befähigt werden, sich Zeit zu nehmen, auch anderen Teammitgliedern außerhalb ihrer eigenen Arbeit zu helfen
Proaktive Zusammenarbeit fördern
- Freiräume schaffen
- Teammitglieder erhalten bewusst Freiraum, um die Gesamtzusammenarbeit im Team aufrechtzuerhalten
- Statt einfach auf natürliche Kooperation zu warten, bringt man absichtlich Dynamik ins System
- Psychologische Sicherheit und Erweiterung der Ingroup
- Menschen fühlen psychologische Sicherheit in Gruppen, zu denen sie sich zugehörig fühlen, und lernen oder experimentieren dort eher
- Es wird Zeit und es werden Ressourcen investiert, um die „Ingroup“ der Teammitglieder zu erweitern
- Bootcamp: Vorübergehende Arbeit in anderen Teams schafft Gelegenheiten zur Zusammenarbeit
- Hackathon: kann als Veranstaltung mit ähnlicher Wirkung genutzt werden
Bewusste Teamwerte
- Philosophie und Prinzipien des Teams festlegen
- Die übergeordneten Ziele von Code Reviews, Bootcamps, Hackathons und ähnlichen Aktivitäten werden klar definiert
- Elitismus wird ausdrücklich als Gift bezeichnet
- Es wird eine Kultur geschaffen, in der alle „die nötige Arbeit selbst erledigen“
- Gegenseitiges Vertrauen und Erwartung von Verbesserung
- Es wird die starke Erwartung gesetzt, dass man die Arbeit anderer stets in einem besseren Zustand hinterlässt
- Eine solche Kultur ermutigt Teammitglieder, bereitwillig zusammenzuarbeiten
Abschließende Gedanken
- Probleme der Tech-Branche: Elitismus und dogmatische Führung
- Dogmatische Führungskräfte ohne Bescheidenheit behindern Teamarbeit und fördern unnötige Grausamkeit
- Die Tech-Branche hält solche dogmatischen Führungskräfte oft fälschlich für nützlich, doch das ist ein parasitäres und schädliches Phänomen
- Es sollte nicht radikal sein, andere mit Respekt zu behandeln, aber in der Realität ist es das oft doch
- Zusammenarbeit führt zu besseren Ergebnissen
- Zusammenarbeit verbessert die Resultate, und ein Leben ohne dogmatische Führungskräfte ist besser
- Es braucht Anstrengungen, um Partikularismus und Ego abzubauen
- Die Bedeutung von Empowerment
- Damit Teammitglieder neugierig bleiben und kooperieren, brauchen sie Erlaubnis und Unterstützung durch Führungskräfte
- Beispiel: Deployment-Aufgaben werden nicht mehr nur von SREs, sondern direkt von Entwicklern übernommen
- Anfangs gab es Sorgen wegen möglicher Fehler der Entwickler, doch die meisten lösten Probleme selbstständig, und der Ansatz funktionierte
- Produkt-Engineers zeigten die Haltung, Probleme selbst anfassen und lösen zu wollen
- Dem System Slack geben
- Programme wie Bootcamps oder Hackathons brauchen dauerhafte Verbindlichkeit
- Ohne Slack im System verschwinden solche Programme leicht wieder
- Computer betreiben wir nicht dauerhaft bei 100 %, aber bei uns selbst versuchen wir es oft
- Die Bedeutung von Werten und Belohnung
- Führungskräfte sollten Zusammenarbeit und Neugier belohnen und beides in der Teamkultur verankern
- CEOs neigen oft dazu, positive Programme wie Bootcamps oder Hackathons zu streichen, unternehmen aber zu wenig gegen negative Programme wie verpflichtende Code Reviews
- Der falsche Glaube, dass „Leid“ Ergebnisse hervorbringt, muss aufgegeben werden
- Leid ist kein geeigneter Proxy für Ergebnisse; Zusammenarbeit und Vertrauen führen zu besseren Resultaten
7 Kommentare
> Damit Teammitglieder mit Neugier zusammenarbeiten, brauchen sie die Erlaubnis und Unterstützung der Führungskraft
Es scheint sehr wichtig zu sein, Teammitglieder dazu zu ermutigen, auch für die Bereiche ihrer Kolleginnen und Kollegen Neugier zu entwickeln, selbst wenn es nicht der eigene Zuständigkeitsbereich ist!
Die Realität ist ...!
In einem hyperagilen Startup, das jeden Tag auf Fortschritt drängt, ist so eine Struktur wohl unmöglich..
Alle Mitarbeitenden in der Praxis müssten die anfängliche Begeisterung nach dem Eintritt ins Unternehmen aufrechterhalten können, aber Unterstützung in dieser Hinsicht gibt es meist gar nicht oder sie ist unzureichend.
Alles stimmt Wort für Wort..
Aber die Realität ist.................. T_T
Scheint wirklich ein sehr guter Text zu sein!
Ein guter Text.
Hacker-News-Kommentar
Es gibt die Ansicht, dass es in der Softwareentwicklung wichtig ist, das Ego des Programmierers auszublenden. Wünschenswert ist es, Softwareprodukte durch Teamarbeit als Leistung des Teams zu betrachten.
Als Lehren aus der Entwicklungskarriere wird geraten, keine unnötigen Prozesse hinzuzufügen, in jeder Rolle Ownership für das Produkt einzufordern, reaktive Entscheidungen zu vermeiden und die Zusammenarbeit zwischen Teams zu fördern.
Die besten Teams bestehen aus Pizza-Teams, die den gesamten Stack verantworten, und Spezialisten, die bei Bedarf Beratung leisten.
Sportmetaphern sind im Tech-Bereich nicht beliebt, aber es gibt die Ansicht, dass die Dynamik von Sportteams guten Business-Teams ähnelt.
Der Erfolg einer Organisation hängt davon ab, dass jedes Mitglied altruistisch handelt, um die Bedürfnisse der Gruppe zu erfüllen.
Die Bedeutung einer bewusst festgelegten Teamkultur wird betont.
Bei der Arbeit in einem Growth-Team wurden anfangs alle Commits vom Manager geprüft und gemergt, später stellte sich jedoch heraus, dass man selbst die Berechtigung hatte, direkt in Production zu deployen.
Domain-Experten werden gegenüber Domain-Ownern bevorzugt, und eine zu explizite Spezialisierung kann Probleme verursachen.