Staff Engineer: Eine Rolle definieren und einsetzen

Als ich zu FloQast kam, hatten wir vier Entwicklungsteams. Heute haben wir mehr als 20. Wir begannen mit einer monolithischen Kernanwendung und trennten kontinuierlich neue Branchen ab, bei denen es sich um Untergruppen der FloQast-Hauptanwendung handelte, oder um komplette Branchen für Neukunden. Eines der vier Teams, die ich bereits erwähnt habe, ist jetzt neun verschiedene Teams.

über GIPHY

Mit unserem Wachstum wurde es immer schwieriger, die technische Architektur und die Verfahren aufeinander abzustimmen. Als wir weniger Teams hatten, konnten unsere technischen Manager die architektonischen Muster der Teams genau im Auge behalten und gleichzeitig für die Mitarbeiter und Prozesse verantwortlich sein. Heute könnten acht Teams sein vier oder fünf technische Manager.

Wie könnten wir uns auf eine Rolle stützen, die das Verständnis der Kundenprobleme mit architektonischen Belangen in mehreren Teams verbindet?

Treten Sie ein: The Staff Engineer

Wir haben Staff Engineers in Disziplinen wie QE und DevOps eingesetzt, aber nicht in der Softwareentwicklung. Wie würde es aussehen, wenn wir diese Rolle in der Software-Engineering-Disziplin einsetzen würden? Mit wem würden sie zusammenarbeiten? Wie würden sie mit ihnen zusammenarbeiten?

Der Stabsingenieur

Zuallererst, was ist ein Stabsingenieur? Als Softwareingenieur bei FloQast kommen Sie in Ihrer Karriere möglicherweise an eine Weggabelung: Möchten Sie als Einzelperson tätig bleiben oder möchten Sie ins Management wechseln? Staff Engineer ist nach dem Senior Engineer unsere nächste Karrierestufe. Ein Software-Ingenieur muss kein Staff Engineer werden — er kann so lange bei Senior bleiben, wie er möchte.

Will Larson hat ein hervorragendes Buch über das Thema geschrieben, das spricht über die Archetypen von Staff Engineer, und es ist lesenswert. Wir mochten viele Teile des Buches und haben uns das geliehen, was FloQast brauchte.

Die Vision

Unser CTO Cullen Zandstra hat die Vision für einen Staff Engineer auf einer Seite zusammengefasst. Darin unterteilt er die übergeordneten Ziele wie folgt:

• Sorgen Sie dafür, dass Teams und Architektur entkoppelt sind
• Machen Sie sich klar, was wirklich wichtig ist (der Kunde)
• Verwenden Sie technische Schulden mit Bedacht
• Tragen Sie zu FQ Shared Tech bei
• Suchen Sie nach Möglichkeiten, Produkttechnologie wiederzuverwenden

Das Obige bietet eine klare Grundlage für die Rolle, da es sich um eine Rolle handelt, bei der für eine Reihe von Teams ständig die Details aus den Augen verloren und der Wald von den Bäumen aus betrachtet werden muss.

Verkleinern des Planeten Erde GIFvon GIFs herauszoomen

Definierender Erfolg für Staff Engineers

Der Erfolg für die Rolle bedeutete nicht, dass sie zehnmal die Arbeit eines Senior Engineers verrichten. (Obligatorischer 10-facher Ingenieur-Tweet) Wir wollten auch keine Stabsingenieure isoliert als Elfenbeintürme zu arbeiten und als Torwächter zu agieren. Stattdessen konzentrierten wir uns auf Ziele, die auf technischen Daten basierten, die wir bereits intern verfolgt hatten.

Tore

• Verbesserung der Teamleistung
• Praktische Umsetzung der architektonischen Entkopplung in Produkt-Roadmaps
• T-förmiges Domänenwissen
• Technisches Mentoring

Für jedes dieser Projekte ordnen wir den Erfolg der Vorlaufzeit und der Berechenbarkeit der Teams in ihrem Zuständigkeitsbereich zu. Das heißt, wie schnell können Teams ein Stück Code von einem Ingenieur zur Produktion bringen, und wie akkurat waren die Teams bei der Schätzung der Liefertermine.

Integration von Staff Engineers in das Team

Wenn wir das Engineering als Ganzes betrachten, können wir die allgemeinen Verantwortlichkeiten in drei Bereiche unterteilen: Mitarbeiter, Prozesse und Technologie.

Einige Teams bei FloQast haben keinen Staff Engineer. In diesen Räumen, wenn sie kaputt sind raus in eine RACI-Matrix es sieht aus wie:

Technischer Leiter

• RVerantwortlich für Menschen, Prozesse
• EINBerechenbar für Tech

Mannschaft

• RVerantwortlich für Technik

Im obigen Fall ist der Engineering Manager für das Mitarbeiterwachstum verantwortlich und fungiert als Agile Lead für Teamprozesse. Das Team ist verantwortlich für den Techniker, aber der Engineering Manager ist verantwortlich dafür.

Wenn das verwirrend klingt, ist das Beispiel, auf das ich mich normalerweise stütze: Wir verwenden React bei FloqAST als unsere Standard-Frontend-Bibliothek. Wenn ein Team beschließen würde, React bei einem kommenden Epic durch jQuery zu ersetzen, würde der Engineering Guide das Team von dieser Entscheidung abbringen, da dies keine allgemeine technische Richtung ist, der wir folgen wollen. Allerdings schreibt das Team den Code und entscheidet in den meisten Fällen über die technische Richtung.

In Teams mit einem Staff Engineer würde das so aussehen:

Technischer Leiter

• RVerantwortlich für Menschen, Prozesse

Angestellter Ingenieur

• EINBerechenbar für Tech

Mannschaft

• RVerantwortlich für Technik

In diesem Fall wechselt der Techniker zur Rechenschaftspflicht zum Staff Engineer. Diese Änderung bedeutet nicht, dass unsere technischen Manager nicht an technischen Problemen beteiligt sind. Sie haben alle eine berufliche Laufbahn als Softwareingenieur hinter sich. Diese Erfahrung ist von unschätzbarem Wert für Code-Reviews, das Wachstum von Ingenieuren oder vielen anderen Facetten. Der Staff Engineer ist jedoch der Punkt, an dem das Geld bei architektonischen Entscheidungen für eine Gruppe von Teams endet.

RACI mit anderen

Um das auf eine Gruppe von Softwareingenieuren aufzuteilen, eine Punktperson, Stabsingenieur, technischer Leiter und Senior EM/Direktor:

Um das Ganze schließlich in einem Venn-Diagramm zusammenzufassen, würde es so aussehen:

Coaching 

Sponsoring von Möglichkeiten damit das Team an Umfang und Wirkung wächst

Lieferung

Geteilte Verantwortung aller Teammitglieder, wobei das Team zuerst an erster Stelle steht. Das Team konzentriert sich auf das Jetzt und das Nächste.

Spätere Roadmap

Die Schwellenländer und die SE sind nicht nur an den Plänen „Jetzt und Weiter“ beteiligt, sondern auch an der Later Roadmap ausgerichtet

Mentoring

Technisches Mentoring für das Team

Fragen, die wir bei der Definition der Rolle des Staff Engineers berücksichtigt haben

Das Obige wird auf der Grundlage von Feedback ständig wiederholt. Beim Aufbau dieser Rolle für uns selbst kamen intern mehrere Fragen auf.

Erarbeitet ein Staff Engineer Tickets in einem Sprint?

Im Allgemeinen nein. Wenn Staff Engineers (so wie FQ das macht) Teil der täglichen Sprintarbeit wären, könnten sie nicht so stark skalieren, wie wir es von ihnen erwarten, und zwar auf mehrere Teams für unsere Kunden. Stattdessen „schweben“ sie zwischen den Teams und zoomen je nach Bedarf hinein- und heraus. Sie können mit sitzen ein Teammitglied bei einer bevorstehenden ERD, oder kombiniere das Programm im Sprint mit einem anderen Ingenieur, der auf einem Ticket steht, aber diese sollten im Allgemeinen nicht zur Gesamtgeschwindigkeit eines Teams gezählt werden.

Bedeutet das, dass technische Manager keine Mentoren mehr sind?

Ganz und gar nicht. Es gibt mehrere Möglichkeiten, ein Team zu vergrößern, und die Perspektive jeder Person stärkt die Gruppe. Der technische Leiter hat möglicherweise auch mehr tägliche Interaktionen mit dem Team, und der technische Leiter und der Staff Engineer sind Kollegen, die zusammenarbeiten.

Sollten alle PRs den Staff Engineer aufsuchen?

Dies ähnelt eher dem Gatekeeping und wir wollen dieses Muster vermeiden, da es zu Verzögerungen für den Kunden und zu wachsender Frustration bei den Ingenieuren führen kann. Anstatt einen Engpass zu schaffen, Wir erwarten von unseren Mitarbeitern, dass sie die Teams dabei unterstützen, ihre Architektur und Muster zu regulieren. Das heißt, wenn die Teams sich der entsprechenden Muster und Praktiken selbst bewusst sind und sich darum kümmern, brauchen sie keinen Staff Engineer, der ihnen über die Schulter schaut.

Woher weiß ein Team, wann es sich an einen Staff Engineer wenden muss?

Anfangs waren wir uns nicht sicher, was der beste Weg wäre, wenn sie nicht täglich im Team sind. Es war jedoch interessant, dies zu beobachten, da Staff Engineers bei einem Design Review (einem Meeting, bei dem Ingenieure über technische Details sprechen), einem Backlog Grooming oder sogar bei der Einrichtung der Bürozeiten auftauchen konnten. In jedem Fall haben die Ingenieure vor oder während der Arbeit an verschiedenen schwierigen technischen Problemen Staff Engineers als Bauchcheck hinzugezogen, was ein positives Ergebnis ist.

Wie bleibt der Staff Engineer mit dem Produkt in Verbindung?

Es kann für eine Person in dieser Rolle sehr einfach sein, sich nur um Architektur und Code zu kümmern, aber einer der Kernwerte für Ingenieure bei FloQast ist es, sich um den Kunden zu kümmern, was auch für die Rolle des Staff Engineers gilt. Sie arbeiten regelmäßig mit Produktkollegen zusammen und können sich besonders auf die langfristige Roadmap auswirken.

Zusammenfassung

Der Staff Engineer spielt eine entscheidende Rolle im FQ Engineering und hat die Aufgabe, mehrere Teams durch ihre Fähigkeiten zu entsperren und zu unterstützen. Wir betrachten sie als Teil unserer langfristigen Wachstumsstrategie, indem wir ihnen klare kunden- und teamorientierte Werte sowie einen Rahmen für ihren Erfolg vermitteln.