Choć w Polsce nie jest to jeszcze popularne stanowisko, za granicą widać je szczególnie w dużych organizacjach. Rozmawiamy z Marcinem Sieńkiem, który rolę Staff Engineera pełnił w Google – gdzie zaczynał od stanowiska Software Engineera. Na stanowisku Staff Engineera pracował także w Tesli.
Zapytaliśmy go o to, na czym polega praca Staff Engineera i czym różni się od roli Senior Software Engineera.
Mam wrażenie, iż na polskim rynku mało popularna jest rola Staff+ Engineera. Zgodzisz się z tym?
Staff+ to zbiorcze określenie opisujące grupę stanowisk dla indywidualnych kontrybutorów (nie menedżerów) wyższych stażem niż Senior Engineer. Takie stanowiska mogą nazywać się Staff Engineer, Member of Technical Staff, Principal Engineer, Uber Tech Lead, niekiedy również Distinguished Engineer.
Potrzeba na takie role najczęściej pojawia się w większych organizacjach, więc rzeczywiście mogą być mniej popularne w startupach czy software house’ach, którymi Polska stoi. Ale stanowisk inżynierskich w randze Staff+ nie spotkamy tylko w wielkich korporacjach Big Tech. Wiele prywatnych scale-upów z Doliny Krzemowej ma takie role jeszcze przed wejściem na giełdę, również w biurach satelickich.
Czym zajmuje się Staff+ Engineer?
Jest kilka archetypów, ale łączy je zaangażowanie w kształtowanie kierunku technicznego przyjmowanego przez organizację, sponsorowanie inicjatyw podejmowanych przez mniej doświadczonych współpracowników, kształtowanie horyzontalnych praktyk czy niwelacja ryzyka (derisking) eksperymentalnej technologii. Bycie (Uber) Tech Leadem to chyba najpopularniejszy archetyp, ale Architekci czy Inżynierowie do Zadań Specjalnych niekiedy również się zdarzają.
Oprócz swoich codziennych obowiązków, tacy inżynierowie często mają również horyzontalne zadania – np. służba w komitecie ds. zatrudnień bądź awansów, tworzenie dokumentów opisujących powtarzalne praktyki (generalizowane z lekcji zauważonych w różnych zespołach, z którymi taki Staff+ Engineer współpracuje) oraz wspieranie młodszych kadr w osiągnięciu sukcesu w organizacji. Ogólnie, nacisk kładziony jest na zadania, które mają funkcję mnożnikową (nie addytywną) do efektywności zespołu.
Co z kolei nie leży wśród jego obowiązków?
Co do zasady, celem tych ról nie jest zarządzanie kadrami, jak w przypadku people managera (choć np. Google zdarzają się pracownicy, którzy pozostają oficjalnie w randze np. Principal Engineera, mimo iż wykonują obowiązki bliższe Engineering Directorowi). Nie znaczy to jednak, iż miękkie umiejętności i troska o rozwój członków zespołu tych ról nie dotyczy.
Często Staff+ Engineerowie – choć mają spory prestiż – nie mają formalnej władzy nad pracownikami. Tak więc – by osiągać cele dla organizacji – muszą praktykować tzw. “influence without authority” – tzn. wpływanie na innych bez formalnej władzy. Źródłem “authority” w takich przypadkach jest wiara zespołu w kompetencje Staff+ Engineera oraz dobre relacje z Engineering Managerami, którzy decydują o alokacji czasu pracy ich podwładnych.
Budowa takiego zaufania to trudna, ale bardzo wartościowa umiejętność, która zresztą pozwala wykształcić wyższą empatię i EQ, a te na pewno przydadzą się, gdy taka osoba pewnego dnia otrzyma formalną władzę.
Staff Software Engineerowie mogą pisać kod, ale nie muszą. Tego typu kontrybucje najczęściej ograniczone są do prototypowania najtrudniejszych części systemu, tak by dotrzeć do postaci, w której reszta jest delegowalna do zespołu.
Jakie znaczenie w kontekście całej organizacji ma Staff+ Engineer? Czy każda organizacja powinna mieć takie osoby?
Myślę, iż potrzeba powstawania tych ról rośnie wraz ze skalą organizacji. W mniejszych grupach, koszt takiego pracownika jest pewnie nie do uzasadnienia. Jednak powyżej pewnego rozmiaru, rośnie rola kształtowania silnej kultury inżynierskiej, zapewnianie spójności między zespołami oraz centralizacja pewnych kompetencji.
Z drugiej strony, nie każdy sprawny inżynier jest motywowany rozwojem zespołu i sprawdzi się w roli menadżera, więc na pewnym etapie liderzy organizacji mają wybór – awansować najbardziej utalentowane kadry ponad poziom ich kompetencji (tzw. reguła Petera), lub dać im odejść. W tej sytuacji utworzenie dla nich wysokiego, niemenedżerskiego stanowiska może być najlepszym wyjściem dla retencji kluczowego talentu.
Od ponad czterech lat pełnisz tę rolę w Google’u. Jak wygląda Twój dzień pracy? Czym różni się od pracy Senior Software Engineera?
Owszem, odgrywałem tę rolę zarówno w Tesli, jak i w Google. Dzień pracy nieco różni się w zależności od tego, jakiego archetypu Staff Software Engineera moja organizacja aktualnie potrzebuje.
Zdarzało mi się leadować zespoły do 18 osób, kiedy to praktycznie cały dzień upływał na budowaniu wspólnej wizji między kierownikami działu inżynieryjnego i produktowego, pomocy starszym inżynierom w rozwiązywaniu różnic zdań, recenzowaniu kodu młodszych inżynierów itd.
Z drugiej strony, bywały okresy, gdy moim celem było głównie tworzenie połączeń z innymi organizacjami w firmie, próba opracowania wspólnej wizji tego, czym mój zespół powinien się zajmować w kolejnych kwartałach, i “pitchowanie” do kierowników (którzy ostatecznie decydują o przypisaniu swoich podwładnych do projektu), iż projekt, który zidentyfikowałem, wart jest ich zasobów.
Wreszcie, zdarza się, iż samemu implementuję najbardziej ryzykowne technicznie aspekty projektu, by gwałtownie zweryfikować, czy proponowany stack technologiczny jest optymalnym dla projektu wyborem.
Jak zostaje się Staff Engineerem? Trzeba przejść typową drogę, czyli wcześniej być Seniorem?
Tak, najbardziej klasyczna ścieżka to oczywiście wspinaczka po szczeblach kariery od juniora, poprzez seniora itd. Tą metodą właśnie otrzymałem takie stanowisko w Google. W odróżnieniu od stanowiska Starszego Programisty (które można niekiedy dostać na podstawie stażu, nieco “przez zasiedzenie”), awansowanie do roli Staff Engineera (i wyżej) często związane jest z odpaleniem (i “wylądowaniem”) jakiegoś dużego projektu, o podwyższonej trudności technicznej i organizacyjnej, długim okresie czasu (18+ miesięcy) oraz dużym wpływie na wyniki przedsiębiorstwa.
Potrzeba do tego nie tylko talentu i wytrwałości, ale też dużo szczęścia – nie w każdym zespole taka okazja może się pojawić. zwykle decyzje o promocji na tak wysokie stanowisko wymagają szerokiego przeświadczenia o unikalnej wartości dostarczanej przez pracownika, dlatego ważna jest widoczność takiego projektu dla co najmniej kilku osób na dyrektorskich stanowiskach – wsparcie bezpośredniego szefa to często za mało. Oprócz wyjątkowej efektywności w spełnianiu wymagań stawianych Senior Engineerom, warto uczestniczyć w definiowaniu, czym organizacja powinna się zajmować, wdrażać horyzontalne praktyki, zgłaszać się do komitetów itd. – innymi słowy de facto wykonywać część odpowiedzialności roli Staff+, zanim się ją formalnie otrzyma.
W firmach, gdzie nie ma systematycznego procesu przyznawania awansów (bądź takie stanowisko jeszcze nie istnieje), dodatkowo ważne mogą się okazać pewne umiejętności negocjacyjne – z gotowością odejścia do innego pracodawcy w przypadku braku awansu włącznie. Osobom zainteresowanym staraniem się o taki awans u aktualnego pracodawcy, rekomendowałbym książkę “Staff Engineer” Willa Larsona.
Drugą popularną metodą jest wynegocjowanie takiego stanowiska w firmie, do której się rekrutujemy (po tym, gdy u wcześniejszego pracodawcy mieliśmy świetne efekty jako Senior Engineer, ale z różnych powodów nie udało nam się tam jeszcze awansować). Tą metodą uzyskałem swój pierwszy tytuł Staff Engineera w Tesli. Oczywiście wymaga to wyjątkowej motywacji ze strony nowego pracodawcy, gładkiego przebiegu rozmów kwalifikacyjnych (zwłaszcza na rozmowach weryfikujących projektowanie systemów i umiejętności miękkie) oraz silnej pozycji negocjacyjnej (np. unikalnej kombinacji umiejętności, którą nowy pracodawca potrzebuje + autentycznej gotowości do zerwania negocjacji gdy nasze oczekiwania nie zostaną spełnione).
Wielu kandydatów wybiera w tej sytuacji skupienie negocjacji na początkowym wynagrodzeniu, a nie nazwie stanowiska – zasadność wyboru celów negocjacji zależy w sporej mierze od horyzontu czasowego w kontekście, którego optymalizujemy swoją karierę. Osobom zainteresowanym przygotowaniem merytorycznym do rozmów o pracę na stanowisko Staff Engineera rekomendowałbym m.in. książkę “Designing Data-Intensive Apps” Martina Kleppmanna.
Alternatywnym źródłem kadr tego szczebla może być awans na stanowisko ze ścieżki menedżerskiej (kierownicze bądź dyrektorskie) a następnie rezygnacja z zarządzania ludźmi na rzecz zajęcia się jakimś wyjątkowo trudnym technicznie problemem bądź w wyniku reorganizacji.
Żeby rola Staff+ Engineera miała sens, musi być on blisko zarządu / core teamu? To znaczy, iż bierze też udział w podejmowaniu wysokopoziomowych decyzji?
To oczywiście zależy od rozmiaru organizacji i archetypu Staff Engineera.
Firmy zajmujące się sprzedażą systemu typu enterprise mają czasem specjalną jednostkę np. “Biuro Chief Technology Officera”, które doradza zarządom potencjalnych klientów odnośnie sposobu wdrożenia sprzedawanej im (za miliony dolarów) technologii. Często można tam znaleźć Staff Engineerów o archetypie “Architekta” bądź “Prawej Ręki” CTO.
“(Uber) Tech Leadowie” (i niekiedy zorientowani wewnętrznie “Architekci”) z kolei są zwykle bliżej zespołów produktowych, najczęściej koordynując wspólne praktyki techniczne, wdrożenia wewnętrzne bądź wyjątkowo duże projekty w warstwie technicznej (podczas gdy Eng Director koordynuje współpracę w warstwie organizacyjnej).
Z kolei archetyp “Inżyniera do Zadań Specjalnych” najczęściej można znaleźć w jakimś centralnym teamie (niekoniecznie podlegającym pod zarząd), który “wypożycza” na krótki czas (1-3 kwartały) Staff Engineerów organizacjom, które przechodzą jakąś wyjątkowo trudną transformację, wymagają zderiskowania rozwiązania jakiegoś skomplikowanego problemu, stworzenia szybkiego prototypu w zupełnie nowej technologii itd.
Rozmawialiśmy o ścieżce kariery, więc zapytam też o to, co jest po Staff Engineerze. Jakie stanowisko jest kolejne?
Ścieżka kariery na wyższych stanowiskach w firmie jest dużo mniej ustandaryzowana. Dość dużo firm z Doliny ma coś w stylu: Staff Engineer – (Senior Staff Engineer) – Principal Engineer – (Distinguished Engineer), ale nie ma na to reguły.
Poziom Distinguished Engineera zwykle wymaga szerokiej rozpoznawalności w mediach, prowadzenia popularnego bloga / podcastu technicznego, autorstwa wyjątkowo wpływowych artykułów naukowych bądź stworzenia niebywale szeroko używanego przez całą branżę open-source’u.
Decyzje o awansie na takie stanowiska podejmowane są uznaniowo i są przedmiotem bardziej indywidualnych negocjacji niż zdefiniowanego procesu. Na przykład w Google stworzono kiedyś poziom “Senior Fellow”, którym przez wiele lat cieszyło się tylko dwóch inżynierów, odpowiedzialnych de facto za większość architektury, na której opierały się Google Search, Ads, Gmail itd.
Osoby motywowane dalszym postępem kariery często decydują się na którymś etapie jednak na przejście na równoległą ścieżkę menedżerską, gdzie postęp Engineering Manager – Engineering Director / Head of X – Vice-President – (Senior Vice President) – Chief Technology Officer – choć również trudny – jest nieco mniej uzależniony od eksplozywnego wzrostu rozmiaru przedsiębiorstwa do dziesiątek tysięcy pracowników, czy żmudnego budowania autorytetu w branży i rozpoznawalności w mediach.
Co określiłbyś jako sukces na tym stanowisku? Co z kolei jest porażką?
Jest pewnie kilka “failure mode’ów”: podstawowym jest nieuświadomienie sobie, jak bardzo oczekiwania na tym stanowisku różnią się od wcześniejszej części kariery i próbą bycia po prostu “Senior Engineerem tylko bardziej”. Innym case’em jest niezrozumienie swojej roli w sukcesie zespołu i niepozostawienie młodszym współpracownikom okazji wykazania się i realizacji również ich własnych celów.
Jednak organizacja, w której Staff Engineerowie odgrywają swoją rolę skutecznie, to organizacja, która ma spójną kulturę, rozwiązuje wartościowe problemy, podejmuje skalkulowane ryzyka, uczy się na błędach i stwarza okazje do rozwoju Mid/Senior Engineerów.
Marcin Sieniek. Tech lead, przedsiębiorca i anioł biznesu. Ukończył doktorat z informatyki na AGH i studia biznesowe na UEK. Od 6 lat pracuje w Google Research w Kaliforni, gdzie współtworzył zespół zajmujący się zastosowaniem AI w diagnostyce raka piersi, którego wyniki zostały opublikowane m.in. w Nature. Wynaleziona przez jego zespół technologia jest przedmiotem kilku międzynarodowych patentów oraz licencji do firm medycznych, obsługujących tysiące szpitali w USA i Europie. Do jego hobby należą siatkówka, podróże, inwestycje alternatywne oraz gra na gitarze w zespole rockowym.
