The Staff Engineer's Path – Zusammenfassung und Einordnung

Einleitung

Hohpes Architekt fährt mit dem Aufzug durch eine große Organisation. Reillys Buch beschreibt eine verwandte, aber moderner organisierte Rolle: den Staff Engineer, also einen sehr erfahrenen Entwickler, der Einfluss über sein Team hinaus hat, ohne Personalverantwortung zu tragen. In vielen Unternehmen ist das die Fortsetzung der technischen Laufbahn neben dem Weg ins Management.

Autorin und Kontext

Tanya Reilly arbeitete lange bei Google, unter anderem als Site Reliability Engineer, und danach als Principal Engineer bei Squarespace. Bekannt wurde sie durch einen Vortrag und Text mit dem Titel Being Glue von 2019, über die unsichtbare Arbeit, die Teams zusammenhält, die aber in Beförderungen oft nicht zählt. Das Buch erschien 2022 bei O’Reilly.

Es gehört zu einer kleinen Gruppe von Büchern über technische Laufbahnen jenseits des Managements, neben Will Larsons Staff Engineer von 2021, das eher aus Interviews und Rollenbeschreibungen besteht. Reillys Buch ist das praktischere der beiden.

Die Kernthese

Ab einer bestimmten Stufe wird ein Entwickler nicht mehr dafür bezahlt, selbst den besten Code zu schreiben, sondern dafür, dass die Organisation bessere technische Ergebnisse erzielt. Das gelingt durch Überblick, durch das Vorantreiben schwieriger Projekte und dadurch, andere besser zu machen. Die Rolle ist unscharf, unterscheidet sich von Firma zu Firma und muss deshalb von jedem Staff Engineer selbst geklärt und gestaltet werden.

Aufbau

Das Buch ist gut lesbar, mit vielen Beispielen, Checklisten und Fragen zur Selbstreflexion.

Was Staff Engineers tun

Warum es die Rolle gibt

In großen Organisationen gibt es Arbeit, die kein einzelnes Team erledigt: Entscheidungen, die mehrere Teams betreffen, Probleme, die zwischen Zuständigkeiten liegen, Wissen, das niemand weitergibt. Manager kümmern sich um Menschen und Ressourcen, aber oft nicht tief genug um technische Zusammenhänge. Staff Engineers füllen diese Lücke.

Drei Säulen

die drei Säulen der Staff-Rolle nach Reilly, nachgezeichnet

Das Fundament ist technisches Können. Ohne es fehlt Glaubwürdigkeit; aber es allein reicht für die Rolle nicht.

Die Rolle klären

Reilly betont, dass „Staff Engineer“ in jeder Firma etwas anderes bedeutet. Sie schlägt Fragen vor, mit denen man seine Rolle mit dem Vorgesetzten klärt:

Will Larson beschreibt vier typische Ausprägungen, die Reilly aufgreift: Tech Lead eines Teams, Architekt für einen Bereich, Löser für besonders schwierige Probleme und rechte Hand einer Führungskraft.

Unsichtbare Arbeit

Aus ihrem bekannten Text Being Glue übernimmt Reilly den Begriff Klebearbeit: Dinge, die Teams zusammenhalten, etwa Protokolle schreiben, Abhängigkeiten klären, neue Kolleginnen einarbeiten, Missverständnisse auflösen. Diese Arbeit ist wertvoll, wird aber in Bewertungen oft übersehen, und sie fällt häufiger Menschen zu, die ohnehin weniger Sichtbarkeit haben. Für Staff Engineers ist sie ein zentraler Teil der Rolle; für andere kann sie die Karriere bremsen, wenn niemand sie anerkennt.

Einordnung

Die drei Säulen entsprechen Hohpes drei Standbeinen Können, Wirkung und Führung. Die Klebearbeit ist das, was DeMarco und Lister bei Menschen beschreiben, die Teams zusammenhalten und in keiner Produktivitätsmessung auftauchen.

Drei Karten

Um Überblick zu gewinnen, schlägt Reilly ein Bild vor: Ein Staff Engineer braucht drei Karten, die er für sich selbst zeichnet und laufend aktualisiert.

Die Standortkarte

Sie hilft, den eigenen Blickwinkel einzuordnen. Reilly warnt davor, das eigene Team für den Mittelpunkt der Welt zu halten. Fragen dazu: Was ist das Ziel der Organisation, und welchen Beitrag leistet mein Bereich? Was würde sich ändern, wenn mein Team verschwände? Welche Probleme halten alle für wichtig, und welche werden übersehen?

Die Geländekarte

Diese Karte ist am schwierigsten, weil sie nirgends dokumentiert ist. Sie beschreibt das inoffizielle Organigramm: wer tatsächlich Entscheidungen beeinflusst, wem man zuhört, wo man Unterstützung bekommt, welche Themen heikel sind, wo Gräben verlaufen. Reilly rät, sie durch Gespräche zu zeichnen: mit Leuten aus anderen Teams essen gehen, in Besprechungen zuhören, fragen, wie frühere Entscheidungen zustande kamen. Das ist Hohpes Rat, Organisationen rückwärts zu verstehen.

Die Schatzkarte

Sie zeigt das Ziel. Oft gibt es keine, oder sie ist unklar, oder es gibt mehrere, die sich widersprechen. Dann ist es eine Aufgabe des Staff Engineers, sie zu zeichnen oder an ihrer Klärung mitzuwirken. Daraus entsteht der Übergang zum nächsten Kapitel: technische Vision und Strategie.

Einordnung

Die drei Karten sind ein einfaches, gut merkbares Werkzeug, besonders nach einem Stellenwechsel oder einer Umorganisation. Die Geländekarte entspricht dem, was Team Topologies als tatsächliche Kommunikationsstruktur gegenüber dem formalen Organigramm beschreibt.

Das große Bild: Vision und Strategie

Zwei Dokumente

Reilly unterscheidet zwei Arten von Dokumenten, die oft verwechselt werden:

Der Kern einer Strategie

Für Strategien greift Reilly auf Richard Rumelts Buch Good Strategy Bad Strategy zurück. Eine gute Strategie hat drei Teile:

Eine schlechte Strategie ist dagegen oft nur eine Liste von Zielen oder eine Sammlung wohlklingender Begriffe ohne Diagnose. Rumelt nennt das „Fluff“.

Der Weg zum Dokument

Reilly beschreibt drei Phasen:

1. Vorbereitung: Braucht es überhaupt ein Dokument? Gibt es einen Sponsor, also jemanden mit Entscheidungsbefugnis, der es will? Ohne Sponsor bleibt jede Strategie ein privates Hobby. Welches Problem genau soll es lösen? Wer schreibt mit?
2. Schreiben: Gespräche mit vielen Beteiligten führen, Ideen sammeln, Entwürfe schreiben und früh teilen. Vor wichtigen Besprechungen einzelne Personen vorab einbinden, damit niemand überrascht wird. Reilly verwendet dafür den japanischen Begriff Nemawashi: den Boden bereiten, bevor man pflanzt.
3. Einführen: Das Dokument offiziell machen, also von der richtigen Stelle bestätigen lassen; es bekannt machen; und danach darauf achten, dass Entscheidungen tatsächlich daran ausgerichtet werden.

Langweilig ist gut

Ein bemerkenswerter Rat: Eine gute Strategie wirkt oft langweilig. Sie beschreibt das Offensichtliche, das alle irgendwie wussten, aber nie aufgeschrieben und vereinbart haben. Ihr Wert liegt darin, dass danach alle in dieselbe Richtung arbeiten.

Vorlage für eine kurze technische Strategie

Das ist Hohpes Rat zum Schreiben für Beschäftigte und die Struktur eines ADR auf größerer Ebene.

Begrenzte Zeit: woran arbeiten?

Ein Staff Engineer sieht mehr Probleme, als er lösen kann. Die wichtigste Fähigkeit ist deshalb, auszuwählen. Reilly beschreibt Auswahl nicht als Zeitmanagement, sondern als Umgang mit mehreren begrenzten Ressourcen.

Die Ressourcen

Jede Aufgabe verbraucht einige dieser Ressourcen und füllt andere auf. Gute Auswahl hält das Gleichgewicht.

Fragen vor dem Ja

Bevor man eine Aufgabe übernimmt, schlägt Reilly sinngemäß solche Fragen vor:

• Ist es wichtig? Trägt es zu einem Ziel der Organisation bei, oder ist es nur dringend oder interessant?
• Ist es meine Aufgabe? Oder sollte ein Team das tun, und ich nehme ihm eine Lernchance?
• Bin ich die richtige Person? Gibt es jemanden, für den es eine größere Chance wäre?
• Was gebe ich dafür auf? Jede Zusage bedeutet, etwas anderes nicht zu tun.

Typische Fallen

Will Larson beschreibt in seinem Text Work on What Matters Fallen, die Reilly ähnlich aufgreift:

Dagegen steht, was Larson als besonders wirkungsvoll beschreibt: an Problemen arbeiten, die wichtig sind und von anderen vernachlässigt werden, und anderen helfen, erfolgreich zu sein.

Einordnung

Das ist DeMarcos und Listers Warnung vor zersplitterter Zeit, angewandt auf die eigene Person. Die Unterscheidung von wichtig und dringend kennt man aus der Eisenhower-Matrix, die Martin in Clean Architecture verwendet.

Große Projekte führen

Teamübergreifende Projekte sind der typische Arbeitsgegenstand eines Staff Engineers: unklar, politisch, mit vielen Beteiligten und ohne fertigen Plan.

Der Anfang

Reilly beschreibt den Anfang eines solchen Projekts ehrlich: Man fühlt sich überfordert, alles ist unklar, und alle erwarten, dass man weiß, was zu tun ist. Ihr Rat: Das Gefühl ist normal, und der erste Schritt ist, Klarheit für sich selbst zu schaffen.

• Kontext sammeln: Warum gibt es das Projekt? Wer will es? Was ist schon versucht worden?
• Erfolg definieren: Woran erkennen wir, dass das Projekt gelungen ist?
• Sponsor und Beteiligte kennen: Wer entscheidet, wer liefert zu, wer ist betroffen?
• Die Rolle annehmen: Wenn man das Projekt führt, soll man es auch ausdrücklich führen, nicht abwarten, dass jemand anderes es tut.

Rollen klären

In teamübergreifenden Projekten ist oft unklar, wer was entscheidet. Reilly empfiehlt, Rollen früh ausdrücklich festzulegen, etwa mit einer einfachen Tabelle: Wer ist verantwortlich, wer muss zustimmen, wer wird gefragt, wer wird informiert? Unklare Zuständigkeiten sind eine der häufigsten Ursachen für Stillstand.

Entwurfsdokumente

Ein großer Teil der Arbeit eines Staff Engineers ist Schreiben. Reilly gibt Ratschläge für Entwurfsdokumente und RFCs:

Sie warnt vor zwei Fehlern: Dokumente, die so allgemein sind, dass niemand widersprechen kann, und Dokumente, die so lang sind, dass niemand sie liest. Ein gutes Entwurfsdokument lädt zu Widerspruch ein, solange er noch billig ist.

Das Projekt steuern

Während des Projekts wechselt ein Staff Engineer zwischen Tätigkeiten: erkunden, klären, entwerfen, selbst programmieren, kommunizieren, Hindernisse aus dem Weg räumen. Besonders wichtig ist regelmäßige, ehrliche Kommunikation über den Stand: Wer Probleme früh benennt, bekommt Hilfe; wer sie versteckt, bekommt später eine Krise.

Einordnung

Die Vorlage ist eine Erweiterung des ADR aus Fundamentals und Nygards Vorschlag. Nicht-Ziele entsprechen Hohpes Betonung statt Vollständigkeit: Was man ausdrücklich ausschließt, macht klar, was gemeint ist.

Warum stockt das Projekt?

Eines der praktischsten Kapitel: Projekte bleiben stecken, und oft weiß niemand genau, warum. Reilly unterscheidet mehrere Formen und gibt für jede Gegenmittel.

Formen des Stillstands

Fertig ist nicht fertig

Reilly betont besonders das Problem des Fast-Fertig: Ein neues System, das gebaut, aber nicht eingeführt ist, hat keinen Nutzen und erzeugt Kosten, weil das alte weiterläuft. Daraus entstehen Hohpes Zombies. Ein Projekt ist erst fertig, wenn das Ziel erreicht ist, nicht wenn der Code steht. Das ist die Definition von „fertig heißt ausgeliefert“ aus Continuous Delivery, auf organisatorische Ebene erweitert.

Eskalieren ohne Drama

Eskalation hat einen schlechten Ruf, ist aber oft der richtige Weg. Reilly rät, sie vorher anzukündigen, sachlich zu formulieren und als Bitte um eine Entscheidung zu verstehen, nicht als Beschwerde. Eine gute Eskalation:

1. beschreibt das Problem und seine Folgen,
2. zeigt, was bereits versucht wurde,
3. nennt die Optionen und eine Empfehlung,
4. bittet um eine konkrete Entscheidung bis zu einem Termin.

Abbrechen ist erlaubt

Ein Projekt zu beenden, das sich nicht mehr lohnt, ist kein Scheitern, sondern eine gute Entscheidung. Reilly rät, Abbrüche ausdrücklich zu kommunizieren, damit niemand weiter Zeit hineinsteckt, und das Gelernte festzuhalten, etwa in einem Abschlussdokument nach dem Vorbild eines Postmortems.

Vorbild sein

Mit dem Titel kommt eine Wirkung, die man nicht abschalten kann: Andere schauen zu. Wie ein Staff Engineer mit Fehlern umgeht, Code reviewt, in Besprechungen spricht oder unter Druck reagiert, prägt, was im Team als normal gilt.

Reilly nennt Haltungen, die ein gutes Vorbild ausmachen, sinngemäß:

• Kompetent sein und es bleiben: weiter lernen, aktuell bleiben, auch wenn man weniger selbst programmiert.
• Verantwortung übernehmen: eigene Fehler offen zugeben; das macht es anderen leichter, es auch zu tun.
• Der Erwachsene im Raum sein: ruhig bleiben, wenn andere es nicht sind; sachlich bleiben, wenn es persönlich wird.
• Langfristig denken: für die Menschen bauen, die das System in fünf Jahren pflegen.
• Zeigen, dass Nichtwissen in Ordnung ist: Fragen stellen, auch scheinbar einfache. Wenn der erfahrenste Mensch im Raum fragt, trauen sich auch die anderen.

Einfluss in der Breite

Staff Engineers können nicht jedem Einzelnen helfen. Reilly beschreibt Wege, die über die eigene Person hinaus wirken:

Die Leitplanken sind dasselbe Prinzip wie Hohpes Steuerung durch Einpflanzen und die Fitness Functions aus Building Evolutionary Architectures: den richtigen Weg zum einfachsten machen. Sponsoring unterscheidet Reilly von Mentoring: Ein Mentor gibt Rat, ein Sponsor öffnet Türen.

Wie es weitergeht

Das letzte Kapitel behandelt die eigene Laufbahn. Reilly beschreibt mehrere Wege:

• Staff bleiben und in der Rolle wachsen, etwa zum Principal Engineer mit noch größerer Reichweite.
• Ins Management wechseln, dauerhaft oder auf Zeit; Charity Majors‘ Bild vom Pendel zwischen technischer und Führungsrolle greift sie auf.
• Die Firma wechseln, wenn die Rolle dort nicht mehr passt.
• Zurück in eine Rolle mit mehr Code, wenn man merkt, dass man das vermisst.

Ihr Rat: regelmäßig prüfen, ob die Arbeit einen noch erfüllt, und wissen, dass keine dieser Entscheidungen endgültig sein muss.

Formulierungen und Übungen

Die folgenden Beispiele sind nicht aus dem Buch übernommen, sondern setzen Reillys Ratschläge in konkrete Sätze und Schritte um.

Formulierungen für typische Situationen

Übungen

1. Drei Karten zeichnen. Zeichne für deine aktuelle Situation die drei Karten, jeweils auf eine Seite: Wo stehe ich und was grenzt an meinen Bereich? Wer beeinflusst tatsächlich Entscheidungen? Wohin soll die Organisation technisch in zwei Jahren?

2. Ressourcenbilanz. Liste deine fünf größten Aufgaben auf und notiere für jede, welche der fünf Ressourcen sie verbraucht und welche sie auffüllt: Energie, Glaubwürdigkeit, soziales Kapital, Fähigkeiten, Lebensqualität. Gibt es Aufgaben, die nur verbrauchen?

3. Klebearbeit sichtbar machen. Notiere eine Woche lang die Klebearbeit, die du oder andere im Team leisten. Wird sie irgendwo anerkannt? Wie könnte man sie sichtbarer machen?

4. Stillstands-Diagnose. Nimm ein Projekt, das gerade nicht vorankommt, und ordne es einer der Formen zu: verirrt, blockiert, fast fertig, sollte beendet werden. Was wäre der nächste Schritt?

5. Eine Leitplanke bauen. Welche Empfehlung gibst du immer wieder in Code-Reviews? Lässt sie sich als Vorlage, Checkliste oder automatische Prüfung festhalten, sodass du sie nicht mehr wiederholen musst?

6. Wen sponserst du? Nenne eine Person, deren Arbeit mehr Sichtbarkeit verdient. Was könntest du in den nächsten vier Wochen tun, um ihr eine Gelegenheit zu verschaffen?

Kritik und Einordnung

Stärken

• Praktisch: Das Buch ist voller konkreter Ratschläge, Fragen und Vorlagen, die man am nächsten Tag anwenden kann.
• Ehrlich: Reilly beschreibt Unsicherheit, Überforderung und Fehlschläge offen, auch eigene.
• Unsichtbare Arbeit sichtbar gemacht: Klebearbeit, Sponsoring und Leitplanken bekommen Namen und Gewicht.
• Gute Werkzeuge: Die drei Karten, die Ressourcenbilanz und die Formen des Stillstands sind einprägsam und nützlich.
• Klare Abgrenzung von Vision und Strategie, mit Rumelts Kern als Gerüst.

Kritikpunkte

1. Große Tech-Unternehmen als Maßstab. Die Rolle des Staff Engineers mit ausgebauter technischer Laufbahn gibt es vor allem in großen amerikanischen Technologieunternehmen. In vielen deutschen Unternehmen, besonders im Mittelstand oder in Konzernen mit klassischer IT, existiert sie so nicht; dort übernehmen Architekten, Senior Developer oder Teamleiter Teile davon.

2. Wenig über Konflikte. Wie man mit schwierigen Menschen, offenem Widerstand oder politischen Kämpfen umgeht, bleibt eher knapp. Dafür sind Crucial Conversations und Radical Candor die bessere Quelle.

3. Kaum Belege. Wie die meisten Bücher dieser Art beruht es auf Erfahrung und Gesprächen, nicht auf Forschung.

4. Nicht für Einsteiger. Das Buch setzt voraus, dass man technisch gefestigt ist und bereits Einfluss über das eigene Team hinaus hat oder haben will.

Gesamturteil

Das beste Buch der Reihe für erfahrene Entwickler, die technisch führen wollen, ohne Manager zu werden. Es ergänzt Hohpe gut: Hohpe beschreibt die Rolle aus der Vogelperspektive eines Konzernarchitekten, Reilly aus der Nähe des Arbeitsalltags. Wer beides gelesen hat, hat ein klares Bild davon, wie technische Führung jenseits des Codes aussieht.

Bezüge zur Reihe

Diskussionsfragen

1. Die Rolle in deinem Umfeld: Gibt es bei euch eine technische Laufbahn jenseits des Managements? Wie heißt sie, und wie klar ist sie definiert?
2. Archetypen: Bist du eher Tech Lead, Architekt, Löser oder rechte Hand? Was davon passt am besten zu dir?
3. Geländekarte: Wer beeinflusst bei euch technische Entscheidungen tatsächlich, und deckt sich das mit dem Organigramm?
4. Strategie: Gibt es bei euch eine schriftliche technische Strategie? Hat sie eine Diagnose, oder ist sie eine Liste von Zielen?
5. Stillstand: Welches Projekt bei euch ist gerade „fast fertig“, und was fehlt bis zur echten Einführung?
6. Klebearbeit: Wer leistet bei euch die unsichtbare Arbeit, die das Team zusammenhält? Wird sie anerkannt?
7. Pendel: Hast du schon zwischen technischer und Führungsrolle gewechselt, oder würdest du es erwägen?
8. Weiter: Als Nächstes Andrew Harmel-Laws Facilitating Software Architecture über gemeinsame Architekturentscheidungen.