Można by powiedzieć, że software engineering manager to taki bardzo mocno techniczny menadżer projektu (w przypadku małych projektów role te mogą nie być rozdzielone). Stąd stawiane przed nim zadania są mocno zróżnicowane i zależne od organizacji, w której wybrał pracować.
Software engineering manager jest osobą odpowiedzialną za całościowe “dowiezienie” projektu. Poczynając od określenia strategii i przełożenia specyfikacji na implementowalne części, zadania czy kamienie liniowe (razem z czasowymi estymatami ich realizacji), przez pośredniczenie między klientem a zespołem (lub zespołami developerów), i pilnowaniem by ci mogli wykonać swoją pracę, aż po aktywne uczestniczenie w tworzeniu kodu rozwijanej aplikacji.
Brzmi co nieco rozlegle? Tak właśnie jest.
Software engineering manager to trochę taki “man in the middle”, który musi sprawnie żonglować nieraz sprzecznymi zobowiązaniami (zespół vs klient) i być zarówno programistą, jak i menadżerem (bardziej). Nie musi być jednak technicznym guru – od tego ma choćby architektów oprogramowania, tech leadów czy senior developerów. Powinien jednak naprawdę dobrze orientować się w używanych w ramach projektu technologiach, tak by być w stanie dokonywać sensownych wyborów co do sposobu realizacji postawionych zadań, uczestniczyć w przeglądach kodu czy projektu technicznego. Kwestią kontrowersyjną jest to, ile czasu powinien poświęcać na kodowanie, ale ją zostawię na koniec.
Za co jeszcze odpowiedzialny jest development manager?
Zdarza się, że w jego gestii leżą także kwestie administracyjne związane z projektem (włącznie z planowaniem i kontrolą budżetu) jak i w pewnej mierze tzw. “zarządzaniem zasobami ludzkimi” – dobieraniem członków zespółu, dbaniem zarówno o ich satysfakcję z wykonywanych zadań jak i odpowiednią wydajność.
Powiedzmy to jasno: same umiejętności techniczne i doświadczenie programistyczne nie wystarczą. Częściej niż rzadziej zdarza się, że ktoś kto jest naprawdę świetnym programistą okazuje się marnym liderem czy menadżerem. Tak więc wysoki poziom umiejętności społecznych, zdolność zarządzaniami ludźmi, motywowania ich, dostrzegania przejawów niezadowolenia z pracy czy początkowych (ale jeszcze niewyrażonych) trudności z realizacją postawionych zadań będą bardziej niż przydatne. Do tego dobrze by było, gdybyśmy umieli inspirować do większego wysiłku własnym przykładem zamiast wydawać polecenia, a także tak rozdzielać zadania pomiędzy członków zespołu, by nie tylko były zrealizowane, ale i wnosiły coś dobrego do ich rozwoju zawodowego.
Zarządzanie zespołem to jedna strona medalu.
Drugą są relacje z klientem lub ogólnie “biznesem”. Musimy więc umieć zarówno słuchać jak i rozmawiać z nim w sposób klarowny i zrozumiały. Dobry software engineering manager winien być w stanie w jasno i przejrzyście informować o postępach projektu i napotykanych trudnościach zarówno biznesowych “laików” jak i osoby bardziej techniczne. Musi umieć realistycznie planować i przewidywać potencjalne przeszkody, wyznaczać realistyczne ramy dostarczenia projektu (także czasowe) i nadzorować jego realizację. Dobrze by też było by taki menadżer nieźle radził sobie dobrze z wystąpieniami publicznymi, gdyż może mu czasem przyjść wygłosić gdzieś jakąś prezentację w celach PRowych (w końcu jest doświadczonym specjalistą i ma o czym mówić) lub też wziąć udział w krytycznym spotkaniu z nowym klientem, jako osoba będąca w stanie wyczerpująco odpowiedzieć na techniczne pytania.
Trzecia strona medalu, bo jest i taka wygląda tak, że software engineering manager jednak powinien być osobą techniczną i być w stanie podejmować techniczne decyzje, doradzać developerom, uczestniczyć w przeglądach kodu, a gdy zajdzie potrzeba, zakasać rękawy i samemu wziąć się za kodowanie. Kilka lat doświadczenia programistycznego wydaje się więc absolutnie niezbędne.
Jakie konkretne umiejętności techniczne powinien posiadać, zapytacie?
Trudno tu o jednoznaczną odpowiedź, gdyż wszystko zależy od konkretnego projektu. Patrząc jednak na tę kwestię mocno ogólnie, na pewno powinien naprawdę dobrze znać język lub języki programistyczne używane przez developerów oraz większość technologii, z którymi przyjdzie im pracować. Koniecznie musi znać od podszewki cykl rozwoju oprogramowania i różne metodologie jego tworzenia. Powinien orientować się w trendach dotyczących testowania aplikacji, mocnych i słabych stronach różnych podejść oraz – co chyba coraz bardziej niezbędne na prawie wszystkich technicznych stanowiskach – rozumieć aplikacje działające w chmurze.
Podobnie więc, jak w przypadku architekta oprogramowania nie jest to w żadnej mierze pozycja, od której możemy zacząć przygodę z IT. To raczej interesujący punkt dojścia lub, dla bardziej ambitnych i widzących się jako VP of engineering, niezbędny punkt pośredni.
Jeżeli więc jesteś geekiem, który oprócz umiejętności technicznych posiada rozwinięty, sprawny i wydajny interfejs międzyludzki, to może być coś dla ciebie
Podobnie jak nie jest to stanowisko “entry level”, tak nie jest to pozycja, na którą szuka się freelancerów z łapanki, na krótkoterminowe “fuchy”. Musimy się wobec tego nastawiać raczej na pracę dla dużych klientów i organizacji. Przydać się może lista najlepszych według Forbesa firm zatrudniających zdalnie albo szukanie szczęścia w mniejszych firmach, które zatrudniają wyłącznie zdalnie licząc się z tym, że przyjdzie nam trochę poszukać.
Inną opcją wartą rozważenia jest aplikowanie do Crossover, który zatrudnia tylko i wyłącznie pracowników zdalnych, zarówno na “zwyczajnych” stanowiskach (jak programista) jak i na tych znacznie wyższych (jak np. wiceprezes do spraw inżynierii oprogramowania).
Rozwiązaniem dla naprawdę zdesperowanych lub przebiegłych, jest z kolei rozpoczęcie pracy od stanowiska biurowego, a po udowodnieniu swojej wartości i okrzepnięciu w firmie poproszenie o pracę zdalną pod groźbą odejścia. Jak pokazuje niedawny przykład mojego własnego przełożonego (tech leada co prawda, ale jednak), jest to manewr, który może zakończyć się sukcesem, ale by mógł się powieść, musimy być gotowi naprawdę odejść, jeśli nie dostaniemy tego, co chcemy.
No cóż, do biednych na pewno nie należy i głodem na przednówku nie przymiera. W końcu to wyższa szarża technicznego światka!
W zależności od zakresu obowiązków i wielkości firmy stawki zaczynają się tu od jakiś 15-20 tysięcy złotych na miesiąc na B2B. Rosną wraz z przemieszczaniem się na zachód globu i dochodzą tam do poziomu prawie $170 000 na rok (czyli jakichś 60 tysięcy złotych na miesiąc), choć w takim USA mediana znajduje się bliżej “marnych” 45 tysięcy złotych na miesiąc.
Jeżeli i to jednak nie jest wystarczającym wynagrodzeniem pozostaje nam jedynie piąć się wyżej po drabinie kariery w kierunku dyrektora czy wiceprezesa ds. inżynierii oprogramowania, których pensje osiągają poziom ponad miliona złotych rocznie. Tak więc nawet jako software engineering manager będziemy mieli do czego dążyć
Na koniec pora na wspomnianą kontrowersję, gdzie jak na takową przystało zdania są podzielone i wahają się od podejścia “nie kodowałem od kilku lat, więc to coś dla mnie”, do “skoro nie kodujesz przez większość czasu pracy, to marny z ciebie engineering manager”. W rozsądnym miejscu między tymi skrajnościami zdaje się lokować podzielane przeze mnie zdanie Eliota Horowitza będącego CTO MongoDB. Jak jest jego odpowiedź? Przynajmniej 30% czasu pracy.
Dlaczego akurat tyle?
Mówiąc w skrócie (więcej szczegółów znajdziecie w jego artykule tutaj) jest dobry pomysł, gdyż pomaga:
Jak dla mnie trzyma się to kupy i zdecydowanie wolałbym pracować z menadżerem, który “wie z czym się to je” zamiast pozostawać bujającym w obłokach teoretykiem. A wy?