Jak skrzywdzić developera?

Trudna sztuka awansu, czyli jak awansować programistę, nie robiąc mu przy tym krzywdy.

Junior – Mid/Regular – Senior. Ścieżka ewolucji developera wygląda z grubsza tak samo. Jest ona raczej niezależna od wieku programisty (na potrzeby artykułu używam zamiennie słowa programista i deweloper – chodzi z grubsza o osobę programującą).
Można wyobrazić więc sobie 23-letniego wymiatacza, który napisał w React Native 8 komercyjnie udanych aplikacji i pracuje na stanowisku seniorskim. Można sobie też wyobrazić 56-letniego Rust developera, który był seniorem w Cobolu, ale stwierdził, że pieniądze to nie wszystko, liczy się rozwój. Przykłady trochę z dupy, w dodatku brakuje w nich postaci kobiecych, ale potrzebuję ich tylko do ilustracji wywodu. Zresztą, trochę odeszłam od głównego wątku.

Czy istnieje życie po Seniorze?

Junior – Mid/Regular – Senior. Czy ścieżka kończy się na Seniorze? Czy Seniora da się awansować? Spróbuję zniuansować te pytania.

Oczywiście ścieżka zawodowa programisty nie kończy się na stanowisku seniorskim. W zespołach są dodatkowe funkcje, mniej lub bardziej techniczne, na które może być awansowany programista. Abstrahując od tych raczej komicznych, jak Scrum Master czy Agile Coach, można wskazać co najmniej dwie ścieżki awansu Seniora, które wymagają nieco lub znacznie odmiennych kompetencji niż tzw. klepanie kodu. Są to:

1. Obszary związane z achitekturą oprogramowania, rozwiązań, integracji
2. Management

W tym poście skupię się na punkcie drugim.

Złote szaty Managera

Niestety w korpo panuje kult Managera i oczywistym wręcz kierunkiem awansu dla wyróżniającego się dewelopera-seniora jest stanowisko Team Lead(er)a. Albo po prostu Managera/Kierownika IT, jeśli firma nie bawi się w nazewnicze niuanse. Pod tymi nazwami często kryje się zarządzanie zespołem deweloperskim, czasem również jego odnogami: analitykami, testerami, DevOpsami, bazodanowcami, etc.

Awans programisty na stanowisko kierownicze wiąże się dla niego/niej zazwyczaj z jeszcze większymi pieniędzmi i – w niektórych kręgach – prestiżem i nobilitacją. Drugą stroną medalu jest jednak wieloaspektowe niedostosowanie osoby awansowanej: kompetencyjne, psychiczne, osobowościowe, wizerunkowe. Odniosę się do pierwszego aspektu, bo nie chcę popaść w naiwne psychologizowanie i bida-coaching.

Zasada Petera

Coś już o tym pisał Laurence J. Peter. Sformułowaną przez niego zasadę można podsumować następująco: pracownik awansuje tak długo, aż przekroczy swój próg kompetencji. Ta zgrabna formuła została przez Petera przedstawiona w 1969 roku i odnosiła się co prawda do amerykańskich organizacji ze sztywną strukturą i mocno ugruntowaną hierarchią stanowisk. Spróbujmy ją jednak przenieść na nasze branżowe poletko.

Awans na linii junior-mid-senior to przyrost kompetencji przede wszystkim twardych: lepsza znajomość języka programowania, używanych platform, IDE, Gita, frameworków, CI/CD, wrażliwości na code smells etc. Jest to zmiana na osi wertykalnej, bo – przynajmniej w teorii – za awansem podąża wzrost kompetencji.

Z kolei awans z pozycji Seniora na Managera/Leada jest to już duża zmiana jakościowa, wymagająca zupełnie innych umiejętności. Nierzadko są to kompetencje, których dana osoba nie będzie w stanie nabyć, bo są one sprzeczne z jej cechami osobowości – tymi cechami, które czyniły z niej dobrego programistę. Sprawnego managera powinna cechować m.in. asertywność, zdolności komunikacyjne, umiejętność delegowania obowiązków i przydzielania zadań, multitasking, wysoka odporność na stres i presję ze strony line managementu, pewność siebie, panowanie nad budżetem, pewnego rodzaju przebojowość, bo za bardzo nie wiem, jak nazwać taki managerski drive, dzięki któremu nawijanie makaronu na uszy i wydalanie z siebie wizji mlekiem i działającym softem płynących przychodzi takiej osobie naturalnie. Ach, nie zapominajmy o zdolności robienia dobrze biznesowi, często kosztem teamu deweloperskiego. Brzmi znajomo?

Wskazane cechy są, jeśli nie sprzeczne, to odbiegające od typowych miękkich kompetencji programisty: skupionego raczej na jednym zadaniu, wnikliwego, kontemplującego problem zanim znajdzie dla niego rozwiązanie, zmęczonego jednym „callem” dziennie, z którego samo daily zdążyło wyssać pokłady towarzyskości i chęci rozumienia innych problemów niż te, którymi obecnie się zajmuje. Oczywiście jest to bardzo stereotypowy obraz, ale, hmm… Może jest coś w tym na rzeczy.

Drugą stroną medalu też jest to, że awansując dobrego dewelopera na stanowisko managerskie team traci dobrego dewelopera. Rzadko bowiem zdarza się sytuacja, że programista awansowany na stanowisko kierownicze ma czas i chęć na pracę z kodem. Dobry dev to skrupulatny dev, myślący holistycznie, łączący kropki, znający architekturę, zawy i zalety systemów, z którymi pracuje (co nierzadko równa się posiadaniu tribal knowledge). To wszystko w dużej mierze tracimy, kiedy awansujemy dobrego developera na stanowisko managera. Osoba raz awansowana na managera ma już na tyle podłechtane ego, że choćby było to najgorsze dla niej stanowisko w wymiarze osobistym, to będzie się go trzymać w imię niepoślednich przywilejów, które się w nim wiążą. Ach, ten bynajmniej niedyskretny urok władzy i pieniędzy.

Kasy, nie igrzysk

Podsumowując.

1. Bardzo developer może okazać się bardzo słabym managerem.

Nie ma tutaj przełożenia kompetencji, bo to dwa odrębne dziedziny ekspertyzy, wymagające innych kompetencji. Tak, manager też ma kompetencje, nie bez przyczyny na te stanowiska pchają się osoby takie, jakie właśnie przydzielają wam zadania.

2. Słaby deweloper może być bardzo dobrym managerem.

W dodatku z technicznym backgroundem – a akurat takich managerów ze świecą szukać w niejednym korpo. Czasem jednak taka osobie kompensuje sobie brak sukcesów na gruncie programistycznym i przepoczwarza się w managera przekonanego o swojej omnipotencji, z rozdętym ego, apodyktycznego i motywowanego głównie swoją Schadenfreude. W ogóle bycie dobrym managerem IT to jest wbrew pozorom trudne wyzwanie, ale to już temat na osobny post.

Chcącemu nie dzieje się krzywda

To co z tym awansem? Chciałoby się odpowiedzieć wszędobylskim, werbalnym wytrychem „to zależy”. Zależy między innymi od preferencji samego programisty. Niektórzy lepiej odnajdują w maintenance, niektórzy w product developmencie i architekturze rozwiązań, niektórzy w pewnym momencie życia wypalają się jako programiści i otwierają budkę z craftowym kebabem albo winiarnię na lubelszczyźnie.
Niektórzy chcą wyjść ze swojej strefy komfortu (what?!) i iść w management, mimo że wszystkie znaki na niebie i pod ziemią wskazują, że to kiepska decyzja. No cóż, chcącemu nie dzieje się krzywda.

Niektórym, jeśli nie większości, zależy głównie na kasie, czyli bezpieczeństwie finansowym, i dla takich osób największym awansem jest brak awansu i podwyżka. Czytaj: pozostanie w swojej strefie ekspertyzy (komfortu), za które dostaje coraz większe pieniądze. I taką ścieżkę nagrody widziałabym dla dobrego dewelopera, jeśli nie interesuje go management.