Kluczowe problemy

1. Dlaczego matryca kariery zawodowej w wielu firmach jest wadliwa i uniemożliwia pracownikowi podążanie czysto techniczną ścieżką kariery?
2. Na ile ryzykowny jest awans osoby zorientowanej technicznie na pozycję lidera. Jakie są wady i zalety?
3. Jak uniknąć tego typu pułapek z czysto technicznego punktu widzenia?

Artykuł jest refleksją na temat technicznej ścieżki zawodowej i procesu stopniowego rozwoju, opisuje pewne popełniane błędy podczas wspinania się po szczeblach kariery zawodowej, od pozycji programisty do technical i team leadera, aż do stanowiska project managera. W rzeczywistości to nic innego, jak oddalanie się od czysto technicznych czynności (np. kodowania, programowania, głębokiej wiedzy technicznej) i zastępowanie ich spotkaniami, prezentacjami, papierkową robotą i zarządzaniem ludźmi. Dla niektórych jest to zapewne wygodne podejście (lepiej czujemy się w roli team leadera lub project managera ), lecz w większości przypadków przyczynia się do ogólnej degradacji nabytych z trudnością umiejętności technicznych i uniemożliwia podniesienie kompetencji z technicznego punktu widzenia. Spróbujmy zagłębić się w temat i zastanowić się, dlaczego tak się dzieje i w jaki sposób można zmienić ten schemat.

Zaczynając od samego początku, w okresie dzieciństwa chodzimy do szkoły i uczymy się rzeczy, które mają nam pomóc w byciu wykształconymi i dysponowaniu podstawową wiedzą. Następnie podejmujemy naukę na uczelni, gdzie otrzymujemy specjalizację w wybranej dziedzinie (np. informatyce, medycynie, ekonomii, inżynierii itd.) i to, przynajmniej teoretycznie, pomaga nam w znalezieniu lepszej pracy. Podążamy tą ścieżką, ponieważ nie posiadamy żadnej innej alternatywy; nasze społeczeństwo jest zbudowane w ten sposób, nieważne czy jest on efektywny, czy też nie. W mediach pojawiają się historie o garstce ludzi bez studiów, którzy zostali bogaci i sławni (np. Larry Ellison, Amancio Ortega), prowadzące do wniosków, że szkoły są nieskuteczne, ponieważ nie przygotowują swoich uczniów do prawdziwego życia. Osobiście, nie jestem zwolennikiem tego założenia.

Następnie, kończymy szkołę i dostajemy swoją pierwszą pracę jako junior developer. Zmagamy się, by wdrożyć w życie wyuczoną ze szkoły wiedzę i nagle zdajemy sobie sprawę, że to nie wystarczy, ponieważ rzeczywista praca wymaga głębszej wiedzy i bardziej profesjonalnego zakresu umiejętności. Wówczas zaczynamy uczyć się coraz więcej i entuzjastycznie przyjmujemy wyzwania techniczne, ponieważ jesteśmy młodzi i mamy bardzo silną motywację do wszystkiego. Po paru latach bycia na stanowisku junior developera, dostajemy szansę awansu. Jesteśmy dumni z siebie, teraz jesteśmy bardziej autonomiczni i lepiej opłacalni. Jednak po kilku następnych latach, podczas gdy staramy się zdobyć więcej umiejętności technicznych, aby mieć dobrą reputację w zespołach, by zostać człowiekiem, którego inni zazwyczaj pytają o poradę techniczną, właśnie wtedy dostajemy następną promocję, lecz tym razem na stanowisko team leadera.

I z radością akceptujemy ją! Teraz przewodzimy własnym zespołom, lecz w domyśle spędzamy więcej czasu na spotkaniach, wysyłamy e-maile, szlifujemy prezentacje, wypełniamy dokumenty i mniej kodujemy. Jeśli wcześniej kodowaliśmy po 5-6 godzin dziennie lub nawet więcej, teraz ledwie mamy czas, by kodować 3-4 godziny, a czasem nawet 1-2 godziny dziennie. Przed awansem poświęcaliśmy wiele czasu na rozwijanie swoich umiejętności technicznych, a nagle oddalamy się od nich. Czy to nie jest absurdalne!? Dlaczego tak się dzieje? Jesteśmy kierowani, by zostać team leaderami, ponieważ branża IT (w większości przypadków) w domyśle prowadzi nas do tych ról, dlatego że praca jest lepiej płatna i nasze ego jest bardziej dumne z tego stanowiska.

W większości firm ścieżki kariery są oparte na właśnie takim, nieidealnym wzorcu, nie ma standaryzowanej czysto technicznej ścieżki rozwoju, a po przekroczeniu pewnego poziomu jest tylko techniczno-nietechniczny miks, który w domyśle zastępuje i degraduje poprzednie stanowisko. Niniejsza matryca kariery zawodowej, zamiast pomóc ludziom z odpowiednią kwalifikacją techniczną przez promowanie ich na stanowiska, na których mogliby rozwijać swoje umiejętności techniczne (np. dalej zajmować się kodowaniem i researchingiem), stopniowo zabiera im te umiejętności.

Kto w takim razie wymyślił tę niedokładną matrycę rozwoju? Prawdopodobnie obecna wadliwa struktura była stworzona zgodnie z biznesowo-dochodowymi strategiami firmy, lecz jest ona także powszechnie akceptowana przez nas. Większość ludzi myśli, że kodowanie przez całe życie nie jest ambitnym wyzwaniem, stąd też potrzeba wyzwolenia się od tego działania po paru latach i objęcia bardziej znaczącej roli w zespole.

Według mnie, jest to całkowicie fałszywe przekonanie. Jeśli lubisz kodowanie, rób to do końca swojego życia! Bycie pasjonatem doprowadzi do odkrycia zupełnie nowych metod technologicznych i pomoże w osiągnięciu skutecznego rozwoju w branży.

W celu uniknięcia tych kwestii, należy dogłębnie zrozumieć, co nas motywuje i w czym chcemy osiągnąć postęp z technicznego punktu widzenia. Jeśli mamy silną motywację, by zostać geekiem, facetem od technologii, moja rada jest taka, by nie przechodzić na żadną pozycję lidera, która narzuca umiejętności nietechniczne na rzecz umiejętności technicznych. Kontynuuj uczenie się nowych rzeczy i kodowanie przez większość czasu (np. przez cały dzień) i nie daj się skusić tego rodzaju stanowiskom kierowniczym. Może się tutaj pojawić problem z ego, lecz w końcowym rozrachunku dojdziemy z tym do ładu, ponieważ robimy coś, co sprawia, że jesteśmy zmotywowani. Oprócz tego, możemy rozwiązać te problemy wewnątrz naszego zespołu i wytłumaczyć naszym managerom, że matryca kariery jest wadliwa, mając nadzieję, że zapewnią nam wsparcie i skorygują niedoskonałości przez usprawnienie i utrzymanie czystej ścieżki technicznej, ze stanowiskami dyrektora technicznego, doradcy technicznego itp.

Przy użyciu analogii, wyobraź sobie, co by było, gdyby tak wspaniałe umysły jak Barbara Liskov, Grace Hopper, Leslie Lamport i in. zaprzestały kodowania i researchingu po paru latach ze względu na awanse na stanowiska z mniejszym wpływem technicznym! Najprawdopodobniej obecnie nie słyszelibyśmy o nich, ponieważ ich wkład do przemysłu IT byłby o wiele mniejszy.

Zasada Laurence J. Petera głosi: "wybór kandydata na stanowisko zależy od osiągnięć kandydata na obecnym stanowisku, a nie od umiejętności potrzebnych na przewidzianym stanowisku", co jest ogólną prawdą w naszej branży. Ludzie wspinają się po szczeblach kariery do czasu osiągnięcia pewnego poziomu nieefektywności, ponieważ kontynuujemy awansowanie ludzi na stanowiska, na których umiejętności i zdolności nie uzupełniają się nawzajem w naturalny sposób, lecz raczej konkurują ze sobą i zastępują się, szczególnie podczas przejścia z pozycji technicznych na nietechniczne.

Uważam, że powinno się określić bardziej naturalną ścieżkę rozwoju, a awansowanie ludzi powinno być przeprowadzone lepszymi sposobami, bez utraty ich zdolności technicznych oraz pomagając im w ciągłym rozwoju technicznym.

Ionut Balosin 
Software Architect