Deutsch

Camille Fournier Führungsstil: Das Playbook für technische Manager

Camille Fournier Leadership Profile

Steckbrief: Camille Fournier

  • Ehemalige CTO, Rent the Runway (2013–2017)
  • Managing Director & Head of Platform Engineering, Two Sigma
  • Autorin, „The Manager's Path" (O'Reilly, 2017) – meistverkauftes Engineering-Management-Buch
  • Beitragerin, „97 Things Every Engineering Manager Should Know"
  • Apache-ZooKeeper-Committer – Kernbeitragerin zum verteilten Koordinierungsdienst
  • Frühere Karriere: Managing Director, Goldman Sachs (Infrastructure Engineering)

The Manager's Path ist kein Wirtschaftsbuch über Vision oder Kultur. Es ist ein Handbuch – Kapitel für Kapitel, vom Tech Lead bis zum CTO –, das beschreibt, was der Job auf jeder Management-Stufe tatsächlich erfordert. 2017 veröffentlicht, wurde es das meistempfohlene Engineering-Management-Buch im Silicon Valley, weil es Fragen beantwortete, die kein anderes Buch gestellt hatte: Was tun Sie, wenn Ihr bester Ingenieur Manager werden möchte und wahrscheinlich nicht sollte? Wie managen Sie Skip-Level-Gespräche, wenn Ihre Directs selbst Manager sind? Was ist der tatsächliche Unterschied zwischen einem Director und einem VP of Engineering?

Camille Fournier schrieb es aus Erfahrung. Sie war von 2013 bis 2017 CTO von Rent the Runway – einem der am schnellsten skalierenden Fashion-Technology-Unternehmen jener Ära. Davor verbrachte sie Zeit bei Goldman Sachs als Managing Director für Infrastructure Engineering, was bedeutete, große Teams in einem der technologieabhängigsten Finanzinstitute der Welt zu managen. Früher in ihrer Karriere war sie eine wichtige Beitragerin zu Apache ZooKeeper, dem verteilten Koordinierungsdienst, der viele der Infrastruktursysteme unterstützt, die sie später in großem Maßstab managen sollte. Sie lernte Management-Theorie nicht in einer Business School. Sie lernte es, indem sie Ingenieure bei Goldman managte, ein Consumer-Technology-Unternehmen bei Rent the Runway skalierte und zu praxisnaher technischer Arbeit bei Two Sigma als Principal Software Engineer zurückkehrte.

Diese Kombination ist das, was ihre Frameworks bei Menschen zum Tragen bringt, die tatsächlich Engineering-Organisationen führen.

Analyse des Führungsstils

Stil Gewichtung Wie er sich zeigte
Strukturierter Mentor 55 % Fourniers primärer Beitrag ist, Engineering-Managern ein klares Bild davon zu geben, was ihr Job auf jeder Seniorität-Ebene ist – und was er kritisch gesehen nicht ist. Die meisten Engineering-Manager-Versagensmuster passieren, wenn Menschen weiter den Job ausführen, in dem sie gut waren, statt den Job, den sie jetzt ausführen sollen: der Tech Lead, der Manager wird, aber nicht aufhören kann, den gesamten Code zu schreiben; der Senior Manager, der weiter 1-on-1s mit Individual Contributors durchführt, statt seine Manager aufzubauen. „The Manager's Path" benennt diese Versagensmuster explizit, Ebene für Ebene, was sie besprechbar macht. Das ist die Mentor-Funktion: Menschen eine Karte geben, bevor sie sie brauchen.
Pragmatischer Systemsbaauer 45 % Fournier denkt über Engineering-Organisationen als Systeme mit identifizierbaren Inputs, Outputs und Versagensmustern nach. Ihr Goldman-Sachs- und Two-Sigma-Hintergrund zeigt sich darin, wie sie organisatorisches Design angeht: analytisch, mit Aufmerksamkeit auf Anreizstrukturen und Informationsflüsse. Ihre Schriften über Technical Debt behandeln es nicht als Code-Qualitätsproblem, sondern als Geschäftsrisikoproblem – so muss es gerahmt werden, um Budget zu erhalten. Das ist Systemdenken auf organisatorisches Management angewendet statt auf Software-Architektur.

Die 55/45-Aufteilung bedeutet, dass Fournier für Menschen am wertvollsten ist, die sich mitten in einem Management-Übergang befinden: von Individual Contributor zu Team Lead, von Team Lead zu Manager, von Manager zu Director. Ihre Frameworks handeln weniger vom Endziel als von den Übergängen. Will Larson setzt dort an, wo Fourniers Leiter endet – seine „Staff Engineer"-Archetypen adressieren den IC-Track, den „The Manager's Path" bewusst außen vor lässt.

Zentrale Führungseigenschaften

Eigenschaft Bewertung Was das in der Praxis bedeutet
Klarheit darüber, was jede Management-Ebene erfordert Außergewöhnlich Die meisten Organisationen befördern Menschen ins Management, ohne ihnen zu sagen, was der neue Job ist. „The Manager's Path" löst das, indem es jede Ebene spezifisch definiert: welche Entscheidungen Sie besitzen, für welche Beziehungen Sie verantwortlich sind, wie Erfolg aussieht und wie Versagen aussieht. Das Kapitel über „Managing Multiple Teams" handelt nicht von allgemeiner Führungstheorie. Es handelt vom spezifischen Job eines Directors, der andere Manager managt – einschließlich dem, wie man die Falle vermeidet, die Manager zu überspringen und ihre Arbeit selbst zu erledigen. Dieser Grad an Spezifizität ist selten in Management-Literatur.
Bereitschaft, Management-Versagensmuster offen zu besprechen Sehr hoch Fournier schreibt nicht über Management, wie die meisten Management-Bücher es tun – aspirational, fokussiert auf Erfolgsmuster. Sie schreibt über Versagensmuster: den technischen Manager, der nicht aufhören kann zu coden; den neuen Manager, der beste Freunde mit all seinen Reports wird; den CTO, der keine organisatorischen Entscheidungen delegiert, weil er seinem VP of Engineering nicht vertraut. Versagensmuster explizit zu benennen ist nützlicher als ideales Verhalten zu beschreiben, weil es Menschen eine Möglichkeit gibt, zu erkennen, wann sie einen Fehler machen, bevor er sich akkumuliert.
Technische Tiefe als Führungskraft beibehalten Hoch Die meisten Führungskräfte, die CTOs waren, hören auf, echten Code zu schreiben. Fournier kehrte zur Principal-Software-Engineer-Arbeit bei Two Sigma zurück, nachdem sie Goldman Sachs auf Managing-Director-Ebene verlassen hatte. Dieselbe Weigerung, von der technischen Arbeit abzudriften, ist bei Jeff Dean sichtbar, der weiterhin grundlegende Systemforschung bei Google lieferte, auch nachdem seine Arbeit definiert hatte, wie die Infrastruktur des Unternehmens skalierte. Das ist ein ungewöhnlicher Karriereschachzug: im Titel rückwärts, im technischen Engagement vorwärts. Es bedeutet, dass ihr Management-Ratschlag von jemandem geschrieben ist, der der Arbeit tatsächlich nahe geblieben ist.
Spezifizität über Abstraktion Hoch Fourniers Frameworks sind Checklisten und Entscheidungsbäume, keine Philosophien. Das 1-on-1-Framework sagt nicht „bauen Sie Rapport mit Ihren Reports auf." Es spezifiziert, was zu behandeln ist, welche Fragen welche Art von Informationen aufdecken, und wie man ein 1-on-1 unterscheidet, das gut läuft, von einem, das zu einem Status-Meeting wird. Das Technical-Debt-Framework sagt nicht „kommunizieren Sie technische Bedenken klar". Es gibt Ihnen die Übersetzung: So konvertieren Sie ein Code-Qualitätsproblem in ein Risiko- und Geschwindigkeitsproblem, über das ein CFO eine Budgetentscheidung treffen kann.

Die 3 Frameworks, die Camille Fournier definierten

The Manager's Path (Fournier Engineering Leadership Ladder)

The Manager's Path, auch Fournier Engineering Leadership Ladder genannt, ist eine Ebene-für-Ebene-Definition des Engineering-Management-Karrieretracks von Individual Contributor über Tech Lead, Manager, Senior Manager, Director, VP of Engineering bis zum CTO. Jede Stufe spezifiziert eine distinkte primäre Beziehung, Arbeitseinheit und ein benanntes Versagensmuster – meistens: den Job der vorherigen Ebene statt des aktuellen zu erledigen. Die Leiter ist das dominante Referenzmodell für Engineering-Management-Karrierepfade in modernen Software-Organisationen.

Die Management-Leiter

Das zentrale Framework von „The Manager's Path" ist einfach: Jede Ebene der Engineering-Management-Hierarchie hat einen distinct­en Job, und das häufigste Versagensmuster auf jeder Ebene ist es, den Job der vorherigen Ebene statt des aktuellen zu erledigen.

Fournier kartiert die Leiter spezifisch: Individual Contributor, Tech Lead, Manager von Individual Contributors, Senior Manager (Manager von Managern), Director, VP of Engineering, CTO. Jede Ebene hat eine andere primäre Beziehung und eine andere Arbeitseinheit. Die primäre Beziehung eines Tech Leads ist mit dem Code und dem Team. Die eines Managers ist mit Individual Contributors. Die eines Directors ist mit ihren Managern. Die eines VPs ist mit Organisationssystemen und Einstellungs-Pipelines. Die eines CTOs ist mit der technischen Strategie des Unternehmens und dem Vorstand.

Das Versagensmuster auf jeder Ebene ist gut definiert. Der Tech Lead, der Manager wird, schreibt weiter den gesamten Code und investiert nicht darin, seine Ingenieure besser zu machen. Der Manager, der Senior Manager wird, führt weiter 1-on-1s mit allen Individual Contributors durch, statt seine Manager aufzubauen. Der Director, der VP wird, trifft weiter individuelle Team-Ebene-Entscheidungen, statt Organisationsstrukturen zu gestalten. Jedes dieser Versagensmuster ist in der Praxis erkennbar, und sie zu benennen ist das, was sie korrigierbar macht.

Für Operatoren außerhalb des Engineering gilt das Leiter-Framework für jede Organisation mit Management-Hierarchie. Die Frage bei jeder Beförderung ist: Was erfordert der neue Job, was der alte nicht tat? Wenn man das nicht klar beantworten kann, befördert man Menschen in Rollen, die sie mit den Fähigkeiten füllen werden, die sie befördert haben – nicht mit den Fähigkeiten, die die Rolle braucht.

Das 1-on-1-Audit

Fournier ist spezifisch darüber, wozu 1-on-1s da sind und wozu nicht. Sie sind keine Status-Meetings. Sie sind keine Check-ins zum Projektfortschritt. Sie sind das primäre Werkzeug, das Manager haben, um frühzeitig vor Talent-Risiko, Karriere-Unzufriedenheit und Team-Dynamik-Problemen zu warnen, die in keinem anderen Format an die Oberfläche kommen.

Die spezifische Agenda, die sie empfiehlt, hat drei Teile. Karriere: Worauf arbeitet diese Person hin, und bewegt sie ihre aktuelle Arbeit darauf zu? Aktuelle Herausforderungen: Was steht ihr im Weg, und gibt es etwas, das nur Sie entfernen können? Team-Dynamik: Wie laufen die Dinge mit den Menschen um sie herum, und gibt es Reibungspunkte, die noch nicht an die Oberfläche gekommen sind?

Der Grund, warum die meisten 1-on-1s zu Status-Meetings werden, ist, dass Manager sich wohler fühlen, den Projektstatus zu besprechen, als direkte Gespräche über Karrierezufriedenheit oder Team-Reibungen zu führen. Status ist sicher. Die tatsächliche 1-on-1-Agenda deckt Probleme auf, die der Manager besitzen und beheben müsste. Fourniers Punkt ist, dass das Unbehagen die Information ist. In dem Moment, in dem ein Direct aufhört, Probleme in 1-on-1s zu erwähnen, hat man das Frühwarnsystem verloren. Wenn man es in einem Kündigungsbrief erfährt, hat man das Fenster zum Beheben bereits verloren.

Technical Debt als Geschäftsentscheidung

Fournier hat ausführlich über eines der häufigsten Versagensmuster für Engineering-Führungskräfte geschrieben und gesprochen: die Unfähigkeit, technische Bedenken in eine Sprache zu übersetzen, die Budget erhält.

Das Engineering-Framing von Technical Debt ist qualitätsorientiert: „Der Code ist unordentlich, er macht es schwer, Features hinzuzufügen, er erhöht das Risiko von Bugs." Dieses Framing ist wahr, aber für einen CFO oder CEO, der Ressourcenallokationsentscheidungen trifft, nutzlos. Das Business-Framing ist anders: „Diese technische Einschränkung verlangsamt unsere Release-Geschwindigkeit um etwa 30 % relativ zu dem, wo sie sein sollte, was unsere Fähigkeit verzögert, auf Marktveränderungen zu reagieren, und hier sieht das Risikoprofil aus, wenn wir es in den nächsten zwei Quartalen nicht angehen."

Fourniers Argument ist, dass CTOs, die diese Übersetzung nicht leisten können, nicht das Budget bekommen, das Problem zu beheben, was bedeutet, dass die Schulden sich anhäufen, was bedeutet, dass die Geschwindigkeitsstrafe wächst, was bedeutet, dass das nächste Budgetargument noch schwieriger zu gewinnen ist. Die Übersetzung handelt nicht davon, komplexe technische Themen zu vereinfachen. Es geht darum, sie in Bezug auf geschäftliche Konsequenzen neu zu rahmen: Zeit, Risiko und Geschwindigkeit. Das sind die drei Währungen, gegen die Führungskräfte tatsächlich allozieren. Gene Kim adressiert dasselbe Problem von der Betriebsseite – sein First Way of DevOps rahmt Deployment-Engpässe als Fluss- und Einschränkungsproblem, mit dem CFOs und COOs sich beschäftigen können, nicht nur Ingenieure.

Was Camille Fournier in Ihrer Rolle tun würde

Als CEO ist das Nützlichste, was Fournier bietet, eine Diagnose für die Management-Qualität Ihrer Engineering-Organisation. Die Frage ist nicht „haben wir gute Ingenieure?" Es ist „wissen unsere Engineering-Manager, was ihr Job ist?" Wenn Ihr VP of Engineering noch Director-Ebene-Arbeit erledigt (Teams direkt managen statt Manager managen), ist Ihre Director-Ebene-Kapazität atrophiert oder inexistent. Wenn Ihre Directors Tech-Lead-Arbeit machen, entwickeln sich Ihre Team Leads nicht. Das Leiter-Framework sagt Ihnen, wo das Management-System steckt, was Ihnen sagt, wo organisatorische Kapazität durch die falsche Ebene konsumiert wird, die Arbeit erledigt, die zur Ebene darunter gehören sollte.

Als COO gilt Fourniers 1-on-1-Framework für jedes Team mit einer Management-Hierarchie. Die Frage, die Sie Ihren Managern stellen sollten: Wann hat Sie zuletzt eine Kündigung überrascht? Wenn die Antwort „kürzlich" oder „regelmäßig" ist, führen Ihre Manager Status-Meetings, keine 1-on-1s. Das 1-on-1 ist das einzige Frühwarnsystem, das Manager für Talent-Risiko haben. Wenn sie es nicht nutzen, operieren Sie blind in der Bindung, bis Menschen die Tür verlassen.

Als Product Lead ist Fourniers Technical-Debt-Framework direkt nützlich. Sie stehen auf einer Seite des häufigsten organisatorischen Konflikts in Produktunternehmen: Engineering will Zeit, um Technical Debt zu reduzieren, und Product will Features. Der Grund, warum dieser Konflikt sich nicht löst, ist, dass keine Seite die Sprache der anderen spricht. Fourniers Framing – Debt in Geschwindigkeit und Risiko übersetzen – gibt Ihnen ein gemeinsames Entscheidungsframework. Statt „Engineering braucht Zeit für Technical Debt" gegenüber „Product braucht Features" können Sie fragen: „Was sind die Geschwindigkeitskosten, wenn wir das nicht angehen, und übersteigen sie die Opportunitätskosten der Verzögerung dieser Features?" Das ist eine Frage, mit der beide Seiten sich beschäftigen können.

In Sales oder Marketing gilt die Management-Leiter für Ihre eigene Organisation. Jeder Sales-Manager, der befördert wurde, weil er der beste Rep war, trägt das Risiko, Verkaufen statt Managen fortzuführen. Fourniers Framework gibt Ihnen eine Möglichkeit zu prüfen, ob Ihre Sales-Manager tatsächlich managen: Pipeline über ihr Team aufbauen, Reps entwickeln, die sich schwer taten, Prognosen erstellen, die das Urteil auf Team-Ebene widerspiegeln statt die persönlichen Deals des Managers. Das Versagensmuster ist dasselbe: für Fähigkeiten befördert, die auf der vorherigen Ebene funktionierten, nicht mit den Fähigkeiten ausgestattet, die die neue Ebene erfordert.

Wie Rework die Fournier-Leiter operationalisiert

Fourniers Leiter funktioniert nur, wenn Manager tatsächlich die Arbeitseinheit sehen können, die ihrer Ebene entspricht. Rework ist für diese Sichtbarkeit gebaut. Engineering-Management-Pipelines in Reworks Work Ops (ab 6 $/Nutzer/Monat) lassen Tech Leads und Manager die Lieferung auf ihrer eigenen Höhe verfolgen – ICs sehen Aufgaben, Manager sehen Team-Durchsatz, Directors sehen teamübergreifenden Fluss – ohne alle in dieselbe Ansicht zu zwingen. Karriereleiter-Templates können als strukturierte Checklisten pro Rolle modelliert werden, sodass die „Was erfordert diese Ebene tatsächlich"-Frage eine konkrete Antwort hat, auf die Ingenieure und Manager während 1-on-1s und Beförderungsreviews zurückgreifen können.

Bemerkenswerte Zitate und Lektionen jenseits des Boardrooms

Fournier hat in verschiedenen Vorträgen gesagt: „Die besten Engineering-Manager, die ich kenne, sind diejenigen, die Ihnen klar sagen können, wofür sie nicht verantwortlich sind." Das ist eine kontraintuitive Aussage. Die meisten Management-Ratschläge handeln von der Ausweitung der Verantwortlichkeit. Ihr Punkt ist über Klarheit: Ein Manager, der die Grenzen seiner Rolle nicht identifizieren kann, wird die Rolle mit dem füllen, womit er sich wohl fühlt – was normalerweise der Job ist, den er früher hatte.

Aus „The Manager's Path": „Als Manager ist Ihr Job, so wenig wie möglich zu tun." Sie klärt sofort: So wenig wie möglich bedeutet nicht minimaler Aufwand. Es bedeutet, dass der Job des Managers darin besteht, Bedingungen zu schaffen, in denen Ingenieure ihre beste Arbeit leisten können – nicht die Arbeit für sie zu erledigen. Jede Aufgabe, die ein Manager einem starken Ingenieur abnimmt, der sie hätte erledigen können, ist eine verpasste Entwicklungsgelegenheit und eine erhöhte Abhängigkeit vom Manager. Das Ziel ist ein Team, das gut funktioniert, wenn man nicht da ist.

Sie war auch in öffentlichen Schriften direkt über die Grenzen des Buches: „The Manager's Path" wurde für Produktunternehmen mit stabilen Engineering-Organisationen geschrieben. Sie hat anerkannt, dass das Leiter-Modell in stark matrixierten Organisationen oder Beratungsunternehmen kompliziert wird, wo Berichtslinien und Projektumfang sich ständig verschieben. Das ist kein Disclaimer. Es ist eine nützliche Grenze dafür, wann man das Framework anwenden und wann man es adaptieren sollte.

Wo dieser Stil scheitert

Fourniers Leiter-Modell funktioniert am saubersten in Produktunternehmen mit stabiler Management-Hierarchie: Unternehmen, die groß genug sind, um eine Director-Ebene zu haben, aber nicht so groß, dass das Organigramm Dutzende konkurrierender Berichtsstrukturen hat. In Beratungsunternehmen, Agenturen oder stark matrixierten Unternehmen, wo Berichtslinien sich mit jedem Projekt ändern, hat das „Hier ist, was der Job Ihrer Ebene ist"-Framing Schwierigkeiten, weil der Job nicht stabil genug ist, um präzise zu beschreiben.

Und die Tiefe des Buches zu einzelnen Management-Übergängen kann die Organisationsdesign-Fragen verschleiern, die auf der CTO-Ebene am meisten zählen: Team-Topologie, Platform-versus-Product-Engineering-Aufteilung, Build-versus-Buy-Entscheidungen. „The Manager's Path" wird Sie zu einem viel besseren Manager auf jeder Ebene unterhalb des CTOs machen. Auf der CTO-Ebene verschieben sich die Probleme von gutem People-Management zu Design des Systems, in dem sie arbeiten. Das ist ein anderes Buch.

Zur weiteren Lektüre über Engineering-Management und technische Führung empfehlen sich Will Larson Führungsstil, Gene Kim Führungsstil, Martin Fowler Führungsstil und Jeff Dean Führungsstil.