Anti-Patterns für Engineering-Führungskräfte

• Das häufigste Gesprächsthema mit CTOs oder Engineering-Führungskräften ist der Druck von CEOs, das Engineering-Tempo zu erhöhen
• Anders als bei Vertrieb oder Recruiting gibt es im Engineering keine klaren Leistungskennzahlen
• Für Engineering-Führungskräfte ist es schwierig, dem CEO zu sagen: „Engineering ist eine Kunst, daher sind Ergebnisse schwer vorherzusagen“
• Ursachen für Meinungsverschiedenheiten zwischen Engineering-Führungskräften und dem Management
  • Engineering-Führungskräfte neigen dazu, konventionelle Leadership-Ratschläge zu starr zu befolgen
  • Wenn man Praktiken pauschal als nützlich oder unnütz verallgemeinert, wird es schwierig, sie passend zur jeweiligen Organisation anzuwenden
  • Je nach Situation zu entscheiden, ob man einer Praxis folgt oder einen neuen Ansatz ausprobiert, ist der Kern effektiver Engineering-Führung
• Ein Artikel, der zusammenfasst, was Cartas CTO Will Larson in einem Podcast gesagt hat

Drei Anti-Patterns der Engineering-Führung

1. Mikromanagement vermeiden
2. Das Messen unvollkommener Metriken scheuen
3. Als Führungskraft ein Regenschirm für das Team sein

[Anti-Pattern #1: Mikromanagement vermeiden]

Drei widersprüchliche Rollen auf dem Weg zur besten Engineering-Führungskraft

• Eine Engineering-Führungskraft muss drei gegensätzliche Rollen erfüllen, und die besten Führungskräfte können geschickt zwischen ihnen wechseln
  • Rolle als Mitglied der Geschäftsleitung: Wege finden, das Geschäft voranzubringen
    • Manchmal muss man Entscheidungen treffen, die „für das gesamte Engineering schlecht“ sind, etwa Kürzungen des Engineering-Budgets
    • Dazu kann auch der Wechsel zu einem Geschäftsbereichsmodell gehören, in dem die Stimme des Engineerings zu bestimmten Themen weniger Gewicht hat
  • Rolle als Engineering-Manager
    • Die Struktur von Richtlinien verstehen, die für den Betrieb einer Engineering-Organisation nötig sind, und herausfinden, wie man eine effektive Führungskraft für Menschen wird
  • Rolle als Engineer
    • Verantwortung für technische Exzellenz und Engineering-Execution übernehmen, trotz äußerer Stressfaktoren
    • Die Messlatte für technische Exzellenz muss hoch bleiben
• Viele Führungskräfte neigen dazu, sich zu stark auf nur eine dieser drei Rollen zu konzentrieren
• Unabhängig davon, welche Rolle sie einnehmen, machen Führungskräfte Fehler, wenn sie an Management-Praktiken festhalten, die nicht mehr hilfreich sind
• Wenn man plötzlich Manager eines Teams wird, hat man technisch gesehen den meisten Kontext zu allem, was das Team tut, ist aber gleichzeitig auch People Manager
• In diesem Moment bekommen Menschen immer wieder den Rat, sich aus den Details zurückzuziehen
• Neue Engineering-Manager hören oft den Ratschlag, „raus aus dem Code“ zu gehen
• Es wird eingeräumt, dass dieser Rat für manche hilfreich sein kann
• Aber hochkompetente Führungskräfte haben ein gewisses Maß an Detailverständnis für die Domäne, die sie verantworten
• Wenn man sich zu weit von den Details entfernt, wird man nur zum Bürokraten – und das ist der Grund, warum so viele Engineering-Manager am Ende zu Bürokraten werden

Führungssstile entwickeln

• Larson rät Engineering-Führungskräften, den Begriff Mikromanagement ganz zu vergessen und sich stattdessen darauf zu konzentrieren, verschiedene Leadership-Stile zu entwickeln, zwischen denen sie wählen können
• Wenn es keinen klaren Weg nach vorn gibt oder Menschen mit Kontext zum weiteren Vorgehen heftig uneinig sind, hilft es, in die Details einzutauchen und selbst Entscheidungen zu treffen
• So kann man die Hebel verstehen, die das Geschäft tatsächlich verändern können, welche Ergebnisse das Team erreichen soll, in welchem Zeitraum dies geschehen soll und wie man Nutzern bessere Dienste leisten kann
• Mehr Sicherheit bei Entscheidungen zu entwickeln, ist eine lebenslange Übung, und Larson arbeitet nach eigener Aussage noch immer daran
• Fragen wie „Was tun wir? Warum tun wir es so? Was sind die Daten? Woher kommen die eigentlichen Daten?“ monatlich oder quartalsweise zu stellen, hilft dabei, tiefer in die Details einzusteigen

Zwei Taktiken, um näher an die Details zu kommen

1. Kontext durch „Konflikt-Mining“ erfassen

   • In einer neuen Umgebung kann schon das Übersehen kleiner Kontextunterschiede den operativen Erfolg beeinträchtigen
   • Auch wenn Gespräche mit Menschen mit gegensätzlichen Sichtweisen lange dauern, ist es wichtig, dabei die „Samen des Konflikts“ zu finden
   • Erfolgreiche Führungskräfte fragen: „Wie muss ich mich ändern, um zur Organisation zu passen?“, nicht: „Wie muss ich die Organisation ändern, damit sie zu meiner Art passt?“

2. Details dokumentieren

   • Strategie ist überall, wird aber fast nie dokumentiert
   • Oft wird die Begründung wichtiger Entscheidungen nicht festgehalten
   • Eine Kultur der Dokumentation aufzubauen, ist der Schlüssel für schnell agierende Engineering-Organisationen
   • Neue Führungskräfte sollten vor der Entwicklung einer eigenen Strategie zunächst alles Bestehende untersuchen und Erfolgsbeispiele anderer Unternehmen als Benchmark heranziehen
   • Für Strategiedokumente wird empfohlen, das Framework aus Richard Rumelts „Good Strategy, Bad Strategy“ zu nutzen
   • Selbst wenn eine Strategie schlecht geschrieben ist, kann sie sich über Nacht verbessern, allein dadurch, dass sie überhaupt dokumentiert wird

[Anti-Pattern #2: Das Messen unvollkommener Metriken scheuen]

• Im Bereich Measurement sind Anti-Patterns weit verbreitet
• Idealerweise könnte man einfach sagen: „Das sollten wir nicht messen“, aber damit verlangsamt man nur das Lernen in der umgebenden Organisation
• Eine der wertvollsten Aufgaben einer Engineering-Führungskraft ist es, andere Führungskräfte darin zu schulen, wie Engineering funktioniert

Auf die Verbesserung mentaler Modelle fokussieren

• Man wünscht sich, dass Metriken die Realität zeigen, aber Metriken sollen nicht nur Wahrheit abbilden, sondern auch Menschen weiterbilden
• Man sollte sich mehr darum sorgen, das mentale Modell des Boards oder des CEO zu verbessern, als darum, dass das eigene mentale Modell gekränkt wird

Den CEO in die Details hineinziehen

• Statt zu sagen: „Das ist eine schreckliche Art zu messen“, sollte man sagen: „Lass uns hier anfangen und so lange tiefer gehen, bis wir die Grenzen dieser Messmethode verstehen“
• Menschen mit Gewalt aus den Details herauszuhalten, ist nie ein guter Ansatz. Man sollte sie in die Details hineinziehen und dort schulen

[Anti-Pattern #3: Ein Regenschirm für das Team sein]

• Früher glaubte man daran, dass Manager wie ein „Regenschirm“ handeln sollten, um das Team zu schützen
• Aber ein Team vor der Realität abzuschirmen, schadet ihm langfristig
• Sowohl Manager als auch Engineers sollten an wichtigen Gesprächen teilnehmen können

Neue Perspektiven für strategische Entscheidungen nötig

1. Bottom-Up-Strategie
   • Vorteil: Das Team kann schnell handeln und die eingesetzten Tools kontrollieren
   • Nachteil: Es fehlt die Fähigkeit zu fokussierten Technologieinvestitionen, und Informationen kommen etwas verspätet an
2. Top-Down-Strategie
   • Nachteil: Es ist ineffizient, wenn der CTO oder eine Architekturgruppe alle Entscheidungen trifft
   • Gremien treffen nur selten die beste Entscheidung

Entscheidungen mit „Navigatoren“ beschleunigen

• Für jede Business Unit werden „Navigatoren“ eingesetzt, die als eine Art „Mini-CTO“ fungieren und die Entscheidungsfindung beschleunigen
• So können die Menschen mit dem meisten Kontext vor Ort die geeignetsten Entscheidungen über den Tech-Stack treffen
• Lehren für den Erfolg:
  1. Dokumentation nicht auslassen
  2. Im Nachhinein überprüfen
  3. Sehr sorgfältig auswählen, wem man vertraut
• Eine Organisation ist die Summe der Urteilskraft einiger weniger Personen, und daran kommt man nicht vorbei

Fazit

• Die Gefahr, Regeln zu strikt zu befolgen
  • Wenn Engineering-Teams gemeinsam mit dem Unternehmen zu wachsen beginnen, dürfen Führungskräfte nicht vergessen, was zuvor viele wohlmeinende Führungskräfte in Schwierigkeiten gebracht hat
  • Das ultimative Ziel ist es, einen hochwertigen Mechanismus dafür zu schaffen, dass Menschen neugierig bleiben und nach Ausnahmen suchen
• Learning Circle
  • Larson veranstaltet seit den vergangenen dreieinhalb Jahren alle zwei Wochen einen „Learning Circle“
    • 6 bis 10 CTOs, VPs of Engineering oder andere leitende Engineering-Führungskräfte aus Technologieunternehmen kommen zusammen, geben ein Update und tauschen sich über taktische und prozessbezogene Probleme aus
    • Jedes Treffen beginnt mit einer Runde von je einer Minute pro Person, in der alle sagen, worauf sie sich in dieser Woche konzentrieren und über welches Thema sie sprechen möchten
    • Nach etwa fünf Minuten zu den Themen wählt die Gruppe eines aus und geht dann ungefähr 20 Minuten lang in die Tiefe
    • Die Themen reichen von „Dieses Projekt bringt mich in Schwierigkeiten“ bis zu „Wir haben gerade eine wirklich großartige Person neu eingestellt und ich freue mich darauf“
• Lernen durch Praxis
  • Menschen, die durch Praxis lernen, können sich auf routinemäßige Reflexionen wie Learning Circles oder persönliche Selbstreflexion stützen, um die Selbstbetrachtung zu erzwingen, die nötig ist, um Regeln feinfühlig anzupassen
  • Larson sagt: „Ich bin zu einer besseren Führungskraft geworden, weil ich aus den Lektionen anderer gelernt habe, die ähnliche Fehler gemacht haben wie ich“

[geniuskey]

Der letzte Teil „Larson sagte: ‚Ich bin ... zu einer besseren Führungskraft geworden.‘“ ist mir etwas unangenehm. Stattdessen wäre es vielleicht angenehmer zu lesen gewesen, wenn es eher so formuliert worden wäre wie: „Eine Führungskraft sollte sich kontinuierlich bemühen, ... zu tun. Auch ich habe noch Defizite und arbeite daran, besser zu werden.“ Ist das vielleicht eine allzu koreanische Sichtweise? ^^;;

[savvykang]

Da Sie zu fragen scheinen, ob es sich um eine koreanische Perspektive handelt, kennen Sie sich offenbar gut aus. Meiner Ansicht nach zeigt der Sprecher keinen Narzissmus, daher finde ich diese Reaktion etwas befremdlich.

[tofumaker]

Es ist wirklich sehr koreanisch, sich nicht auf die Essenz oder den Inhalt eines Textes zu konzentrieren, sondern auf die Haltung des Sprechers.

[savvykang]

Es heißt „Anti-Pattern #1: Mikromanagement vermeiden“, aber dann soll man Mikromanagement vergessen — der Gedankengang ist etwas seltsam.

[frog08]

Es ist ein Anti-Pattern, Mikromanagement pauschal als etwas Schlechtes zu betrachten, das man vermeiden sollte. Statt zu urteilen, ob etwas Mikromanagement ist oder nicht, geht es darum, sich bei Bedarf um die Details zu kümmern.

[savvykang]

Wenn es zumindest als „Anti-Pattern: Mikromanagement als Option in Betracht zu ziehen“ oder „Auf Details zu achten und Mikromanagement für dasselbe zu halten“ formuliert worden wäre, hätte sich der Kontext etwas flüssiger gelesen. Die Absicht des Textes ist nachvollziehbar, aber letztlich ist die Botschaft wohl, dass man statt „Mikro“-Management ein Management betreiben soll, das auf Details achtet.

[kandk]

Wenn ich CTOs oder Engineering-Führungskräfte treffe, ist das häufigste Gesprächsthema der Druck des CEO, „die Engineering-Geschwindigkeit zu erhöhen“.
Anders als bei Vertrieb oder Recruiting gibt es im Engineering keine klaren Leistungskennzahlen.
Aus Sicht von Engineering-Führungskräften ist es schwierig, dem CEO zu sagen: „Engineering ist eine Kunst, daher ist Leistung schwer vorherzusagen.“

[xguru]

Siehe auch die Meinungen auf Hacker News zu diesem Artikel.

• Die Meinung, dass Will Larsons Methodik, die in mehreren Organisationen angewendet wurde, nicht besonders effektiv ist. Seine Methodik führt zu Konflikten zwischen Engineering und Business.
• Empfehlung für ein Buch von Ron Jeffries: Empfohlen wird The Nature of Software Development, das schrittweisen Mehrwert, von Engineers getriebene Entwicklung, kontinuierliches Feedback und Flexibilität betont.
• Positiv ist, dass Larson zur Selbstreflexion und Kritik fähig ist. Seine Texte sind nicht immer richtig oder falsch, aber er beschäftigt sich intensiv mit Problemlösungen.
• Aufgrund der Eigenschaften webbasierter Produkte sind Fehler nicht fatal, und häufige Änderungen erfolgen oft aus Marketinggründen. Daher hat sich eine Kultur entwickelt, die schnelles Handeln und das Zulassen von Fehlern begünstigt.
• Die positive Seite von Mikromanagement: Gute Engineering-Führungskräfte verstehen Details gut und können mit dem Team kommunizieren. Das ist etwas anderes als Mikromanagement.
• Zu viel technisches Personal verursacht Probleme. Mit besseren Tools dürfte auch ein kleines Team ausreichen, um die Arbeit zu erledigen.
• Nicht das Messen selbst ist das Problem, sondern dass auf Basis der Messergebnisse falsche Urteile gefällt werden. Metriken sollten als Werkzeug genutzt werden, um Fragen zu stellen.
• Der Kern großer Softwareentwicklung ist Zusammenarbeit. Der Zusammenbruch der Community ist ein Hauptgrund dafür, dass Projekte langsamer vorankommen.
• Wenn in der Entwicklungs-Pipeline die jeweiligen Rollen und Erwartungen nicht klar sind, entstehen Probleme. Manager müssen solche Situationen lösen.
• Die Meinung, dass es ein guter Artikel ist, aber noch besser wäre, wenn er um 25 % gekürzt würde.