Vom Engineer zum Manager: Was ich daran mag und was nicht
(thoughtspile.github.io)- Nach 7 Jahren als Frontend-Entwickler und dem Wechsel erst zum Team Lead und dann zum hauptberuflichen Engineering Manager ist der Einfluss auf Produkt und Team größer geworden, aber die Art der Arbeit hat sich stark verändert
- Ein Manager kann mit formaler und informeller Autorität in Probleme eingreifen, die sich als IC nur schwer ändern lassen, etwa Tests schreiben, Prozesse verbessern oder die Teamdynamik steuern
- Langfristig bringt die Karriere mehr Gehalt als typische Engineer-Stufen, breitere Chancen als staff+ IC-Rollen und übertragbare Fähigkeiten, die den Wechsel in andere Tech-Bereiche, ins Projektmanagement, Produktmanagement oder in die Gründung erleichtern
- Umgekehrt muss man unternehmensartige Prozesse wie Performance-Bewertungen, unrealistische Deadlines oder Organisationsrichtlinien durchsetzen und Konflikte, psychische Unsicherheit sowie den Druck ständiger Erreichbarkeit direkt selbst tragen
- Managementarbeit zeigt Ergebnisse oft nicht innerhalb eines Monats, und selbst richtige Veränderungen wie Teamaufteilungen oder Neueinstellungen können die Lage kurzfristig verschlechtern, sodass man lange Feedback-Loops aushalten muss
Der Weg vom Engineer zum Manager
- Vor etwa zwei Jahren bin ich zum Team Lead gewechselt und nach dem Wachstum des Teams hauptberuflicher Engineering Manager geworden
- Davor habe ich 7 Jahre als Frontend-Entwickler gearbeitet, zunächst die Laufbahn als erfahrener Individual Contributor (IC) gewählt und bin dann ins Management gewechselt
- Der Übergang war holprig, aber spannend, und an meiner aktuellen Arbeit gibt es Dinge, die ich mag, und Dinge, die ich nicht mag
Was ich an der Manager-Rolle mag
-
Die Autorität, Produkt und Team zu verändern
- Als Manager bekommt man die Autorität, den Gesamtzustand von Produkt und Team zu verbessern
- Als IC kann es schwer sein, Probleme wie frühe morgendliche Stand-ups, geringe Code-Qualität oder schwer verständliche neue Features zu verändern
- Ein EM kann durch formale und informelle Autorität steuern, dass das Team und man selbst besser arbeiten
- Selbst derselbe Satz wie „Wir sollten Tests schreiben“ hat ein anderes Gewicht, je nachdem, ob ihn ein IC oder ein EM sagt, und beim EM kann das tatsächlich dazu führen, dass Tests geschrieben werden
-
Breitere Karrieremöglichkeiten
- Ein Engineering Manager bietet breitere Karrieremöglichkeiten als die klassische Engineer-Laufbahn
- EMs verdienen in der Regel mehr als typische teambezogene Engineer-Stufen wie junior, middle oder senior
- Höhere IC-Stufen wie staff oder principal können zwar ebenfalls über EM-Niveau liegen
- Allerdings konzentrieren sich staff+ IC-Jobs eher auf große Tech-Unternehmen mit schwierigeren technischen Herausforderungen, während fast jedes Unternehmen mit einem Software-Team auch Führungspositionen hat
- Die Karriereleiter im Management reicht höher als die des IC
- Selbst wenn die Chance, CTO zu werden, gering ist, öffnet das Optionen, die einem reinen IC ohne Management-Erfahrung nicht offenstehen
- Die Nachfrage nach EMs ist stabiler als die nach staff+ Engineers und bietet auch später in der Karriere mehr Möglichkeiten
-
Fähigkeiten, mit denen man leichter in andere Bereiche wechseln kann
- Management-Fähigkeiten sind breiter einsetzbar als die vieler spezifischer IC-Engineering-Rollen
- Ein Frontend-Engineer mit React-Erfahrung kann zu einem anderen Frontend-Framework wechseln oder mit etwas Titelverlust in Backend- oder Mobile-Rollen gehen
- Mit Erfahrung als Engineering Manager ist es leichter, auch Teams mit anderem Fokus zu übernehmen, etwa ein Mobile-Entwicklerteam, ein Infrastrukturteam oder ein ML-Engineering-Team
- Man braucht zwar Zeit, um die großen technischen Schwierigkeiten eines neuen Teams zu verstehen, aber viele Unternehmen können solche Wechsel akzeptieren
- Wer nicht dauerhaft EM bleiben will, ist in einer guten Position für Rollen im Projektmanagement oder Produktmanagement
- Selbst wenn der gesamte Tech-Markt schwächelt, funktionieren viele Management-Fähigkeiten auch in anderen Branchen
- Erfahrung mit Menschen und geschäftlichen Entscheidungen ist auch als Vorbereitung auf eine Gründung nützlich
-
Wissen veraltet weniger schnell
- Wenn es ermüdend ist, ständig die neuesten Frontend-Frameworks und Tools zu verfolgen, kann eine Management-Rolle diese Last verringern
- „Neue“ agile-, Kanban- und Scrum-Methoden sind Konzepte, die schon 20 bis 30 Jahre alt sind, und grundlegende Meeting-Typen wie Demos, Dailys und 1:1s entwickeln sich seit Langem weiter
- Im Kern von Management stehen Teamarbeit und menschliche Interaktion, und daran hat sich seit den Anfängen der Menschheit nicht allzu viel geändert
- Man muss technologische Veränderungen weiterhin im Blick behalten, aber deutlich seltener unter Zeitdruck tief einsteigen
-
Neue Herausforderungen jenseits vertrauter technischer Probleme
- Wer 4 bis 5 Jahre in einem bestimmten technischen Bereich gearbeitet hat, kann die meisten praktischen Probleme dort irgendwann gut lösen
- Für erfahrene Engineers gibt es nur begrenzte Wege, größere Herausforderungen zu finden
- Den Stack nur leicht zu verändern, etwa durch ein neues Frontend-Framework, bleibt auf Dauer oft nicht spannend
- Ein größerer Wechsel wie vom Frontend ins Backend kann ein paar Jahre spannend sein, passiert aber eher zufällig oder wirkt sich auf die Vergütung aus
- Wenn man Probleme künstlich erzeugt, etwa alles mit einer neuen Library neu schreibt oder für die Zukunft 9000 RPS verarbeiten will, kann das zwar Spaß machen, ist für Team und Business aber oft schädlich
- Für erfahrene Engineers bietet der Wechsel ins Management die meisten neuen Lernfelder, ohne dass das Gehalt sinkt
Was ich an der Manager-Rolle nicht mag
-
Man muss unternehmensartige Prozesse durchsetzen
- Als Engineer mochte ich Corporate-BS wie individuelle Leistungsbewertungen, nutzlose Deadlines oder von der Firma erzwungene Prozesse und Tech-Stack-Beschränkungen nicht
- Als Manager wird man zu der Person, die solche Praktiken durchsetzt, ob man daran glaubt oder nicht
- In Organisationen mit Performance-Kalibrierung muss ein Team Lead alle sechs Monate eine Person benennen, die nicht hart genug gearbeitet habe
- Wenn man kein Teammitglied als Opfer liefert, kann später irgendjemand zufällig ausgewählt werden, was es schwer macht, den Prozess abzuschaffen
- Manche Verfahren lassen sich verhandeln oder umgehen, zum Beispiel indem „unter den Erwartungen“ per Round-Robin vergeben wird
- Aus Sicht des Teams kann der Manager dadurch manchmal wie ein Unternehmensmonster wirken
- Noch schwierigere Situationen wie Entlassungen, Schließungen oder Reorganisationen habe ich bisher nicht erlebt
-
Man muss Spannungen zwischen Menschen auffangen
- Ausgangspunkt auf dem Weg zum Engineering Manager war die Fähigkeit, Dinge gut zu bauen, und erwartet hatte ich Unterstützung bei technischen Entscheidungen, Karriereberatung, Prozessanpassungen und Automatisierung
- Ein großer Teil der tatsächlichen Arbeit besteht jedoch darin, soziale Spannungen und psychische Unsicherheit von Menschen zu debuggen
- Beispielsituation:
- Ein Junior-Engineer kommentiert einige Tests aus, um eine Feature-Vorschau deployen zu können
- Die QA-Verantwortliche ist wütend, weil sie das Gefühl hat, dass das Team die QA-Rolle und ihren Wert nicht respektiert
- Der Manager muss das Vertrauen wiederherstellen
- Noch ein Beispiel:
- Ein Projektmanager macht einen misslungenen Witz, und eine Designerin ist so verletzt, dass sie weint
- Der Manager muss dafür sorgen, dass der PM sich entschuldigt
- Ich bin weder Psychologe noch besonders gut im Umgang mit Menschen, deshalb fällt mir dieser Teil schwer und fühlt sich eher wie Durchhalten an, bis man sich daran gewöhnt
-
Eine Arbeitsstruktur, in der man schwer offline sein kann
- Das Leben eines Engineers kann vergleichsweise entspannt sein
- Wenn nichts Dringendes anliegt, kann man auch mal einen halben Tag draußen verbringen und über die Zukunft des Projekts nachdenken, und selbst das spontane Auslassen einiger Meetings ist manchmal kein großes Problem
- Wenn ein EM ein paar Stunden nicht erreichbar ist, stapeln sich die Probleme im Messenger
- Ein Praktikant hat vergessen, wie
npm installfunktioniert, und kann nicht weiterarbeiten - Ein Senior Manager will ein mögliches Feature besprechen
- Ein Release läuft schief
- Ein Praktikant hat vergessen, wie
- Meetings, die man selbst leitet oder organisieren muss, lassen sich ohne Vorbereitung nur schwer ausfallen lassen
- Wenn das Team reifer wird und die Prozesse besser werden, kann sich das verbessern, aber generell spüren Manager Office Hours deutlich stärker
- Die Work-Life-Balance hängt direkt von der eigenen Fähigkeit ab, die Arbeit gut zu bewältigen
-
Feedback-Loops sind lang und nicht linear
- Die meisten Engineering-Aufgaben zeigen Ergebnisse relativ schnell
- Bei neuen Features sieht man die Auswirkungen in einigen Wochen bis Monaten, und nach einem Bugfix kann man oft schon am nächsten Tag die Reaktion der Nutzer sehen
- Bei einem Refactoring kann man innerhalb weniger Stunden erkennen, dass die Komplexität gesunken ist
- Handlungen eines Managers führen nur sehr selten innerhalb eines Monats zu sichtbaren Ergebnissen
- Wenn ein Team zu groß geworden ist und aufgeteilt werden muss, sind dafür viele Schritte nötig
- die richtige Zusammensetzung der Engineers für das neue Team festlegen
- mit den Beteiligten über ihre Gefühle zu der Veränderung sprechen
- neue regelmäßige Meetings einrichten
- Prozesse und Kommunikation aufsetzen
- Jira-bezogene Aufgaben erledigen
- gegebenenfalls die Codebasis eines Teilprodukts abtrennen
- Wer glaubt, das in einer Woche erledigen zu können, liegt falsch
- Selbst richtige Veränderungen können erst einmal alles verschlechtern, bevor es besser wird
- Wenn wegen Personalmangels neue Leute eingestellt werden sollen, kostet das kurzfristig viel Zeit für Interviews, und neue Teammitglieder sind nicht sofort produktiv, sondern brauchen Onboarding
- Management-Veränderungen ähneln eher einem großen Refactoring als einer schnellen Problemlösung, und es kann frustrierend sein, wenn keine unmittelbare Verbesserung sichtbar ist
Für Engineers, die über den Wechsel nachdenken
- Der Wechsel vom IC-Engineer ins Management ist eine Achterbahnfahrt mit hellen und dunklen Seiten
- Die Vorteile sind ein größerer Einfluss auf Produkt und Team, mehr Chancen und Flexibilität als langfristiger Karrierepfad sowie neue Herausforderungen, wenn man sich im technischen Bereich zu langweilen beginnt
- Die Nachteile sind das Durchsetzen von Unternehmensrichtlinien, der Umgang mit sozialen Spannungen und psychischer Unsicherheit, eine Arbeitsstruktur, in der man schwer offline sein kann, sowie stark verzögerte Befriedigung und lange Feedback-Loops
- Wer Herausforderungen und Verantwortung mag und die Gelegenheit hat, sollte es ausprobieren
- Management passt nicht zu allen, kann aber eine Erfahrung sein, die den eigenen technischen Horizont erweitert und einen neue Blickwinkel auf Engineering-Arbeit gewinnen lässt
- Und wenn es am Ende doch nicht passt, bleibt immer noch genug Zeit, zum Coden zurückzukehren
1 Kommentare
Hacker-News-Kommentare
Ich war viermal Manager, darunter zweimal bei FAANG, aber ich stimme dem Original in vielen Punkten nicht zu.
Die Manager-Laufbahn ist in Wirklichkeit nicht höher, und die meisten Engineering Manager ballen sich ungefähr auf dem Niveau von L6/Staff Engineer. Beförderungen zum Senior Manager und darüber hinaus hängen stark von den Umständen ab und sind selten, während Kollegen auf der Engineering-Laufbahn befördert werden, sobald sie bereit sind, statt auf eine günstige Sternenkonstellation warten zu müssen.
Leute, die reine Engineering Manager waren und entlassen wurden, suchen oft noch immer nach einem Job und stehen kurz davor aufzugeben, aber für Menschen, die auch als IC zurückkehren können, ist die Jobsuche kein großes Problem. Führungskultur unterscheidet sich von Firma zu Firma stark und lässt sich nicht leicht direkt übertragen, und ich halte in dieser Branche Linux-Interna für die am besten übertragbare Fähigkeit.
Auch die Vorstellung, man könne mit 5 Jahren Erfahrung die meisten Probleme lösen, wirkt seltsam. Ich arbeite seit 18 Jahren und habe immer noch vieles, das ich nicht weiß oder worin ich besser werden muss, und selbst hervorragende Ingenieure mit 40 Jahren Erfahrung lernen weiterhin dazu.
Das Beste am Manager-Dasein ist, dass man viel Zeit damit verbringt, über die Zukunft nachzudenken, und eher in „den Raum“ kommt, in dem mit der C-Ebene gesprochen wird. Gleichzeitig ist das auch das Schlimmste, weil man viel zu gut sieht, wie Entscheidungen zustande kommen.
Den Punkten, die das Original nicht mochte, stimme ich zu, aber mit der Zeit wird es besser. Wenn man allerdings ein neuer Manager ist, hat man womöglich den Punkt noch nicht erlebt, den man am meisten hassen wird: dass sich das obere Management vieler Firmen wie Highschool-Cliquen verhält und problematisches Verhalten von VPs, der C-Ebene und manchmal Direktoren toleriert wird, obwohl normale Mitarbeiter dafür entlassen würden.
Die meisten Softwareingenieure bleiben auf Senior-Niveau hängen, besonders bei Google, daher ist es schon ein relatives Privileg, überhaupt in einer Umgebung zu sein, in der sich Leute bei L6 sammeln. Beförderungen zu L6 sind nicht extrem selten, aber auch nichts, was die Mehrheit bekommt, und L7 oder höher ist schwierig. Wenn es sich anfühlt, als kämen die meisten Kollegen ganz natürlich dorthin, dann wurden womöglich die Leute ausgeblendet, die ohne Beförderung gegangen sind, oder man hatte wenig Gelegenheiten, mit Menschen auf niedrigeren Levels befreundet zu sein.
Ich stimme zu, dass der Weg zum Engineering Manager nicht so viele Türen öffnet, wie früher oft angenommen wurde, aber die Beförderungsmöglichkeiten wirken auf mich nicht enger als für ICs.
Etwas von 0 auf 1 aufzubauen hat fast nichts mit Engineering Management zu tun. Am wichtigsten ist die Fähigkeit, schnell Code zu schreiben und entspannt mit potenziellen Kunden zu sprechen, und beides hängt nicht direkt mit der Rolle eines Engineering Managers zusammen. Es gibt auch keine Garantie, dass man überhaupt Leute einstellen wird, die man dann managen kann.
Management-Positionen sind strukturell viel seltener als Engineering-Rollen, und weil die Grenze zwischen Lead Engineer und First-Line-Manager in beide Richtungen ziemlich unscharf ist, wird der tatsächliche Wettbewerbspool dadurch auch nicht entsprechend kleiner.
Mit Übertragbarkeit ist gemeint, dass es Fähigkeiten sind, die auch außerhalb der Big-Tech-Blase nützlich sind. Vielleicht will man wegen des Geldes nicht raus, aber es ist gut zu wissen, dass man auch etwas anderes tun kann, als Computer piepsen zu lassen.
So ging es mir etwa bei der Vorstellung, dass die Aussage „Wir müssen mehr testen“ ernster genommen wird, wenn sie von einem Engineering Manager kommt statt von einem IC.
Tatsächlich hatte ich, als ich gerade erst als IC auf Staff-Niveau befördert worden war, auch das Gefühl, dass mir Glaubwürdigkeit fehlt, und wollte teils ins Management wechseln, weil es helfen könnte, mich hinter einem Titel zu verstecken. In Wirklichkeit war das nicht nötig, und heute werden meine Gedanken und mein Feedback als IC in einer anderen Firma sowohl auf Organisationsebene als auch von Kollegen ernst genommen.
Ein System, in dem man halbjährlich zwangsweise Rankings erstellt und Minderleister auswählen muss, ist kaputt. Performance Management hat an vielen Orten diese traurige Realität, aber es ist keine allgemeingültige Wahrheit, dass es für Manager zwangsläufig so sein muss. Schwierige Gespräche über echte Leistungsprobleme lassen sich statistisch nicht vermeiden, aber es gibt auch Firmen, in denen man keine Gespräche führen muss wie „In diesem Halbjahr waren alle Teammitglieder besser als Sie“ oder „Irgjemanden mussten wir auswählen, und diesmal hat es Sie getroffen“.
Ich mag Problemlösung und das große Ganze und arbeite gern Lösungen aus und beseitige Hindernisse. Die Rolle, die am besten zu mir passte, war die des „Architekten“, aber als Titel scheint sie zunehmend zu verschwinden. Das ändert jedoch nichts daran, dass diese Arbeit weiterhin nötig ist
Ich war auch schon Team Lead/Manager, Scrum Master und Produktmanager, aber die Fähigkeiten, die ein guter Manager braucht, unterscheiden sich stark von denen eines Engineers. Der Kern ist extrem niedriger Neurotizismus, also die Fähigkeit, unter lang anhaltendem Stress gute Entscheidungen zu treffen und nach außen ruhig und rational zu bleiben
90 % der unteren Führungskräfte haben diese Eigenschaft nicht, und unter Stress richten sie im Team und im Unternehmen Schaden an. Wenn du Manager werden willst, solltest du ehrlich einschätzen, wie du auf lang anhaltenden Stress reagierst. Ob du Leute in deinem Umfeld anfährst, dich zurückziehst oder erstarrst und keine Entscheidungen mehr treffen kannst, oder ob du anderen die Schuld gibst, um deinen Ruf zu schützen — diese scheinbar banalen Faktoren machen in Wahrheit den Unterschied zwischen effektiven Managern und allen anderen aus
Meistens gehört dazu die unangenehme Arbeit, Probleme anzusprechen, die alle anderen vermeiden, Menschen ihren kollektiven Unmut über meine Entscheidungen auslassen zu lassen und auch dann weiter dranzubleiben, wenn die andere Seite disengaged und auf Distanz geht
Für mich fühlte sich Management so an, als würde es alle Löffel verlangen, die ich habe, und dann noch mehr. Ich denke aber, das ist weniger das Wesen von Management als vielmehr eine Frage der Passung zu mir. Laut Internettests liege ich beim Neurotizismus im Mittelfeld, aber ich bin schlecht darin, bei „gut genug“ aufzuhören, und der erweiterte Verantwortungsbereich im Management erzeugt für mich emotional ein Skalierungsproblem
Vielleicht liegt der Schlüssel zur Lösung von Crunch und Burnout darin, ein regulatorisches Umfeld zu schaffen, in dem der gesamte Lebensunterhalt von Beschäftigten — Gesundheit, Miete, Rückzahlung öffentlicher Studienkredite usw. — nicht allein vom Erhalt eines einzigen Jobs abhängt
Als IC kann man seine Karriere ausbauen, indem man neue Technologien oder Fachgebiete lernt, aber bei Managern hängt die berufliche Entwicklung zunehmend von persönlichem Wachstum ab — Reife, Perspektive, emotionale Widerstandskraft. Das könnte auch erklären, warum mit wachsender Seniorität oft auch das Interesse an Achtsamkeitsmeditation und ähnlichen Dingen zunimmt
HN wird das nicht mögen, aber obwohl ich selbst ledig bin, frage ich mich auch, ob Eltern nicht bessere Manager werden, vielleicht weil sie im großen Ganzen seltener wegen Unwichtigem die Perspektive verlieren und sich stressen lassen. Seltsamerweise scheint man Management am besten zu machen, wenn man emotional einen Schritt zurücktritt
Ich mache mir persönlich Sorgen, dass ich vom Temperament her ziemlich empfindlich bin und für Management verfassungsmäßig ungeeignet sein könnte. Auch die mitunter heuchlerische Natur von Dingen wie „nicht steuern, sondern motivieren“ fällt mir schwer. Ich möchte einfach durch Organisationen ziehen, Probleme beheben, Prozesse vereinfachen und Arbeitssysteme neu gestalten
Ich bin seit 12 Jahren Software Engineer, habe aber überhaupt kein Interesse daran, Manager zu werden. Ich will einfach Dinge bauen, nicht managen
Ich arbeite eng mit Managern zusammen und sehe, was der Job ist, aber er wirkt auf mich überhaupt nicht attraktiv. Als Senior Engineer hat meine Stimme oft ebenfalls Einfluss, aber ohne die enorme Verantwortung, die ein Manager trägt, und das gefällt mir. Ich will den Stress in meinem Leben nicht noch weiter erhöhen
Wahrscheinlich werde ich auch in den nächsten 30 Jahren meiner Karriere in einer ähnlichen Rolle bleiben
Vor ein paar Jahren war es bei mir ähnlich. Mein Chef mochte mich, und durch mein Netzwerk wurde jede Information mit mir geteilt, ich saß bei Entscheidungen mit am Tisch, man fragte mich nach meiner Meinung zur Richtung, und wenn nötig, sagte mein Chef, er würde mich unterstützen, wenn ich für ihn oder andere Manager sprechen müsse
Jetzt gibt es eine komplett neue Führungsstruktur, sehr top-down, mit viel Ego und ohne Bereitschaft, Feedback anzunehmen. Untere Manager und Engineers, die ihre Stimme erheben, wurden immer weiter an den Rand gedrängt, und die Autonomie und Mitsprache, die ich hatte, sind fast vollständig verschwunden
Sogar viele Dinge, die ich für Engineering-Entscheidungen hielt, wurden mir entzogen. X wurde für einen Service, den ich baue, benötigt, also habe ich dafür eine automatisierte Lösung gebaut, und sie funktionierte gut. Ein paar Monate später wurde mir gesagt, ich hätte falsch gehandelt, weil es für X andere Pläne gebe, und ich sollte die vollautomatisierte Lösung löschen und sie durch einen manuellen Unternehmensprozess eines anderen Teams ersetzen. Diese Arbeit wird oft nicht erledigt, was die Zuverlässigkeit meines Services verschlechtert
Ich bin froh, dass ich nicht der Manager bin, der sich mit solchen Leuten anlegen muss. Wäre ich es, hätte ich den Job wahrscheinlich inzwischen verloren und wäre durch einen ihrer Freunde ersetzt worden. Trotzdem kann sich der Einfluss eines Senior Engineers auch innerhalb desselben Unternehmens und Teams langfristig stark verändern
Es gibt auch höhere technische Rollen mit wenig oder gar keiner Führungsverantwortung. Senior Principal Engineer, Architekt und Ähnliches — es hängt davon ab, wie wertvoll dich das Unternehmen einschätzt
Das beste Beispiel, das ich gesehen habe, war ein Engineer mit Doktortitel und jahrzehntelanger Erfahrung, der als Forschungs-/Architektur-Guru arbeitete, keine Teams und keine Direct Reports hatte, viel Matlab nutzte und in einem Unternehmen mit mehreren hundert Mitarbeitenden „VP of technology“ war
Das Schwierige sind nicht nur das Lernen oder die Menschen selbst, sondern die Umstände drum herum. Eine Management-Perspektive zu haben, ist sehr hilfreich, um zu verstehen, was gebaut wird und warum, und warum Arbeit ineffizient und kaputt wirkt. Man gewinnt auch Einblicke in Lösungen und in den Kontext, der oft nicht richtig vermittelt wird
Ich bin derzeit Senior-Entwickler und führe Gespräche für eine Team-Lead-Position in einem Startup. Ich halte mich selbst für technisch stark, aber was mich im Alltag am meisten frustriert, sind Probleme rund um Teamwork.
Mangelndes Vertrauen, Teammitglieder, die ungern miteinander reden, andere Seniors, die Arbeit unter Niveau einfach durchgehen lassen, das Fehlen eines klaren Teamziels und einer Produktvision sowie mangelnde Einigung auf gemeinsame Engineering-Praktiken. Wenn man People Manager wird, fallen solche Probleme im Guten wie im Schlechten in den Bereich, auf den man Einfluss nehmen und für den man Verantwortung tragen soll.
Als ich dann tatsächlich Team Lead wurde, war der Bereich, in dem ich Einfluss ausüben konnte, viel kleiner als gedacht. Es gibt viele Leute, einschließlich meines Vorgesetzten, die alles selbst steuern wollen und von mir nur erwarten, den Stempel aufzudrücken.
Stattdessen ist es noch unangenehmer, weil ich die Themen ansprechen muss, die die Leute im Team sich nicht zu sagen trauen. Zum Beispiel: „Damit eine Story ready ist, muss die API definiert sein.“ Wie soll QA parallel automatisierte Tests bauen, wenn nicht einmal klar ist, was getestet werden soll?
Scrum Master, Product Owner, Manager und Architekten sagen jeden Tag das, was ihnen gerade passt, als wäre es eine selbstverständliche Wahrheit, und beschweren sich am nächsten Tag darüber, warum die Tests zu spät sind.
Am Ende landet man bei der Politik darüber, wer für den aktuellen Zustand verantwortlich ist, und die Leute, die diese Richtung und Strategie gewählt haben, sind gut vernetzt und können Verantwortung gut abschieben.
Früher stand ich im Büro meines damaligen Chefs, nachdem er erfolgreich ein Telefonat beendet hatte, in dem er jemanden aus einer anderen Abteilung um etwas gebeten hatte.
Er blickte von seinem Schreibtisch zu mir auf, lächelte leicht und sagte in einem verwunderten Ton: „Dadurch, dass mein Titel von ‘Specialist’ zu ‘Manager’ gewechselt hat, bin ich nicht hübscher geworden, aber es hilft definitiv dabei, Dinge erledigt zu bekommen.“ Das war ein Moment, in dem die Macht des Titels tatsächlich wirkte.
Ein Manager wird leicht einfach ignoriert, solange er nicht mit echten Nachteilen droht, und so eine Karte sollte man sparsam ausspielen.
Ich habe vor ein paar Jahren als CTO eines kleinen Startups angefangen, Engineering Manager zu sein, und mein Leben hat sich stark verändert. Bei allem, was der Originaltext als geliebt und gehasst beschreibt, empfinde ich genau dasselbe.
Mein zusätzlicher Rat ist, wirklich zu meditieren. Bevor man wichtige und einflussreiche Entscheidungen trifft, die anderen schaden könnten, sollte man lange genug still dasitzen, bis das Gehirn praktisch abschaltet.
Am Anfang wird es zu einer Art Eltern-Kind-Genie-Beziehung. Man muss die Menschen annehmen und verstehen, wie sie funktionieren. Je mehr Kontrolle man aufbaut, desto weniger tatsächliche Kontrolle hat man. Die Leute werden unnötige Bürokratie umgehen und sich dagegen wehren, und ehrlich gesagt würde ich das auch tun.
Der zweite Rat ist, immer so zu handeln, als würdest du morgen gehen. Dann sind Team und Kollegen vorbereitet, und die eigene Lebensweise verbessert sich ebenfalls.
Sie wachsen daran wirklich schnell, und es ist seltsam beruhigend zu sehen, dass die Organisation auch ohne mich funktioniert. Gleichzeitig scheinen sie zu wachsen, wenn ich nicht da bin, also frage ich mich manchmal, ob das ein Zeichen ist, dass ich etwas falsch mache.
An manchen Tagen habe ich das Gefühl, mit den Fähigkeiten aus dem Job meine Familie zu managen.
Mein Hintergrund ist das Gegenteil. Ich bin ein durchschnittlicher Software Engineer, aber im Umgang mit Menschen ziemlich gut.
Ich habe genug Erfahrung, um zu wissen, was Zeit kostet und welche Teile eines Systems wichtiger sind. Es gibt einige Senior Engineers, die wirklich zuhören und viel Vertrauen und Entscheidungsspielraum geben.
Die Designentscheidungen treffen nicht ich, sondern sie, und ich bringe nur meine Meinung ein. Wenn es scheitert, übernehme ich Verantwortung und lerne daraus, und wenn es gelingt, bekommt das Team die Anerkennung. Auch wenn das bescheiden klingt: Ich denke, die Managerrolle dreht sich vor allem um Menschen.
Es gibt nur einen einzigen Grund, warum ich aus einer Coder-/IC-Rolle in die Management-Laufbahn wechseln möchte: die Whiteboard-Interviews, die bei jedem Jobwechsel wieder nötig sind.
Man muss sich fast schmerzhaft jedes Mal wieder von Grund auf vorbereiten. Es gibt zwar Rollen ohne diesen Prozess, aber sie sind sehr selten. Wenn ich an diese Vorbereitung denke, denke ich oft nur: „Ach bitte, nicht schon wieder“, und bleibe dann einfach im selben Job.
Ein schlechter Engineering Manager kann viel mehr Schaden anrichten als ein schlechter IC. Ich finde nicht, dass darüber oft genug gesprochen wird.
In einer langen Karriere hatte ich einen großartigen Manager, ein paar ordentliche und viele miserable. Miserable Manager machen die Arbeit deutlich schwerer und manchmal vollständig unerquicklich.
Die Kombination aus einem schlechten Engineering Manager und einem Junior-IC kann besonders übel sein. Als ich älter wurde, habe ich gelernt, dass man auch mit schlechten Managern arbeiten und die Situation in eine bessere Richtung bewegen kann oder, wenn es hoffnungslos erscheint, eben gehen.
Ich frage, weil meine Management-Verantwortung gerade wächst.
Ich habe einmal ein Team geführt, das aus promovierten ICs bestand. Ich musste ihnen Arbeit verschaffen, Träumer abwehren und dafür sorgen, dass sie zufrieden blieben.
Kein Witz: Ich habe manchmal sechs Stunden am Stück einzeln mit ihnen gesprochen und dabei die Rolle von Karriereberater und Tröster übernommen. Ich hätte nie gedacht, dass so etwas zu meinem Job gehören würde.
Eines der Teammitglieder half dabei, zwei separate Verträge im Wert von jeweils 1 Milliarde Dollar zu gewinnen, also hat sich meine Zeit wohl ausgezahlt.