- Wann wird ein Staff Engineer benötigt, und worin unterscheidet sich diese Rolle von einem Engineering Manager?
- Viele Engineers und Manager sind über die beiden Rollen im Unklaren
- EMs, die Personalführung vermeiden und sich auf Technik konzentrieren möchten, sowie Senior Engineers, die technische Führungsverantwortung übernehmen wollen, stehen oft vor dieser Frage
- Es ist wichtig, Verantwortlichkeiten und Umfang jeder Rolle klar zu verstehen
Fragen, die mir gestellt wurden
- EM: "Ich möchte mich lieber auf Technik konzentrieren statt auf Personalführung. Wäre die Rolle Staff Engineer passend für mich?"
- Senior EM: "Ich habe zu viele Management-Aufgaben. Soll ich einen Staff Engineer einstellen, der die technische Arbeit übernimmt?"
- Staff Engineer: "Ich übernehme de facto die Rolle eines Teammanagers, und das gefällt mir. Sollte ich zu EM wechseln?"
- Senior Engineer: "Welche Verantwortung hat ein Staff Engineer? Das wirkt wie ein Entwickler im Ruhestand."
- New Staff Engineer: "Was bedeutet eine 'dotted reporting line'? Ich habe doch schon einen Line Manager — muss ich mich jetzt auch nach einem anderen Manager richten?"
Wann wird ein Staff Engineer gebraucht?
- Engineers bauen und betreiben Technik, aber Technik existiert nicht für sich allein
- Sie ist eine Lösung für ein Problem, und das Problem wird durch das Produkt definiert
- Ein Produkt erbringt einen Service für Endnutzer oder interne Kunden
- Ein Produkt ist ein Mittel, um ein Nutzerproblem zu lösen, zum Beispiel:
- eine App, die Laufdistanzen misst und mit anderen Nutzern teilt
- eine Website zur Hotelbuchung
- eine Infrastrukturplattform, die von anderen Teams genutzt wird
- ein System zur Arbeitszeiterfassung
- Engineers, die solche Produkte entwickeln, arbeiten in der Regel in Teams, die von einem Engineering Manager (EM) geführt werden
- Ein EM trägt Accountability für die Teammitglieder (Engineers) und für die von ihnen erzeugten technischen Artefakte (artifacts)
- In den folgenden Fällen ist es jedoch schwierig, dieser Verantwortung vollständig gerecht zu werden:
- wenn das Team sehr groß ist
- wenn die Technik zu komplex ist
- oder wenn beides gleichzeitig zutrifft
- In solchen Fällen reichen Zeit und Energie (Bandbreite) des EM nicht mehr aus, um sowohl der Verantwortung für Menschen als auch für Technik vollständig nachzukommen
- Wenn es dem EM schwerfällt, seiner Verantwortung gerecht zu werden, kommen zwei Delegationsstrategien infrage:
- Delegation administrativer Aufgaben:
- HR-Prozesse und -Tools optimieren oder
- einen Assistenten einstellen, um die Last der Personalführung zu reduzieren
- Ein dedizierter Assistent für nur ein Team mag übertrieben wirken, aber es gibt auch Modelle, bei denen sich mehrere Teams einen Assistenten teilen
- Mit AI-Tools lassen sich mechanische Aufgaben wie Terminabstimmung, das Beantworten von Management-Fragen oder das Einsammeln von Feedback teilweise ersetzen
- Gute HR-Systeme können die Management-Last drastisch senken
- Delegation technischer Arbeit:
- Man kann einen Staff Engineer einstellen, um die technische Last aufzuteilen
- Assistenten oder AI können jedoch die folgenden menschenzentrierten Kernaufgaben eines EM nicht übernehmen:
- ein gutes Team aufzubauen
- Mentoring
- Performance-Reviews
- Recruiting usw.
- Umgekehrt gilt es als Anti-Pattern, die gesamte technische Arbeit an den Staff Engineer zu übergeben
- Ein Staff Engineer sollte nicht als technischer Übersetzer des EM fungieren
- Ein EM muss ein gewisses Maß an technischer Verantwortung behalten
- Deshalb ist es essenziell, dass ein Engineering Manager technisch dranbleibt,
Situationen, in denen ein Staff Engineer nützlich ist
- In den folgenden Fällen kann ein Staff Engineer einer Organisation konkreten Mehrwert liefern:
- wenn es eine technische Last gibt, die der EM schwer tragen kann
- z. B. wenn viel Legacy-Technik vorhanden ist und laufende Wartung erforderlich ist
- wenn es komplexe teamübergreifende Lösungen gibt oder tiefes technisches Wissen nötig ist
- oder wenn der EM selbst (kein empfehlenswertes Muster) nicht technisch genug ist
- wenn sich für einen Teil der technischen Arbeit klare Accountability definieren lässt
- wenn der technische Umfang über das hinausgeht, was ein einzelner EM steuern kann
- Ein Staff Engineer sollte für Technik verantwortlich sein, nicht für Menschen
- Teamführung oder Performance-Reviews gehören nicht dazu
- Da Situation, Produkt und Personen je nach Organisation unterschiedlich sind, lässt sich das nicht universell anwenden
- Hinweis: responsibility und accountability sind fein unterschiedliche Konzepte,
- Ein Staff Engineer sollte folgende Eigenschaften mitbringen:
- tiefes technisches Verständnis und hohe technische Literacy
- klare technische Accountability
- mehr Zeit für technische Investitionen, da keine Personalführungsverantwortung besteht
- Andererseits darf sich auch ein EM nicht vollständig aus technischer Verantwortung zurückziehen
- er oder sie muss weiterhin in gewissem Maß technisch involviert bleiben und die Technik verstehen
- Der eigentliche Wert eines Staff Engineers entsteht durch technische Führung über mehrere Teams hinweg
- Wenn man einen Staff Engineer nur innerhalb eines Teams einsetzt, können folgende Probleme entstehen:
- Überschneidungen in der technischen Verantwortung
- Rollenverwirrung und am Ende die ineffiziente Aufspaltung einer Rolle auf mehrere Titel
Ausnahmefälle, in denen teambezogene Arbeit möglich ist
- Normalerweise konzentriert sich ein Staff Engineer auf teamübergreifende technische Führung, aber in den folgenden Situationen ist auch Arbeit auf Teamebene vorübergehend möglich:
- wenn ein neuer EM einen Legacy-Stack schnell verstehen muss
- wenn ein neuer Staff Engineer sich zunächst über einen kleineren Umfang onboardet
- wenn es so viele technische Schulden gibt, dass sich die Systemgesundheit verschlechtert hat
- wenn Wartung aufgrund technischer Komplexität schwierig geworden ist
- In solchen Fällen sollte ein teambezogener Staff Engineer eine temporäre Konstellation sein
-
Der eigentliche Wert eines Staff Engineers
- als verbindendes Element (glue) zwischen Teams
- indem er nah an der tatsächlichen Arbeit mit anderen Engineers zusammenarbeitet und ihre Stimmen an das Management weiterträgt
- Engineers sprechen in der Regel offener mit anderen Engineers als mit Personen, die über Gehalt, Urlaub oder Beurteilungen entscheiden
- durch technisch tiefgehende Führung
- anders als ein EM hat ein Staff Engineer weniger Meetings, 1:1s und Management-Aufgaben und kann sich daher stärker auf Engineering-Kompetenz und technische Tiefe konzentrieren
-
Das größte Risiko: der Ivory Tower Architect
- ein abstrakter Theoretiker, der sich von realen Problemen und Code entfernt
- dieses Problem wird in Ivory Tower Architect ausführlicher behandelt
Die Rolle des Staff Engineers für Systeme über mehrere Teams hinweg
- Ein Staff Engineer eignet sich am besten für technische Führung, die nicht nur ein Team, sondern das gesamte System umfasst
- Will Larsons Essay stellt vier Archetypen des Staff Engineers vor:
- Tech Lead: technischer Leiter innerhalb eines Teams
- Architect: Systemarchitekt
- Solver: Löser komplexer technischer Probleme
- Right Hand: rechte Hand der Leitung einer technischen Organisation
- Den im Diagramm gezeigten teaminternen Tech Lead einfach als Staff Engineer zu bezeichnen, ist schwierig
- der echte Wert eines Staff Engineers liegt in teamübergreifender Abstimmung und technischer Integration
- siehe Introduction to Staff Engineering
- Ein Staff Engineer ist nicht nur ein Titel, sondern eine auf technischer Führung basierende Haltung
- Diese Rolle übernimmt technische Abstimmung und Problemlösung über unterschiedliche Teams und Produkte hinweg
- Sie entfaltet Wirkung ohne formale Autorität über Menschen oder Produkte und prägt die technische Strategie und Richtung der gesamten Organisation
- Anders als ein Engineering Manager schafft sie Wert weniger durch Management als durch tiefe technische Expertise und organisationsübergreifende Zusammenarbeit
- Sie bleibt nah an der Praxis und übernimmt auch eine Mentorenrolle, um das Wachstum anderer Engineers zu fördern
- In realen Organisationen sind technische Systeme nicht auf ein Team beschränkt, sondern über mehrere Teams verteilt oder eng miteinander gekoppelt
- in solchen Fällen braucht es einen dedizierten Staff Engineer, der für das Gesamtsystem verantwortlich ist
- unabhängig davon, welcher Teil bei welchem Team liegt, braucht es einen Blick auf das Gesamtsystem und das entsprechende Verantwortungsbewusstsein
Ein Staff Engineer muss nicht nur durch Technik, sondern auch durch Menschen und Produkt wirken
- Der zentrale Punkt: Technik spricht oder hört nicht mit der anderen Seite
- Technik kann nicht für sich allein bestehen, sondern erhält Bedeutung erst durch Menschen (Engineers) und das Produkt (Problemraum)
- Damit ein Staff Engineer echten Wert schafft, muss er oder sie zwingend durch Folgendes wirken:
- Zusammenarbeit mit Engineers
- Abstimmung mit dem Produktteam
- Deshalb hat ein Staff Engineer dotted reporting lines
- eine informelle, aber wichtige Verbindung für organisationsübergreifende Zusammenarbeit und Commitments
- Manche aufmerksamen Beobachter fragen, warum die Pfeile im Staff-Modell eher nach unten zeigen
- Grund 1: Gute Führung basiert auf Zusammenarbeit, nicht auf Autorität
- Ein Staff Engineer trägt Anfragen zur technischen Verbesserung in kollaborativer Form an teamnahe EMs oder PMs heran
- nicht als einseitige Anweisung, sondern als kooperatives Vorgehen unter Berücksichtigung von Engineers und Produkt-Roadmap
- Grund 2: Ein Staff Engineer ist ein IC (Individual Contributor) und hat daher keine formalen direkten Reports
- wenn es mit EMs/PMs regelmäßige Gesprächskanäle gibt, dann idealerweise nicht nur zum Reporting, sondern für:
- den aktuellen Zustand der Technik (status quo)
- eine technische Vision zur Lösung von Produktproblemen (vision)
- eine organisatorische technische Strategie dafür (strategy)
- ideal ist ein Dialog in beide Richtungen über diese drei Aspekte
- Um diese verschachtelten Reporting-Strukturen zu ordnen und die technische/produktseitige Ausrichtung über Teams hinweg zu unterstützen, ist
- ein unternehmensweites Strategiedokument (strategy document) sehr hilfreich
- die Grundlagen dazu finden sich unter Strategy basics
-
Diagnose (Diagnosis)
- Nach der Untersuchung des Problemraums werden die zentralen zu lösenden Themen und die Gründe dafür herausgearbeitet
- Sie erklärt, warum eine Strategie nötig ist
- Symptome und Ursachen werden identifiziert und analysiert, warum sie gerade jetzt wichtig sind
- In schlechter Strategie fehlt dieser Teil oft oder beschreibt nur den Status quo
- Eine gute Diagnose erfordert objektive Untersuchung und eine fast detektivische Haltung
-
Leitlinie (Guiding Policy)
- ein High-Level-Ansatz, um die identifizierten Probleme zu lösen
- Sie fokussiert die Lösung und richtet die gesamte Organisation darauf aus
- Sie gibt Orientierung, ohne jede taktische Detailfrage neu aufzurollen
- Schlechte Strategie trennt diese Leitlinie (HOW) von der Diagnose (WHY)
-
Kohärente Maßnahmen (Coherent Actions)
- ein konkreter Umsetzungsplan, um die in der Diagnose beschriebenen Probleme gemäß der Leitlinie anzugehen
- Er macht klar, wer (WHO), was (WHAT) und wann (WHEN) tut
- Entscheidend ist die Kohärenz, damit verschiedene Teams abgestimmt in dieselbe Richtung arbeiten
Eine andere Möglichkeit, technischen Scope auf ein Team zu begrenzen: das Kebab-vs.-Cake-Modell
- Man kann die Organisationsstruktur auch so gestalten, dass Technik nicht teamübergreifend verläuft, sondern innerhalb eines Teams lösbar bleibt
- Ein typisches Beispiel dafür ist das Kebab-vs.-Cake-Modell
- ein struktureller Ansatz, der Teams entlang der Consumer Journey organisiert und damit den Umfang technischer Verantwortung verkleinert
- eine ausführlichere Erklärung findet sich unter Kebab vs Cake organization
-
Kebab-Architektur
- Teams sind rund um bereitgestellte Funktionen organisiert
- die User Journey verläuft durch die Artefakte mehrerer Teams
- Vorteil: Autonomie und lose Kopplung
- Nachteil: Risiko von Handovern
-
Cake-Architektur
- Teams sind entlang der User Journey organisiert
- die kognitive Last wird über Abstraktionsschichten gesteuert
- Vorteil: End-to-End-Ownership und weniger Handover
- Nachteil: Risiko höherer kognitiver Last
- Ein Staff Engineer ist nicht nur eine technische Rolle, sondern ein Owner mit Verantwortung für das Gesamtsystem und sollte drei Dinge mitbringen:
- Wissen (Knowledge):
- tiefes Verständnis des Tech-Stacks und des Produktproblems
- bei Bedarf in der Lage, dies zu erklären und selbst umzusetzen
- Mandat (Mandate):
- in einer Position zu sein, eine Meinung dazu einbringen zu können, wie sich die Technik weiterentwickeln und wie sie betrieben werden soll
- Verantwortung (Responsibility):
- Verantwortung für den Gesundheitszustand des Systems (Incidents, technische Schulden, Dokumentation, technische Brüche usw.)
- Ein Staff Engineer ist keine rein technische Rolle; um eine Organisation technisch zu führen, sind Soft Skills essenziell
- etwa wirkungsvolle Kommunikation, Zusammenarbeit und Leadership
- Wenn man sich jedoch zu stark auf Soft Skills konzentriert, entstehen Probleme wie diese:
- Es werden nur realitätsferne Ideale präsentiert, ohne Beteiligung an tatsächlichem Coding oder Problemlösen
- das birgt das Risiko, zu einem Ivory Tower Architect zu werden
Fazit
- Nicht jede Organisation braucht einen Staff Engineer. In den folgenden Fällen kann man auch gut ohne auskommen:
- wenn der EM technisch stark genug ist, um die Technik des Teams selbst zu führen
- wenn der Tech-Stack gesund und leicht wartbar ist
- wenn die Technik innerhalb eines Teams vollständig abgedeckt ist und es kaum teamübergreifende Abhängigkeiten gibt (das Cake-Organisationsmodell ist ein Beispiel)
- wenn die Organisation so reif ist, dass sie das Gesamtsystem auch ohne klar benannten Owner gut betreiben kann
- Wenn eine Organisation dagegen Staff Engineers hat, sollte sie Folgendes klar definieren:
- technical ownership eindeutig festlegen und
- dem Staff Engineer dafür klare Accountability geben
- Die Kernaussagen:
- Ivory Tower Architects sollte man vermeiden (ohne Realitätsbezug)
- eine Rolle auf mehrere Titel aufzuteilen ist ineffizient
- ein nichttechnischer EM ist ebenfalls ineffizient
- Abschließend gilt: Dieser Text ist kein absolutes Gesetz, sondern ein Essay zur Orientierung
- Organisation, Technik, Produkt, Betrieb und Menschen sind überall unterschiedlich, daher ist situationsgerechtes und flexibles Urteilen wichtig
- blindes Nachahmen (cargo culting) sollte vermieden werden → siehe den zugehörigen Beitrag
4 Kommentare
Es wirkt, als wären sie die rechten Hände des CTO.
Staff Engineer: die Person, zu der man geht, um Druck zu machen, wenn man es immer wieder versucht hat und es trotzdem nicht klappt.
Haha, total nachvollziehbar.
Das hat zwar nicht direkt viel mit dem Inhalt des Artikels zu tun, aber da ich gerade über accountability und responsibility nachgedacht habe, war der folgende Link für mich sehr hilfreich.
https://blog.alexewerlof.com/p/accountable-vs-responsible