Rola inżyniera Staff-plus zależy w dużej mierze od tego, czego potrzebuje zespół, a także od mocnych stron danego inżyniera. Z mojego doświadczenia wynika, że obowiązki inżyniera Staff-plus mogą się zmieniać w czasie, ale zazwyczaj ich głównym celem jest praca nad projektami/działaniami, które mają wartość strategiczną dla firmy, przy jednoczesnym prowadzeniu projektu technicznego i podnoszeniu poziomu zespołu. – Diana Pojar

Każdy, kto został zaatakowany przez krewnych na imprezie i poproszony o wyjaśnienie, co właściwie robią inżynierowie oprogramowania, wie, że wyjaśnienie tej pracy może być wyzwaniem. Z czasem możesz stworzyć przekonującą odpowiedź dla swoich krewnych, ale wielu ludzi ma pustkę w głowie, kiedy ich współpracownik pochyla się i pyta: „Czym zajmuje się inżynier sztabowy?”

Najprostszą odpowiedzią jest to, że inżynierowie sztabowi nadal robią wiele z tego, co sprawiło, że odnieśli sukces jako starsi inżynierowie: budują relacje, piszą oprogramowanie, koordynują projekty. Jednakże, jest to myląca odpowiedź. Wykonują te same zadania, ale podczas gdy wcześniej stanowiły one trzon pracy, teraz stały się pracą pomocniczą i mają nowe priorytety. Ich codzienny harmonogram różni się nieco w zależności od archetypu, ale istnieje wspólny fundament dla wszystkich archetypów: wyznaczanie i edytowanie kierunku technicznego, zapewnianie sponsoringu i mentoringu, wprowadzanie kontekstu inżynierskiego do decyzji organizacyjnych, eksploracja i to, co Tanya Reilly nazywa byciem klejem.

Wyznaczanie kierunku technicznego

Czuję się najbardziej wpływowy, kiedy mogę ułatwić wyznaczanie wizji technicznej dla danego obszaru i sprawić, że ludzie ruszą w kierunku tej wizji. Myślę, że wszyscy zgodzimy się, że chcemy, aby nasz kod był lepiej zaprojektowany niż jest lub w jakiś sposób ulepszony. Jednakże, zauważyłem, że często ludzie mają jakieś mgliste poczucie, że chcą czegoś lepszego, ale nie mają jasnego pomysłu na to, czego chcą. Lubię pomóc grupie zdecydować się na wspólne zrozumienie tego, gdzie dokładnie próbują się dostać (to właściwie w porządku, jeśli nigdy tam nie dotrzemy) i wymyślić ogólny plan gry, jak się tam dostać. – Joy Ebertz

Podobnie jak Lorax mówi w imieniu drzew w swojej popularnej książce dla dzieci, inżynierowie personalni mówią w imieniu technologii swoich firm. Technologia nie może mówić sama za siebie i wymaga skutecznych orędowników w swoim imieniu. Ludzie, którzy z powodzeniem rozwijają technologię, są pragmatyczni, rozważni i skupiają się bardziej na długoterminowym trendzie postępu, niż na postrzeganiu każdej pojedynczej decyzji jako kryzysu typu „make-or-break”. Pomocne może być myślenie o tym jako o niepełnoetatowym Product Managerze dla technologii.

Niektórzy inżynierowie Personel-plus są wyraźnie zatrudnieni do prowadzenia konkretnego obszaru, takiego jak projektowanie API, a w innych przypadkach znajdują się przy edycji i wyrównywaniu podejść w szerokim obszarze. Jedna stała we wszystkich rolach jest to, że rzeczywistość ustalania kierunku technicznego jest znacznie więcej o zrozumienie i rozwiązanie rzeczywistych potrzeb organizacji wokół ciebie, a znacznie mniej o priorytetyzacji technologii i podejść, które osobiście są podekscytowani, aby dowiedzieć się o. We wcześniejszych rolach mogłeś próbować wpływać na decyzje w kierunku wyborów technologicznych, do których jesteś zmotywowany, ale na wyższych stanowiskach jesteś odpowiedzialny za biznes i organizację po pierwsze, a siebie po drugie.

Mentorstwo i sponsoring

W mojej obecnej roli, czuję się naładowany energią, gdy ktoś, kogo sponsorowałem wysyła ogłoszenie, że wysłał swoją pracę, lub gdy widzę, że pomogłem ukształtować lub zmienić model zespołu inżynieryjnego w ważnym temacie. To właśnie te zespoły, a nie ja, wykonują ciężką codzienną pracę związaną z budowaniem i wspieraniem technologii. Mój wpływ mierzę na podstawie ich postępów, a co ważniejsze, kierunkowości tych postępów i dostosowania ich pracy do celów firmy. – Michelle Bu

Popularna wizja heroicznego przywództwa koncentruje się na niezwykle produktywnych osobach, których decyzje zmieniają przyszłość firmy. Większość z tych narracji jest celowo zaprojektowana przez zespoły public relations, aby stworzyć dobrą historię. O wiele bardziej prawdopodobne jest, że zmienisz długoterminową trajektorię swojej firmy poprzez rozwój inżynierów wokół siebie niż poprzez osobiste bohaterstwo. Najlepszym sposobem na rozwój osób wokół Ciebie jest stworzenie aktywnej praktyki mentoringu i sponsoringu.

Wiele szczebli kariery ma obowiązkowe pole wyboru wokół mentoringu, aby zakwalifikować się do awansu do roli Personelu, a mentoring jest kluczową częścią tej roli. Dzielenie się swoim doświadczeniem i radą, wraz z trwającą relacją, aby zrozumieć kontekst odbiorcy, to praca o dużym wpływie. Na wyższych stanowiskach, mentoring jest tylko poprzeczką do przyjęcia, a najbardziej efektywni inżynierowie sztabowi łączą umiarkowaną ilość mentoringu ze znacznie większym sponsoringiem: kładą swój kciuk bezpośrednio na skali, aby pomóc w rozwoju i wspierać tych, którzy są wokół nich. Jeśli jeszcze tego nie czytałeś, Lara Hogan napisała kanoniczną pracę na temat różnicy między sponsoringiem a mentoringiem, What does sponsorship look like?

Providing engineering perspective

I have a seat at the table at higher level engineering discussions that occur at a level above individual projects and teams. Odbywamy powtarzające się spotkania inżynieryjne personelu, na których omawiamy problemy obejmujące zespoły, które mają charakter zarówno techniczny, jak i nietechniczny. – Dan Na

Efektywne organizacje usprawniają podejmowanie rutynowych decyzji. Dobrym tego przykładem jest proces sprawdzania kontraktów dla potencjalnych klientów korporacyjnych. Na początku podpisywane są umowy, które nie są wygodne dla zespołów inżynierskich i produktowych. Po tym, jak zdarzy się to kilka razy, proces obejmie więcej interesariuszy w etapach przeglądu, a z czasem właściwi ludzie znajdą się we właściwych miejscach we właściwym czasie.

Jest też druga kategoria decyzji, te, które są zarówno wrażliwe na czas, jak i ważne, i trudniej jest zebrać właściwych ludzi w pokoju, zanim te decyzje zostaną sfinalizowane. Często zdarza się, że restrukturyzacja organizacyjna odbywa się bez cennego wkładu, który mógłby zmienić jej wynik. Podobnie, jest to powszechne dla pętli wywiadów dla rzadkich ról – te, gdzie można zatrudnić jedną osobę do nich każdego roku, jak kierownictwo lub Staff-plus inżynierów w firmie na wczesnym etapie – nie oceniają kandydata na ważnym wymiarze. Dla niektórych firm nawet takie rzeczy jak planowanie mapy drogowej należą do tej kategorii.

Staff-plus inżynierowie są ludzie, którzy będą często się niespodziewanie wciągnąć do pokoju, gdzie tego rodzaju decyzji dzieje. Daje im to możliwość wprowadzenia kontekstu inżynierskiego i perspektywy do decyzji, kiedy jeszcze można zmienić jej wynik. Te krótkie chwile wkładu w krytyczne decyzje są niezwykle istotne i pozwolą Ci zachować perspektywę inżyniera. Jest to również moment, w którym łatwo zapomnieć, że Twoją rolą w tych chwilach jest często reprezentowanie interesów całej inżynierii, a nie tylko swoich własnych.

Eksploracja

W mojej obecnej roli w inkubatorze spędzam cały dzień na prototypowaniu, ale w mojej poprzedniej roli lidera technicznego robiłem wiele różnych rzeczy. – Ritu Vincent

Hill-climbing nie rozwiąże każdego problemu, ale jest tak skuteczny, że wiele firm walczy o przyjęcie innych podejść. Może to być firma zorientowana na konsumenta, która zmaga się z obsługą transakcji korporacyjnych lub dojrzała firma, która walczy z mniejszym konkurentem, aby konkurować z jego kadencją wydawniczą. Może to być nawet przypadek, w którym obecna działalność jest tak cenna, że trudno jest nadać priorytet nowym przedsięwzięciom, nawet jeśli tempo wzrostu cennego biznesu spada.

W dłuższej perspektywie firmy albo nauczą się odkrywać, albo znikną; nie jest to wyzwanie, którego nie da się zignorować. Zwykłe przydzielenie zespołu, który opanował wspinaczkę po wzgórzach, do wykonania pracy eksploracyjnej nie jest rzeczą pewną, dlatego wiele firm stosuje inne podejście. Znajdują kilka zaufanych osób o szerokich umiejętnościach, przeznaczają pewne zasoby i po kilku miesiącach sprawdzają, co udało im się odkryć. Jednym z tych inżynierów jest często inżynier ds. personelu.

Nie zawsze jest to też problem biznesowy, może to być dowolny rodzaj niejednoznacznego, ważnego problemu, do rozwiązania którego systemy firmy nie są przystosowane. Może to być zmniejszenie kosztów infrastruktury o rząd wielkości. Może to być określenie strategii wieloregionalnej, która zajmie sześć miesięcy zamiast trzech lat. Może to być zajęcie się nagłym uświadomieniem sobie, że twoja podstawowa baza danych ma tylko trzy miesiące pozostałej przestrzeni dyskowej i nie możesz jej rozbudować do większego rozmiaru (z mojego doświadczenia wynika, że jest to zaskakująco częsty problem w szybko rozwijających się startupach).

To jedna z najbardziej satysfakcjonujących i najbardziej ryzykownych prac, jakie wykonują firmy, i potrzeba wiele organizacyjnego zaufania, aby móc zaufać tej pracy, w tym szacunku ze strony biznesu, że jeśli zawiedziesz, to jest to odzwierciedlenie problemu, a nie ciebie.

Being Glue

Tanya Reilly napisała wspaniały post, Being Glue, który ujmuje kolejny kluczowy element udanych inżynierów personalnych: robienie tego, co konieczne, aby zidentyfikować właściwą pracę i dostać ją do wysyłki. Nie jest to chwalebne, ale organizacje o dużym wpływie często mają jednego lub więcej inżynierów sztabowych pracujących za kulisami, przyspieszających najważniejszą pracę i zapewniających jej ukończenie.

Ale czy nadal będziesz pisał oprogramowanie?

Niegrzecznie jest kończyć jakąkolwiek dyskusję na temat roli inżyniera sztabowego bez wypowiedzenia się na temat pierwszego pytania, które inżynierowie sztabowi zadają, gdy zbierają się razem w pokoju: „Czy nadal znajdujesz czas na pisanie oprogramowania?”. Odpowiedź brzmi, oczywiście, to zależy!

Ras Kasa Williams powiedział: „Wciąż regularnie pisałem kod – z pewnością mniej niż reszta inżynierów w moim zespole; ale ważne było, abym podtrzymywał pracę „z ręki do klawiatury”, aby zapewnić, że moja strategia techniczna (i inne decyzje na poziomie makro) były informowane przez praktyczne doświadczenia reszty mojego zespołu.”

Katie Sylor-Miller powiedziała: „Jestem architektem frontendowym, ale zdecydowanie główną rzeczą, jaką ostatnio piszę, jest SQL, ponieważ przeprowadzam wiele analiz danych. Patrzę na nasze wskaźniki wydajności, aby dowiedzieć się, gdzie są obszary do poprawy i jakie problemy byłyby najbardziej znaczące do naprawienia, aby poprawić wydajność i wskaźniki biznesowe. Piszę małe kawałki JS lub PHP tu i tam, ale głównie po to, by pomóc odblokować zespoły lub przeprowadzić małe eksperymenty związane z wydajnością.”

Silvia Botros powiedziała: „Nie zajmuję się już kodowaniem dla biznesu. Myślę, że ostatni raz, kiedy musiałam wyciągnąć mój terminal, to było w celu refaktoryzacji moich plików dot. To jest celowa decyzja mojego szefa, Głównego Architekta. Co kwartał sprawdza, czy nie napisaliśmy żadnego kodu, który trafiłby do produkcji.”

Joy Ebertz powiedział: „Im wyższa pozycja w hierarchii, tym mniej zajmujesz się kodem. Oczywiście, w przeciwieństwie do menedżera, nadal masz bardzo techniczne nachylenie i nawet przez dyrektora, prawdopodobnie będziesz robić co najmniej trochę kodowania. Jednak im wyżej się dostaniesz, tym bardziej twoja praca staje się o mentoringu i rozwoju ludzi wokół ciebie (i szerzej), budowanie zespołu poprzez budowanie publicznej marki firmy tech, zauważając większe trendy techniczne, które mogą być ulepszone lub skorygowane, pomagając ustawić wizję tech dla swojego zespołu lub firmy i orędownictwo dla zasobów dla projektów długu tech.”

Większość napisać trochę, niektórzy piszą żadnego, ale żaden nie pisze tak dużo, jak kiedyś na początku swojej kariery. Będzie sporadyczny tydzień, który jest czysto kodowania, ale te nie będą normą, a jeśli zdarzają się zbyt często, to zwykle znak pracy na coś wygodnego, a nie ważne.

Slow but rewarding

Jeden wspólny temat w całej pracy Staff-plus jest to, że ramy czasowe są po prostu dłużej. Na początku kariery łatwo jest się przywiązać do szybkiego cyklu informacji zwrotnej w rozwoju oprogramowania – napisz, przetestuj, wyślij, powtórz – a większość pracy, którą będziesz wykonywać na tym poziomie, zastępuje tę pętlę informacji zwrotnej pętlą, która trwa tygodnie, miesiące i lata.

Wpływ i rozwój osobisty odbywa się w tych dłuższych ramach czasowych, a chociaż wszyscy, z którymi rozmawiałem, życzyli sobie, aby od czasu do czasu mieli więcej czasu na kodowanie, żaden z nich nie żałował przejścia do swoich obecnych ról.

Wpływ i rozwój osobisty są w tych dłuższych ramach czasowych.