To jest 109. odcinek podcastu Porozmawiajmy o IT, w którym to wraz z moim gościem rozmawiam o tym, kim jest senior developer. 

Przypominam, że w poprzednim odcinku rozmawiałem o atakach na strony i ich zapobieganiu. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/109. 

Ocena lub recenzja podcastu w twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. 

Partnerem tego odcinka jest firma cyber_Folks, oferująca szybki i bezpieczny hosting jak również domeny i certyfikaty. Cyber_Folks to nowoczesna firma, która oferuje mnóstwo zabezpieczeń oraz darmowych narzędzi, m.in. audyt Twojej strony, wykonany w kilka sekund czy generator polityki prywatności. 

Sprawdź ofertę na https://cyberfolks.pl/. 

Sponsorem dzisiejszego odcinka jest również platforma rekrutacyjna SOLID.Jobs. Jeśli szukasz pracy w IT, koniecznie odwiedź adres: https://solid.jobs/. Znajdziesz tam oferty pracy z widełkami wynagrodzeń. Jeżeli aktualnie nie myślisz o znalezieniu nowej pracy, to koniecznie zapisz się na jobalert. Otrzymasz regularne wiadomości e-mail z zestawieniem ofert, które mogą cię zainteresować. Jeśli w swojej pracy nadal korzystasz z SVN-a, to koniecznie odwiedź SOLID.Jobs. 

Nazywam się Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest m.in. ten podcast. Zostając patronem na platformie Patronite, możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły! 

Jednocześnie bardzo dziękuję moim obecnym patronom. 

Teraz, nie przedłużając, życzę ci miłego słuchania. Odpalam! 

 

Cześć! Mój dzisiejszy gość to współzałożyciel i CTO Bitnoise. Tata trzech córek, entuzjasta szeroko pojętych nowych technologii, od ponad 18 lat związany zawodowo z branżą IT. Przygodę z programowaniem zaczął od Atari 65XE.

Obecnie współwłaściciel Bitnosie, również w roli CTO. Obserwuje świat It z dwóch perspektyw: inżyniera i biznesu. W wolnych chwilach kupuje gry, w które nie ma czasu grać, marnuje czas przy serialach, a zamiast spać, czyta książki. Bardzo dziwne hobby!

Balansu i czystej głowy szuka na motocyklu i na rowerze. Moim i Waszym gościem jest Łukasz Roth.

Cześć, Łukasz! Miło mi gościć cię w podcaście.

 

Cześć, Krzysztofie! Dziękuję ci bardzo za to wprowadzenie. Mam nadzieję, że moja perspektywa pozwoli na ciekawą rozmowę i ciekawe spojrzenie na rzeczy, o których będziemy dzisiaj rozmawiać.

 

No właśnie! Będziemy rozmawiać o temacie trochę z IT, trochę z HR-ów, trochę z różnych punktów widzenia. Mianowicie o tym, kim jest, jak my definiujemy senior developera, jaka jest odpowiedzialność takiej osoby w firmie. Cieszę się bardzo i czekam na tę rozmowę!

Na początek muszę cię przepytać na okoliczność słuchania podcastów, jak to robię z moimi gośćmi. Czy słuchasz podcastów? Może masz jakieś swoje ulubione audycje?

 

Muszę przyznać, że od podcastów jestem uzależniony z racji tego, że jak typowy człowiek z IT lubię się ze słuchawkami i przy pracy codziennej często siedzę z nimi na głowie i tak mi zostało, więc w chwilach wolnych tak samo, starając się nie marnować czasu.

Natomiast słucham wielu podcastów, jak próbowałem sobie przygotować listę najważniejszych, wyszło mi ok. 30! Żeby więc nie powielać tych, których pewnie słucha więcej osób, bo ja jak inni z naszej branży słucham o biznesie, IT, natomiast mam też trochę rzeczy politycznych, trochę growych, trochę sportowych, natomiast ostatnim moim odkryciem jest bardzo fajny podcast anglojęzyczny, Darknet Diaries. Myślę, że to jest świetna pula bodajże 80 odcinków opowiadających trochę w taki sposób reporterski o zagrożeniach w sieci, o prawdziwych case’ach z włamań, hackingu. 

Myślę, że to jest taka rzecz, którą de facto wszyscy powinniśmy posłuchać, a jest to naprawdę profesjonalnie, fajnie zrobione, także szczerze polecam! Super sprawa. 

 

Świetnie, dzięki za tę rekomendację i cieszę się, że nie tylko ja mam podcastoholizm – to jest chyba taka niezdefiniowana jednostka chorobowa, ale widzę, że coraz więcej osób mówi o tym, że jest uzależnionych od słuchania podcastów. Myślę, że bardzo fajna forma do tego, żeby się uczyć, żeby czerpać jakąś rozrywkę. 

Cieszę się, że też widzisz w tym wartość!

 

To jest doskonała alternatywa do ebooków czy audiobooków. Świetne źródło wiedzy. 

 

Pewnie! 

Okej! To zacznijmy rozmowę o stanowiskach w IT, które bardzo często definiuje się przez pryzmat lat doświadczenia. Powiedzmy ten junior rok, dwa, później do trzech, czterech mid, pięć i wyżej powiedzmy, senior. To jest najczęściej powielająca się perspektywa, jak sobie spojrzymy np. na oferty pracy. Czy według ciebie to jest dobre podejście do definiowania naszego zaawansowania w branży?

 

Myślę, że absolutnie nie. Wydaje mi się, że można mieć 10, 15 lat doświadczenia, ale w tak bardzo wąskiej specjalizacji, czyli możemy utknąć w zespole lub też w projekcie, produkcie na wiele, wiele lat. I bezpośrednio nasze doświadczenie wynikające tylko ze stażu pracy, nie będą się przekładały na twoje doświadczenia, na takie holistyczne podejście do projektów, na kontakt z wieloma aspektami naszej pracy, bo dawno się już zmieniła perspektywa tego, że programista jest takim typowym borsukiem, który siedzi przy swojej klawiaturze, nie ma kontaktu z rzeczywistością, natomiast dostarcza fantastyczne linijki kodu. 

Myślę, że w kontekście całej tej sytuacji, lata doświadczenia można albo spędzić bardzo produktywnie, albo można je przepalić. Można też nie mieć żadnych aspiracji, bo warto wspomnieć też o tym, że niektóre osoby po prostu lubią w ten sposób swoją działką się zajmować i pewnie ciężko jest mówić o tym, żeby oni zmarnowali w jakiś sposób swój potencjał lat, bo to dla każdej osoby jest co innego, im przynosi satysfakcję i to też jest wartościowe. Natomiast do takiego rozwoju perspektywistycznego w kierunku „seniora” myślę, że same lata nie wystarczą. Myślę, że to jest kwestia dotknięcia przez te lata szerszych aspektów naszej pracy. 

 

Zgadzam się z tym! Skoro zgodziliśmy się, że jest to uproszczenie, to chcę cię zapytać, kim według ciebie jest senior developer i jakbyś mógł w kilku słowach powiedzieć, czym dla ciebie się różni od junior developera?

 

Dla mnie taka osoba bardzo doświadczona – może niekoniecznie nazywajmy ją „seniorem”, bo konotacje mogą być różne – przede wszystkim wyróżnia się tym, że na projekty, problemy z jakimi spotyka się IT patrzy bardziej holistycznie. 

Mamy więc ludzi, którzy nie tylko wiedzą, jak jakąś rzecz zrobić w jakimś konkretnym języku, ale są też świadomi konsekwencji, infrastruktury, są świadomi, co przynosi wartość biznesową, co nie. Potrafią dużo bardziej świadomie podjąć pewne decyzje niż osoba o mniejszym stażu, doświadczeniu. 

 

Mamy więc ludzi, którzy nie tylko wiedzą, jak jakąś rzecz zrobić w jakimś konkretnym języku, ale są też świadomi konsekwencji, infrastruktury, są świadomi, co przynosi wartość biznesową, co nie. Potrafią dużo bardziej świadomie podjąć pewne decyzje niż osoba o mniejszym stażu, doświadczeniu.

 

Potrafi też na pewno przewidywać potencjalne problemy. Czyli to są zazwyczaj osoby, które są bardzo nielubiane przez biznes, bo często ich pytania są tzw. kłodami pod nogi. Ale to są rzeczy, z którymi ta osoba się wcześniej wiele razy spotkała, przerobił to paręnaście, parędziesiąt razy, wie, o co zapytać, wie co może pójść nie tak. 

Z drugiej strony potrafi świadomie odstępować od jakichś zasad, które zostały gdzieś wypracowane. Czyli jeżeli senior ma dowieźć coś na czas, to jest w stanie podjąć świadomą decyzję o tym, że idziemy w danym problemie trochę na skróty lub pomijamy testy. Ale to też odróżnia juniora od seniora, że senior zrobi to świadomie i za jakiś czas będzie w stanie albo do tego wrócić, albo będzie w stanie zdefiniować to na przyszłość, natomiast osoba o młodszym stażu popełnia i robi tak, oby było. 

Generalnie nazwałbym to takim holistycznym podejściem do projektów i problemów, natomiast widząc detale to myślę, że drugim ważnym aspektem jest cały szereg miękkich kompetencji plus świadome łamanie zasad. Myślę, że to też jest bardzo ważna rzecz. 

 

Czyli wiem, co robię albo jeśli robię coś niezgodnie z zasadami, to podejmuję to ryzyko i zaciągam ten dług świadomie. Wiem, do czego to może prowadzić, ale mimo wszystko wdrażając różne za i przeciw, podejmuję taką, a nie inną decyzję. 

 

Robimy to też z pełną odpowiedzialnością. Jak podejmiemy taką decyzję, to jesteśmy świadomi konsekwencji, ale jeżeli później pojawi się jakikolwiek problem, to jestem w stu procentach świadom tego, co zrobiłem. Potrafię ponieść konsekwencje. Potrafię też przede wszystkim wytłumaczyć, bo to też jest bardzo ważne. 

 

Właśnie – myślę, że dotknąłeś bardzo ważnego obszaru, a mianowicie odpowiedzialności, jaką można wziąć na siebie. Jako junior ta odpowiedzialność dana mi jest dosyć wąska, mogę, ale nie muszę się poczuwać do tego, żeby brać ją większą, a od seniora oczekuje się tego, że będzie brał większą odpowiedzialność i że będzie w tym świadomy. Myślę, że to też jest jeden z wyróżników, który może nam podpowiedzieć przynajmniej, kto w zespole jest seniorem, mimo tego, że tych lat doświadczenia jeszcze nie ma aż tyle. 

Holistycznie patrzy na projekt i bierze tę odpowiedzialność na siebie. 

 

Dokładnie tak. Myślę, że często jest rola nienazwana, sama się kreuje w zespole i wynika trochę z konsekwencji codziennej pracy. Ludzie często sami wybierają osobę, do której idą z pytaniem, z problemem. To też jest wartościowe i trafne, co powiedziałeś. 

 

Skoro tak jest – to efekt nabierania doświadczenia, jakiejś szerszej perspektywy, to domyślam się, że nie ma czegoś takiego, że we wtorek jestem midem a w środę nagle zostałem seniorem, bo doznałem olśnienia. 

To zazwyczaj jest ciągły, bardziej rozszerzony w czasie proces. 

Wobec tego może się rodzić pytanie: kiedy albo na podstawie jakich czynników, obserwacji, mogę uznać, mogę nazwać siebie seniorem, mogę myśleć o sobie jako senior developer?

 

Myślę, że to ciekawy temat, bo dla mnie łatka juniora, mida, seniora to jest super charakterystyczne dla naszej wąskiej branży IT, bo ciężko mi sobie wyobrazić chirurga, który przechodzi przez cały proces edukacji i robi potem wszystkie potrzebne staże, dokumenty, formalności, nabywa tego doświadczenia. Potem mamy nagle junior chirurga, któremu pozwalamy się diagnozować, mamy mida chirurga, któremu pozwalam zbadać kolano i mamy seniora, który robi operację na otwartym sercu. 

To jest bardzo charakterystyczne dla naszej branży – natomiast myślę, że największy wpływ na tę łatkę czy ocenę seniora ma organizacja, w której się znalazłeś. Jeżeli pracujesz jako programista w startupie, zakładam, że tam nie ma podziału ról. Jeśli jesteś w jakiejś większej organizacji – nie mówię, że coś jest lepsze lub gorsze, myślę, że to jest po prostu definiowane przez daną organizację i przez to dana osoba trafi na jakąś ścieżkę, jakie ma potrzeby, jak chce się rozwijać. 

Obserwując to z boku widzę to tak, że większe organizacje bardzo często, tak jak wspomniałeś wcześniej, wprowadzają pewną ścieżkę kariery, wypełniasz odpowiednie – czy nabierasz odpowiednich kompetencji w czasie, przechodzisz wyżej w tabelce i myślę, że organizacja definiuje to, na jakim „poziomie” jesteś. 

Natomiast myślę, że to, co jest wartościowe dla mniejszych organizacji, mniejszych zespołów, bardziej elastycznych czy też startupów, to jest to, że ta rola często wynika nie wprost, dzieje się trochę naturalnie, trochę organicznie. W zespołach często wyrastają osoby, które stają się nienazwanym seniorem. Łatwo to poznać. Zazwyczaj jest kolejka do tych osób, są to osoby, które są wypychane na spotkania z klientami. Jeżeli pojawia się jakiś problem, trzeba go omówić, wyjaśnić, wytłumaczyć – czasami jest tak, że w zespole ktoś musi podjąć pewną decyzję i tak jak wcześniej mówiliśmy, ponieść konsekwencje decyzji, to jest to, co moim zdaniem definiuje takiego seniora, osobę dojrzałą w projekcie czy dojrzałego developera. 

 

Tak. Bardzo fajne określenie! Sam lubię myśleć o tym jako o połączeniu dwóch słów. Senior – to rozumiem przez taką dojrzałość życiową i developer – czyli osoba, która ma po prostu jakiś techniczny skill, umiejętności, którymi potrafi się posługiwać. 

Chciałbym zacząć od tych umiejętności technicznych. Czy według ciebie jest jakiś uniwersalny ich zestaw czy jakichś obszarów, które taka osoba powinna opanować, którymi powinna umieć się posługiwać, żeby można było o niej powiedzieć, że ma ten skill techniczny na poziomie senior developera?

 

Całkowicie się zgodzę z twoją tezą. Uważam, że zupełnie naturalnymi umiejętnościami są te, których nabywamy latami. Jeżeli ktoś pracuje przy projektach, siedzi przy komputerze godziny, miesiące, lata, to nabiera pewnych umiejętności technicznych, których nie da się w żaden inny sposób wypracować. Mówię tu o takich rzeczach jak umiejętność korzystania ze swoich narzędzi na komputerze. Ciężko mi sobie wyobrazić dojrzałego develpera, który nie jest biegły w podstawowych narzędziach, z którymi na co dzień pracuje, już pomijając czy to będzie git, IDE czy jakikolwiek edytor tekstu, odrobina infrastruktury, poruszanie się po znanych mu rzeczach. Zakładam, że w tych po prostu powinien być biegły. 

Tak samo nie wyobrażam sobie, żeby osoba doświadczona zupełnie naturalnie nie była biegła z pierwszym językiem programowania. Albo nawet nie w pierwszym, ale w takim, w którym aktualnie pracuje, bo to też jest tak, ze zdolności senioralnych – tak jak mówiliśmy wcześniej, związanych z doświadczeniem życiowym, dojrzałością człowieka, natomiast to, w jakim on aktualnie momencie, języku pracuje, to też jest, tak, że nie powinien się zastanawiać czy zaglądać za każdym razem na Stack Overflow, jeżeli ma podstawowy problem, Ale to też nie jest rzecz, której trzeba się uczyć- ona będzie zupełnie naturalna i naturalnie, z konsekwencją tego, w jaki sposób my pracujemy czy co robimy na co dzień, jak ta osoba… Z czym spędza czas! 

I wydaje mi się – to już jest znowu trochę z pogranicza technologii, trochę spraw miękkich. Zakładam, że ta osoba przez lata dotknęła wielu aspektów, nawet tych, w których nie jest jakimś ekspertem, to jest w stanie na te tematy się wypowiedzieć, przeprowadzić rekrutację na inne stanowisko niż to, na którym on pracuje czy nawet język, technologia – po prostu ma ogólne o niej pojęcie i z niejednego pieca jadł chleb w swoim życiu i pracował przy różnych stackach, z różnymi klientami, problemami, więc na poziomie narzędziowym to jest osoba, która nie powinna mieć już żadnych problemów z takim szeroko pojętym podejściem do technologii. 

 

Zgodziłbyś się, że można taką osobę nazwać jako doskonałego rzemieślnika? Osobę, która ma te narzędzia na tyle opanowane, że potrafi się nimi sprawnie posługiwać na co dzień? 

 

Myślę, że tak. Że właśnie to też na poziomie takim narzędziowym już, bo to jest to, co odróżnia osobę, która generalnie siada do komputera i może być nawet super fajnym gościem, który przepracował X czasu w jakimś swoim IDE, ale nagle okazuje się, że w firmie mamy zupełne inne narzędzia i ta osoba już ma problem, żeby się na coś przestawić, natomiast osoba, która przez lata pracowała z różnymi narzędziami po prostu ma dużą zdolność i łatwość do tego, żeby chociażby zmieniać swój stack, narzędzia czy ogólnie „poruszać się na komputerze”. 

 

 Kilka razy z twoich ust padło określenie „umiejętności miękkie”. Spotykam się z tym, że coraz częściej mówi się o nich jako „power skills” – mogą być mocarne i faktycznie nieraz nawet przeważające. 

Jak to jest z tymi umiejętnościami, jeśli chodzi o seniora? Powiedziałeś, że może się zdarzyć, że biznes często wypycha taką osobę do spotkań z klientami, ponieważ potrafi się dogadać, porozumiewać, przedstawić pewne pomysły w zespole, namówić ludzi. Cały szereg umiejętności. 

Jestem ciekaw, jak ty na to patrzysz. Jeżeli kogoś rekrutujesz do zespołu, czy bierzesz to pod uwagę? 

 

Myślę, że najciekawszym odniesieniem może być powrót do moich początków pracy jako programista. Nigdy nie byłem też wybitnym programistą, ciężko byłoby mi nazwać się seniorem nawet gdy startowaliśmy w Bitnoise we dwójkę z Adrianem, 12 lat temu. 

Myślę, że moją mocną stroną było to, że zawsze starałem się robić rzeczy, które rozumiałem, więc dla mnie zrozumienie biznesu i taka naturalna rozmowa z klientem o tym, co będziemy wdrażać, dlaczego będziemy to robić i przed podjęciem jakichkolwiek decyzji starałem się w pełni zrozumieć scope rozmawiając z klientem. Myślę, że to było moją mocną stroną na początku, tak samo, jak startowaliśmy w Bitnoise byłem jedynym programistą. Zostałem wypchnięty do tego, żeby przedyskutować pewne rzeczy z klientami. Myślę, że tej senioralności nabierałem z czasem, więc myślę, że to jest super ważne. 

Z perspektywy czasu, jeżeli miałbym określić osobę dojrzałą w tej chwili na rynku pracy, nawet w momencie, kiedy by ktoś rozglądał się za zmianą swojego miejsca, to bym to podzielił w proporcji 70:30. Myślę, że 30% umiejętności osoby dojrzałej w tej chwili to powinna być przede wszystkim umiejętność definiowania problemów, wytłumaczenia technologii – myślę, że to też jest super ważna rzecz, czyli dla nas pewne rzeczy, skróty myślowe są bardzo zrozumiałe w wewnętrznym środowisku, natomiast w momencie, kiedy idziemy porozmawiać z jakimś inwestorem, klientem czy chociażby project managerem wewnątrz organizacji – super ważne jest to, żeby rozumiał, o czym do niego mówimy i żebyśmy potrafili używać takich słów i sformułowań, i takich porównań do różnych rzeczy, żeby to dla nich też stawało się zrozumiałe. 

Myślę, że to super ważne i bardzo podoba mi się twoje nazwanie tego zestawu umiejętności, bo całkowicie odpowiada moim zdaniem na potrzeby rynku i tego, jak teraz postrzegany powinien być dojrzały programista, który jest super wartością nie tylko dla zespołu, ale też całej organizacji. 

 

Jak przeprowadzam rekrutację, myślę, że podobnie szukam takiego zestawu umiejętności, ale zastanawiam się, może czysto teoretycznie – czy wyobrażasz sobie osobę, która 10 lat pracuje w danej firmie. Zna cały stack technologiczny, produkt, infrastrukturę, wszystko w małym palcu – też mogą się do takiej osoby ustawiać kolejki, bo po prostu ona jest ekspertem i doskonale zna te umiejętności, a mimo wszystko trudno się z nią dogadać i raczej jest to zawsze problematyczne, czyli ten zestaw umiejętności miękkich jest na niskim poziomie. 

Czy dla ciebie taka osoba – ekspert technologiczny z pewnym niedosytem umiejętności miękkich to jest senior developer czy raczej inaczej byś ją określił? 

 

Myślę, że to jest ekspert. Oddzieliłbym wysoko wykwalifikowanego eksperta, natomiast zdarzało się nam też w historii, przy rozmowach rekrutacyjnych wręcz odrzucić osoby, których było szkoda eliminować z procesu rekrutacji, bo mieliśmy świadomość podczas rozmowy, że jego umiejętności techniczne, wiedza czy umiejętności rozwiązywania problemów jest ponadprzeciętna, natomiast brakowało w tym wszystkim uzupełnienia tej osoby o pasujące do naszej, małej, elastycznej organizacji tych wszystkich umiejętności, które my sobie cenimy, czyli dzielenia się wiedzą, pomagania innym, konsultowania swoich rozwiązań. 

Byłbym daleki od tego, żeby nazywać takie superstar developers seniorami, bardziej bym ich traktował na zasadzie ekspertów, którzy są super wartościowi w pewnych rodzajach zespołów, natomiast dla mnie to nie jest osoba senioralna, w moim pojmowaniu tego stanowiska, bo brakuje mu wszystkich miękkich zestawów narzędzi, które są super ważne. 

 

Byłbym daleki od tego, żeby nazywać takie superstar developers seniorami, bardziej bym ich traktował na zasadzie ekspertów, którzy są super wartościowi w pewnych rodzajach zespołów, natomiast dla mnie to nie jest osoba senioralna, w moim pojmowaniu tego stanowiska, bo brakuje mu wszystkich miękkich zestawów narzędzi, które są super ważne. 

 

Powiedziałeś, że w większości przypadków to firma definiuje, że dana osoba jest nazywana czy odbierana jako senior developer. Otoczenie, środowisko firmy. To w związku z tym rodzi się pytanie, czy w ogóle takie stanowisko senior developera jest przenaszalne między firmami?

Widzę, że często jest taka obawa, że okej – może się trochę zasiedziałem w tej firmie, ale jestem senior developerem, jak zmienię tę firmę, to być może okaże się, że te moje umiejętności, moje widzenie swojej osoby nie jest aż tak super i może faktycznie okazać się, że już nie będę tym senior developerem, co często przytrzymuje osoby i powoduje, że one zostają nadal i ten rozwój jest wyhamowywany. 

Czy senior developer jako stanowisko jest przenaszalne między firmami według ciebie? 

 

Wcześniej powiedziałeś o tym, że dla ciebie senior developer to jest osoba dojrzała życiowo. Myślę, że to jest tak, że im bardziej stajemy się dojrzali i więcej wiemy, tym bardziej jesteśmy świadomi tego, ile jeszcze nie wiemy. Bardzo mocno bym to porównał do takiego seniora, który jest w stu procentach świadom swoich kompetencji, ale też jest świadom swoich słabych stron. 

Uważam, że to może być przenaszalne stanowisko w momencie, kiedy podczas rozmowy rekrutacyjnej czy takiego pierwszego kontaktu z daną organizacją jasno zdefiniujemy to, gdzie jesteśmy, co robimy, gdzie widzimy siebie w nowej organizacji. Myślę, że o ile pomiędzy bardzo zbliżonymi organizacjami, technologiami to jest w jakiś sposób przenaszalne, bo zakładam, że bliźniaczych firm czy organizacji ileś tam jest na rynku i istnieje taka możliwość, natomiast z drugiej strony rozumiem to też w ten sposób, że taki senior może w którymś momencie być świadom swoich słabych stron, natomiast może zdecydować się na degradację kosztem zmiany organizacji, technologii. 

To też by mogło tak zadziałać, że w tej nowej organizacji osoba świadomie rekrutująca takiego seniora z innej organizacji będzie miała poczucie, że ta osoba bardzo szybko nadrobi. Myślę, że to jest też rzecz, która wyróżnia taką osobę dojrzałą, że ona mimo świadomości swoich słabości pójdzie i zgodzi się na to, że okej – ale ja będę potrzebował 3 miesiące, pół roku, rok na to, żeby w jakiś sposób nadgonić czy przebranżowić się. I bardzo szybko u was w organizacji wskoczę na ten poziom seniorski, natomiast nie widzę też problemu, żeby osoba o pewnym zespole umiejętności była przeniesiona do innej organizacji o podobnym zestawie umiejętności jako potrzebie i zachowała swoje stanowisko. 

Też w historii rozmów spotkałem się z tym że osoby, które osiągnęły pewien poziom eksperckości w danej technologii chciały ją zmienić, były skłonne do pewnych wyrzeczeń, do tego, żeby zacisnąć zęby i przez jakiś czas zgodzić się na pewnego rodzaju degradację tylko po to, żeby odnaleźć się w nowej organizacji, bardzo szybko się wybić, przebić i działać sobie dalej. 

Myślę, że te osoby dużo szybciej progresują w czasie i to jest trochę ich precyzja, świadomość, na co się decydują. Ale tutaj fajnie organizacje, jakby organizacje, do których przechodzą, jawnie definiowały to, czego oczekują, a taka osoba potrafiła nazwać swoje potrzeby, wprost o nich mówiła. 

 

Tak jest, dokładnie! To jest prostszy wariant i jeśli jesteśmy PHP i przechodzimy na stanowisko, które również wiąże się z tą technologią. Wówczas można powiedzieć, że w miarę szybko jesteśmy w stanie wrócić do pełnego działania, jako senior developer, czyli odnaleźć się w organizacji nie tylko w obszarach technicznych. 

Czasem się zdarza, że chcemy wykonać jakąś zmianę w naszej karierze, być może nauczyć się nowego języka, być może lekko się przebranżowić. 

W takiej sytuacji trzeba nabyć nową technologię, musimy nabyć doświadczenia z nią związanego i tutaj zmiana już może być nieco trudniejsza, przynajmniej w oczach takiego senior developera, ponieważ może się okazać, że ta degradacja następuje – chociażby finansowa, bo rozpoczynając swoją przygodę z nową technologią, nowym językiem programowania wpadamy w te widełki junior/mid developer, więc teoretycznie to wynagrodzenie może być niższe. 

Co byś tutaj doradził? Jakie masz obserwacje z takiego obszaru, zakresu zmian, kiedy ludzie zmieniają faktycznie ten język, przechodzą być może do innej firmy, w końcu decydują się na tę zmianę, ale muszą się liczyć z jakąś degradacją?

 

Trafnie to nazwałeś – junior/mid. Spotkałem się kiedyś z bardzo trafnie zdefiniowanym pojęciem, który taką osobę nazwał „overpaid junior”. Czyli masz seniora, który osiągnął jakiś poziom eksperckości w analizie danych albo machine learningu i nagle on chce się w jakiś sposób „przebranżowić”. Z jednej strony jego umiejętności trzeba doceniać, bo jest to osoba, która 10-12 lat zajmowała się złożonymi algorytmami operowania danych i tak dalej, natomiast z drugiej strony ta osoba powinna być świadoma, że to jest trudne dla organizacji, ponieważ nie każda może sobie pozwolić na to, żeby przyjąć osobę o bardzo wysokich kwalifikacjach, zapewnić mu widełki seniorskie, które miał wcześniej, jednocześnie godząc się na to, że musi poświęcić ileś tam swojego czasu, swoich nakładów – nie chodzi tutaj tylko i wyłącznie o kwestie wynagrodzenia danej osoby, ale zakładam, że w zespole ileś osób będzie musiało poświęcić ileś swojego czasu po to, żeby ta osoba nabyła tych umiejętności czy stała się znowu wprawna. 

Natomiast – to jest temat rzeka, o którym każda organizacja będzie umieć inaczej powiedzieć. Myślę, że ważne jest tutaj to, żeby z jednej strony jasno zdefiniować, być świadomym swoich słabości i wiedzieć, na co się decydujemy, czyli zgodzić się na to, że cofam się trochę w swojej karierze, godzę się na niższe wynagrodzenie, co w naszej bańce IT i tak nie będzie jakąś straszną głodówką, natomiast te osoby też są w stanie bardzo szybko nabyć umiejętności w nowych technologiach, jeżeli tylko organizacja w jakiś sposób będzie miała potrzebę i będzie w stanie wesprzeć taką osobę, to myślę, że to jest wykonalne. 

Przy czym znowu, wracając wcześniej, ta osoba po prostu musi mieć tę świadomość, że w jakiś sposób decyduje się na zmianę w swoim życiu i ta zmiana może być bolesna dla portfela, ale z drugiej strony jak ktoś bardzo chce i ma dużą potrzebę, czuje, że to jest frajda i odświeżenie swojego miejsca pracy, to z mojej perspektywy po prostu warto. 

Myślę, że gdybym miał obecnie zmieniać pracę, gdzie przez ostatnie 4-5 lat już aktywnie nie programowałem, zostałem przesunięty do zadań menedżerskich, no to byłbym świadom, że idę na to stanowisko juniorskie. Myślę, że potrzebowałbym roku, dwóch na to, żeby znów się wdrożyć w język, natomiast z pewnością wniósłbym umiejętności miękkie, które z latami zostały rozbudowane, a jednocześnie jestem w stanie szybko nadrobić technologie, ale byłbym świadom tego, że wiąże się to z degradacją. Byłbym najmłodszym, najgłupszym w zespole, ale z perspektywy czasu zakładam, że warto, jeżeli przyniosłoby mi to w jakiś sposób szczęście. 

 

Pewnie! Myślę, że to jest bardzo zdrowe podejście do tej sytuacji. 

Jak rozmawialiśmy przed nagrywaniem – dużo pracuję ze startupami i tam to określenie, przedimek senior przed stanowiskiem pracy zazwyczaj ma małe znaczenie dla osób, które ze startupami pracują, bo o niczym to ani nie świadczy, ani nie daje to jakichś specjalnych benefitów. 

Jak obserwuję korporacje, to tam to może być istotna oznaka tego, na jakim szczeblu kariery jesteśmy, na jakiej pozycji, jaki status w danej firmie posiadamy. 

Jak ty do tego podchodzisz? Jak Bitnoise do tego podchodzi? Jestem ciekaw!

 

Jesteśmy małą organizacją, jest nas trzydzieści-parę osób i ciężko tutaj mówić o jasnych ścieżkach kariery, o zdefiniowanych poziomach doświadczenia. Jesteśmy po prostu grupą fajnych ludzi, którzy pracują i robią to już od lat – i mamy osoby, które są z nami po 8, 9 lat w organizacji. Myślę, że to o czymś też świadczy. Ich doświadczenie wynika z lat spędzonych z nami. 

U nas jest to totalnie nienazwane stanowisko. Myślę, że to jest bardzo zbliżone do tego, o czym ty wspomniałeś. Jeżeli pracujesz ze startupami, to ludzie skupiają się na tym, żeby dowozić rzeczy, robić to możliwie szybko, najlepszej jakości, dbając o technologie, ale jednocześnie czuję też, że – jak większość startupów w jakiś sposób mierzą się z ryzykiem i muszą dowozić rzeczy. 

Tam nie ma czasu na to, żeby robić cotygodniowe ewaluacje i sprawdzać, czy checklista się zgadza, czy ktoś przeskoczył na poziom wyżej czy niżej. Natomiast w dużych organizacjach traci się to indywidualne podejście do człowieka, przez co on w jakiś sposób musi być opisany profilem i zadbać trzeba o nich w trochę inny sposób. Zakładam, że to nie jest kwestia tego, w jaki sposób dana organizacja to definiuje, myślę, że to jest bardziej kwestia tego, ile osób w danej organizacji pracuje, jak się podchodzi do tego typu sytuacji. 

Ona została nienazwana i myślę, że najłatwiej ją poznać po tym, że do kogoś ustawia się kolejka ludzi z pytaniami i to są najczęściej takie osoby, które są nieformalnym liderem w danym zespole, wyróżniają się pewnie poza typowo technicznymi umiejętnościami, umiejętnością porozmawiania z biznesem, project managerem czy klientem, także ja bym powiedział, że te osoby same się rodzą w zespołach i przebijają z czasem. 

Natomiast sami nie mamy formalnego podziału na junior i senior. Myślę jednak, że gdyby zapytać o to kogokolwiek z naszego zespołu, to nie byłoby problemu, żeby wymienić takie osoby i nazwać ich konkretnie po imieniu. 

 

Właśnie -takie stanowiska, osoby rodzą się same, a nie są z nadania. 

 

Tak. 

 

Myślę, że to jest dużo lepsze podejście. 

 

Zakładam, że jest super trudne, jeżeli masz organizacje po prostu trzystu osób, natomiast myślę, że w mniejszych zespołach do 100 osób spokojnie można bardziej indywidualnie do takich rzeczy podchodzić. 

 

Okej. Na początku zgodziliśmy się, że definiowanie tych licznych stanowisk stosując tylko lata doświadczenia, lata pracy to nie jest zbyt dobry sposób, ale jakoś trzeba to uwzględnić w ofertach pracy. Jednak firmy zazwyczaj umieszczają, że chodzi im o mid developera, o senior, juniora. 

Widzimy tam takie wyszczególnione lata doświadczenia w szeregu technologii. Zastanawiam się, jak według ciebie do tego podejść – czy może znasz jakąś alternatywę, może jakieś porady jak dobrze skonstruować tego typu oferty pracy, żeby przyciągać z jednej strony odpowiednie osoby, a z drugiej strony, żeby to nie było pisane językiem zbyt korporacyjnym, gdzie niewiele chcemy przekazać, niewiele tego wynika? 

 

Myślę, że dobrą radą byłoby zachowanie złotego środka. Czyli z jednej strony mamy tę pewną checklistę niezbędnych rzeczy – ciężko mi sobie wyobrazić, żeby ktoś nabywał umiejętności seniorskich czy żeby zatrudniał kogoś na stanowisko lidera, eksperckie kto ma 2-3 lata doświadczenia. Myślę, że te są pierwszym docięciem. I wiesz co – biorąc pod uwagę fakt, że średnio jesteśmy aktywni zawodowo 40 lat, to jeżeli byśmy odcinali seniora po 5-6 latach – no i co dalej? Tutaj rodzą się kolejne pytania. 

Myślę, że z mojej perspektywy te lata doświadczenia są pewnie pierwszym odcięciem, bo często oczekiwać od rozmowy z kimś, kto ma 2-3 lata doświadczenia tego, że potrafi się płynnie poruszać po technologiach i mierzy jakieś szerokie spektrum, może być pewnie jakimś tam doświadczonym developerem, w bardzo wąskim aspekcie technologii, w której aktualnie pracuje lub też pracował, także myślę, że to jest ważne i wartościowe, bo to z jednej strony nie marnuje czasu w organizacji czy też osób, które rozmawiają z potencjalnymi kandydatami, z drugiej strony jest to szanowanie czasu programisty. 

Nie widzę tutaj za bardzo sensu do tego, żeby nie szanować czyjegoś czasu. Zapraszać go na rozmowę i jednocześnie potem na tej rozmowie upewniać się, że on de facto nie ma takiego doświadczenia, jakiego oczekiwaliśmy, więc tak. Natomiast myślę, że my też nie odkrywamy biznes Ameryki i podchodzimy do rekrutacji bardzo indywidualnie. 

Podczas takiej rozmowy przechodzimy trochę organoleptycznie przez to, co ta osoba robiła, w jakich technologiach się poruszała. Rozmowa ma luźniejszą formę, mniej lub bardziej dotykamy pytań technicznych. I to daje pogląd na to, gdzie ta osoba była, z kim pracowała, w jakim zespole, jaką pełniła rolę w zespole i myślę, że to jest też wartościowa informacja do takich osób, które szukają pracy, że w momencie, kiedy czują, że po drugiej stronie mają partnera do rozmowy, a nie osobę, która sprawdza checklistę, to komfort takiej rozmowy jest dużo większy. 

Jako osoba rekrutująca, sam powiedziałeś, że pomagasz w startupach, rekrutujesz, rozmawiasz z ludźmi, pewnie też masz takie poczucie, że są takie rozmowy, podczas których pytanie o sortowanie elementów tablicy byłoby faux-pas, bo jeśli ktoś pracuje 15-20 lat na rynku, zrobił pewne rzeczy, to trochę nie wypada.

 

Gruby policzek, tak! 

 

Dokładnie. Myślę, że nie zostałoby to dobrze odebrane, z drugiej strony tobie nie daje to żadnej informacji. To nie jest ważne. Staram się prowadzić rozmowy w ten sposób, że jest zupełnie luźną formą rozmowy o technologiach i czując, że ta osoba ma mniejsze doświadczenie w pewnych aspektach – naciskam na pytania techniczne w danym obszarze i patrzę, co tam się dzieje. Jeżeli widzę, że ta osoba się zaczyna bardzo mocno stresować, wycofuję się z tego. Układam w głowie obraz, że okej, tutaj go jeszcze nie było i to też jest czasami okej, bo to nie jest tak, że każdy musi być alfą i omegą. 

Natomiast z drugiej strony uważam, że też jest taki poziom doświadczenia, w którym te rozmowy już na poziomie bardzo, bardzo technicznym po prostu nie są na miejscu, bo te osoby nie będą rozwiązywały quizów i nie tego się od nich w tym momencie oczekuje. 

To bardzo dobrze można wyczuć w takiej rozmowie 1:1, zupełnie szczerej i otwartej, i myślę, że to daje dużo więcej niż jakakolwiek checklista, którą byśmy sobie odhaczali. 

 

Mam do tego identyczne podejście, przeprowadzam to dokładnie w taki sposób. Myślę, że to jest taki komfort mniejszych organizacji, bo jeśli mówimy o dużo większych to musimy mieć checklisty, mieć możliwość zaraportowania, porównania wielu osób i wtedy trzeba mieć jakieś dane, żeby je porównać, musimy mieć jakiś powtarzalny proces. 

 

Absolutnie się zgadzam, bo to jest trochę to, o czym wcześniej rozmawialiśmy – to, że do któregoś poziomu, tam, gdzie takie osoby, które są długo w organizacji, dobierają tych ludzi przez pryzmat bardziej kulturowego dopasowania do organizacji, pomysłu, no to tak może działać. Uważam, że to jest super fajne, natomiast nie da się takiego podejścia wyskalować na większą organizację. To może być trudne albo wręcz niemożliwe i też się absolutnie z tobą zgadzam. 

Natomiast z mojej perspektywy te rozmowy pewnie zajmują więcej niż powinny, ale dają też fajny obraz i obiekt w głowie, który potrafisz gdzieś dopasować i często mi się zdarzało przeprowadzać takie rozmowy, które poszły w zupełnie absurdalnym kierunku, ale były super wartościowe i tak się zdarza czasami! Myślę, że warto rozmawiać, a checklisty pewnie od któregoś poziomu są ważne, natomiast ja bym traktował je jako uzupełnienie, wyraportowanie, natomiast nie jako najważniejszą rzecz przy rekrutacjach. 

 

Myślę, że nieco schodzimy z głównego tematu, ale to też arcyciekawe. 

Myślę, że to jest też fajna okazja do tego, żeby budować markę pracodawcy, bo nigdy nie wiadomo, czy taka osoba za jakiś czas nie wróci z innym zestawem swoich doświadczeń i nie okaże się, że jednak będzie u nas pracownikiem. 

Natomiast doświadczenia, których miała okazję doznać podczas tej rozmowy zostaną i to jest coś takiego, jest trudne do zbudowania marketingowym przekazem w social mediach. Nie da się bardzo łatwo oddać atmosfery panującej w firmie, natomiast podczas takiej rozmowy, kiedy jesteśmy w 4 oczy, może dwa ekrany, dużo prościej jest przekazać ten vibe, atmosferę panującą w firmie i nigdy nie wiadomo, w którym kierunku to się potoczy, jak powiedziałeś. 

 

Myślę, że w ogóle jest tak, że nie warto palić żadnych mostów i te rozmowy, nawet jeżeli się nie dogadasz, to masz świadomość tego, że pójdzie gdzie dalej, rozwinie się. Mieliśmy też takie sytuacje – z racji tego, że jesteśmy już ileś lat na rynku, osoby, z którymi w międzyczasie albo współpracowaliśmy, albo do tej współpracy nie doszło, ale dobrze wspominały rozmowę z nami czy spotkania, bo to też nie jest tak, że to proces, jeden dzień, jesteśmy razem w zespole. 

Te osoby szły gdzieś dalej, nabierały pewnych kompetencji, zmieniały swoją karierę, bo tak też się nam zdarzało, a potem wracają do ciebie jako klient, nie? To jest zupełnie naturalne, bo te osoby ciebie wspominają miło. Jestem w ogóle zwolennikiem tego, żeby rozmawiać, rozmawiać w sposób kulturalny, uczciwy, szczery, a z czasem to po prostu procentuje i nigdy nie wiadomo, jak się nasze życie dalej potoczy, a warto dbać o kontakty! 

 

Otóż to! Chciałbym teraz przejść na temat rozwoju, oczywiście szumne słowo, ale chciałbym to ugryźć w tym kierunku. Dla juniora rozwój jest niezwykle ważny i szybki rozwój, żeby jak najszybciej nabierać tych kompetencji, jak najszybciej uczyć się nie tylko umiejętności technicznych, ale też, żeby odnaleźć się w projekcie, w zespole. 

Jak to jest według ciebie z seniorem? Czy on też powinien poznawać nowe technologie, czy też może pogłębiać swoją specjalizację w tych kilku dziedzinach, w których jest ekspertem?

 

Myślę, że odpowiedź może być krótsza. Myślę, że nasz zawód – czy w ogóle zawód osoby pracującej w IT jest bardzo zbliżony do zawodu lekarza czy prawnika. To jest zawód, który wymaga ciągłej nauki. W momencie, w którym się zamkniesz i przestaniesz uczyć to wiemy dobrze, jak łatwo wypaść z tego rynku, technologii. Czy to jest dobre czy złe, to myślę, że to jest temat na zupełnie inny podcast, bo też nie jestem zwolennikiem tego, żebyśmy co miesiąc czy co trzy zmieniali frameworki, języki technologie, bo gdyby każdy lekarz zmieniał swoje narzędzia co trzy miesiące to nie wiem, czy chciałbym mu się oddać na operację. 

 

Myślę, że nasz zawód – czy w ogóle zawód osoby pracującej w IT jest bardzo zbliżony do zawodu lekarza czy prawnika. To jest zawód, który wymaga ciągłej nauki. W momencie, w którym się zamkniesz i przestaniesz uczyć to wiemy dobrze, jak łatwo wypaść z tego rynku, technologii. 

 

Myślę, że to zupełnie inny temat. Także ja bym powiedział, że to jest ciągła nauka, to raz – a dwa, że super ważna jest ta specjalizacja, bo nawet jeżeli jesteś osobą w zespole, która jest zatrudniona czy rozwija się jako taki mid, regular, to to, że ona się specjalizuje w jakimś konkretnym obszarze otwiera mu furtkę i to jest ten moment, w którym taka osoba stanie się ekspertem w bardzo wąskiej dziedzinie, nabywa możliwości do tego, żeby spojrzeć na pewne tematy szerzej. 

Czyli pierwsza rozmowa z potencjalnym klientem, pierwsza sesja, na której musi zrobić demo, musi opowiedzieć o jakichś aspektach, także ja bym powiedział, że taka specjalizacja powoduje, że nabierasz możliwości, czy z nich skorzystasz czy nie, to jest bardziej kwestia twojego charakteru i podejścia do komunikacji. Natomiast to na pewno otwiera pewne drzwi, pozwala rozwinąć się szerzej i podejść bardziej otwarcie do elementów planowania, biznesu, ryzyka. Jesteś wciągany w coraz większe decyzje i to jest super wartościowe! 

 

W tej dzisiejszej rozmowie zgodziliśmy się już ze sobą w wielu różnych kwestiach, jedną z nich było to, że najczęściej senior to jest osoba po ok. 5 latach doświadczenia, myślę, że w branży coś takiego istnieje. 

Pytanie: co dalej? 5 lat to jest niewiele porównując do potencjału 40, 45 lat, jakie przed sobą mamy. 5 lat to jest właściwie ułamek. 

Zderzamy się trochę z takim szklanym sufitem. W korporacjach próbuje się jakoś temu przeciwdziałać, tworząc takie stanowiska jeszcze wyższe, ocierające się może trochę o biznes, klientów, typu principal developer czy architekt, ale generalnie, właśnie. Chciałem cię zapytać o to, jak żyć, jak wyznaczać sobie cele i do czego dążyć, jak już jesteśmy tym seniorem?

 

Myślę, że dobrze, że wspomniałeś po raz kolejny o tym czterdziestoletnim przedziale naszej aktywności zawodowej, bo myślę, że w tej perspektywie to 5 lat brzmi dosyć zabawnie. Bo jeśli według rynku po 5 latach nabywamy umiejętności seniorskich, to pytanie: co dalej? Także dla mnie to pięcioletnie doświadczenie absolutnie nie oznacza seniora. 

Uważam, że to jest trochę wymuszone przez rynek, bo żyjemy na rynku w IT, na rynku pracownika, to to wymusza. Często jest też tak, że jeżeli organizacja nie ma innego pomysłu na to, żeby w jakiś sposób gratyfikować ludzi, to daje im tę łatkę seniora. 

Natomiast myślę, że już jesteśmy zgodni z tym że to pięcioletnie jest bardzo optymistyczne i jest zupełnie inaczej. Wydaje mi się, że ta nasza branża wbrew pozorom jest bardzo trudna. Ona trochę ocieka tym dobrobytem z punktu widzenia takiego juniora. Mamy rynek pracownika, co w jakiś sposób wpływ na to, jak definiowane są ścieżki rozwoju w organizacjach. 

Natomiast wydaje mi się, że z jednej strony mamy bananowe czwartki, tę całą otoczkę startupową, natomiast z drugiej strony bardzo mało mówi się o wypaleniu zawodowym, stresie, rzeczach, z którymi tak naprawdę osoby, które nabywają pewnych kompetencji miękkich, o których już rozmawialiśmy, zaczynają ich doświadczać, bo z decyzyjnością wiąże się stres. Z jakimiś decyzjami wiążą się konsekwencje tych decyzji – tutaj myślę, że wbrew pozorom to jest bardzo trudna branża i ciężko tutaj jest – albo jeszcze nie dotarliśmy do momentu, w którym mamy lawinę wypalenia zawodowego, z którym w jakiś sposób organizacje będą musiały się zmierzyć. 

I to już nie ma znaczenia, czy to będą małe czy duże organizacje – po prostu każdego to dotknie prędzej czy później, bo wiemy też jak trudną pracą jest praca dzień w dzień z komputerami, one są często nieprzewidywalne, nasze decyzje są często nieprzewidywalne i obojętnie, ile byśmy nie mieli lat doświadczenia, to zawsze może coś pójść nie tak. 

Tutaj ta odporność na stres, dbanie o szeroko pojęty work life balance będzie też super ważny. Na pewno też presja czasu, to są takie naciski, które dotykają developerów. 

Nie widzę tutaj jakiejś złotej rady na to, żeby powiedzieć co dalej z takim seniorem. Ale wydaje mi się, że z perspektywy lat myślę, że jeszcze z 10 lat temu była taka wprost ścieżka, która mówiła o tym, że jeżeli osiągasz pewien poziom doświadczenia jako developer, to oczekuje się od ciebie tego, że pójdziesz w kierunku managerskim. I myślę, że to na szczęście zostało zrewidowane w ostatnich latach i teraz jest często tak, że taka osoba nabywa pewnego rodzaju umiejętności technicznych i w nich zostaje, jest ekspertem, który ma 40-50+ lat za jakiś czas, natomiast ona sobie została w tych technologiach, nie ma w tym nic złego, tej osobie jest dobrze, organizacji jest dobrze, jest super wsparciem dla młodszych kolegów, ale sobie został w tym obszarze technicznym. Natomiast na pewno jest też tak, że jeżeli trafiasz do organizacji, która cię wspiera w rozwoju i dochodzisz do tego stanowiska seniorskiego, to otwiera ci się wiele furtek. 

Możesz albo iść w kierunku architekta albo stanowiska dyrektorskiego, możesz iść bardziej w kierunku project managerskim, możesz iść bardziej w kierunku CTO, bo też nic nie stoi na przeszkodzie, żeby iść do startupu czy do mniejszej organizacji, czy też nawet do dużej się przesunąć, ale uważam, że nie ma złotego środka. Na pewno wartościowe jest to, żeby mieć możliwość zmiany projektu czy zmiany zespołu w obrębie organizacji. To jest coś, co pozwala nam czasami utrzymać ludzi po 8-9 lat w naszej organizacji, ale jakby też każda osoba jest inna i widzę tutaj z latami doświadczeń w IT bardzo szerokie możliwości do tego, żeby nie tylko zmienić sobie technologię, projekt, organizację, ale wręcz zmienić ścieżkę i to otwiera wiele drzwi. 

Im więcej mamy możliwości, a nabieramy ich przez specjalizację, tym szerzej możemy z czasem myśleć i albo sobie zostać w tym swoim świecie technologii, nie ma w tym nic złego i robimy nadal to, co lubimy, jesteśmy ekspertem i nadal się rozwijamy, albo zmieniamy sobie obszar na bardziej miękki, jeżeli nam to odpowiada i rozwijamy się w innych kierunkach, natomiast jest to bardzo indywidualne. 

 

Zacząłeś mówić o tym, że branie większej odpowiedzialności na siebie czy też angażowanie się w inne projekty to może być ucieczka przed nudą, wypaleniem, może jakiś sposób na znalezienie swojej drogi w tej organizacji, wcale niekoniecznie musimy z niej uciekać. 

Czym jeszcze oprócz technologii może się zajmować senior developer, żeby w jakiś sposób się nie wypalić, nie znudzić i ciągle być czynnym w takiej organizacji?

 

Widzę kilka takich obszarów, które u nas się przynajmniej sprawdzają i widzę, że to jest świetna odskocznia dla osób, które generalnie są bardzo doświadczone w technologii. Na pewno jest to dzielenie się wiedzą, jest to jakaś forma edukacji, wspierania młodszych kolegów, młodszych stażem albo bycie ekspertem, wyrocznią, do której ludzie przychodzą z pytaniami. 

 

Widzę kilka takich obszarów, które u nas się przynajmniej sprawdzają i widzę, że to jest świetna odskocznia dla osób, które generalnie są bardzo doświadczone w technologii. Na pewno jest to dzielenie się wiedzą, jest to jakaś forma edukacji, wspierania młodszych kolegów, młodszych stażem albo bycie ekspertem, wyrocznią, do której ludzie przychodzą z pytaniami. 

 

Myślę, że to na pewno jest bardzo ciekawy aspekt, bo z jednej strony pozwala wykazać się i podzielić swoją wiedzą, z drugiej pozwala mieć kontakt z ludźmi, którego potrzebujemy i to nie jest tak, że cały dzień siedząc przy komputerze może być super produktywny, więc warto sobie odskoczyć głową na moment, z kimś porozmawiać, to jeśli jeżeli możemy się podzielić wiedzą, to tym bardziej. 

Na pewno taka osoba ma możliwość, żeby rozmawiać z klientem, biznesem, bo to są też bardzo wartościowe rzeczy. One są mało komfortowe pewnie na początku, bo gdzieś tam wymagają wyjścia z pewnej strefy komfortu, natomiast dają spojrzeć na rzeczy z innej perspektywy i to jest na pewno super ważne. Myślę, że trochę wracając do tych mniejszych organizacji, takich jak powiedziałeś, z którymi ty pracujesz, czyli w takich startupach, mniejszych firmach – na pewno daje to możliwości posiadanie pewnego wpływu na to, jak ta organizacja kształtuje się w czasie. Czyli nasz realny wpływ – wiadomo, ze founderzy darzą cię też dużym zaufaniem, jeżeli jesteś takim seniorem, dają ci możliwość decydowania, wierzą w ciebie i to sprawia, że jeżeli ty przyjdziesz do nich jako doświadczony człowiek i powiesz, że to ci się nie podoba, to bym zrobił lepiej, to bym zrobił inaczej, no to osoby decyzyjne w organizacji będą się liczyły z twoim zdaniem. 

Taki realny wpływ na nasze środowisko pracy myślę, że jest świetny, bo to pozwala ludziom nie tylko skupiać się na rozwoju technicznym, ale też pozwala im wpływać na miejsce pracy, a wiemy, że tyle życia tam spędzamy, że to jest bardzo ważne. 

 

Tak jest! A jak to wygląda z perspektywy pracodawcy? Też obserwuję takie dążenie, że wszyscy chcieliby mieć samych senior developerów w zespołach, bo teoretycznie wtedy taki zespół jest bardzo efektywny, szybki, tam jest dużo kompetencji, wszystko powinno się udać. Tymczasem niekoniecznie. Jestem ciekawy, jak ty to widzisz, czy uważasz, że to jest dobry pomysł?

 

Myślę, że najgorszy i tu się chyba tez zgodzimy.  Znowu myślę, że to jest takie życiowe – dobry zespół jest zbalansowany i potrzebuje kompetencji na całym spektrum, czyli potrzebujemy doświadczonych osób, które jak trzeba dowieźć, dowiozą, które poświęcą pewne rzeczy, ale są w stanie to zrobić na czas i zadbać o to, aby to było odpowiedniej jakości. 

Z drugiej strony gdybyśmy mieli samych seniorów to zakładam, że byśmy z innowacją byli 5-6 lat do tyłu, bo ta iskra młodzieńczej, ułańskiej fantazji jest też niezbędna w zespole i myślę, że wypadkową takiego świata są po prostu zwinne i sprawne zespoły. Ciężko mi sobie wyobrazić takich sześciu, siedmiu leśnych ludków, którzy siedzą po 15-16 lat w tym samym i nadal robią to samo, bo ten świat zmienia się strasznie szybko. 

Myślę, że taka dywersyfikacja w zespole, jeżeli chodzi o poziom doświadczenia jest super ważna dlatego, żeby taki zespół był sprawny i to jest też uzupełnienie twojego poprzedniego pytania o to, w jaki sposób seniorzy mogą czuć się spełnieni, bo nie samym dowożeniem na czas ludzie żyją. Nie samą jakością kodu czy też pokrywaniem wszystkiego testami. Myślę, że ten element edukacyjny jest ważny i z jednej strony taka osoba, która jest w zespole i ktoś od niego może się uczyć, to jest super ważne i na pewno doceni taką możliwość. 

 

Myślę, że taka dywersyfikacja w zespole, jeżeli chodzi o poziom doświadczenia jest super ważna dlatego, żeby taki zespół był sprawny i to jest też uzupełnienie twojego poprzedniego pytania o to, w jaki sposób seniorzy mogą czuć się spełnieni, bo nie samym dowożeniem na czas ludzie żyją. 

 

Z drugiej strony osoba, która może się dzielić wiedzą też czuje się doceniona i spełniona. Nie trzyma tej wiedzy tylko dla siebie. Myślę, że to ma i pozytywny wpływ na to, jak takie zespoły funkcjonują w biznesowym znaczeniu, ale ma też bardzo pozytywny wpływ na to, jak wewnątrz organizacji takie zespoły czy też ma to bezpośredni wpływ na zadowolenie osób, które są wewnątrz takiego zespołu. 

Myślę, że to jest trudne, w jaki sposób to zbalansować, bo z jednej strony mamy tę stabilność, na której nam zależy, szybkość, prędkość, ale z drugiej strony taka iskra świeżości też jest w każdym zespole potrzebna i myślę, że po prostu balans jest ważny.  

 

Okej, to na koniec chcę cię zapytać o dobre praktyki z Bitnoise w temacie właśnie senior developerów. Czy takie osoby są u was mocno samodzielne, czy może uzyskują cały czas wsparcie? Jak tutaj z nimi współdziałacie, jak ich wspieracie, pracujecie na co dzień? 

 

Myślę, że trochę wrócimy pewnie do moich wcześniejszych odpowiedzi, bo gdzieś tam jakiś obraz pewnie się już wyłonił. Natomiast z racji tego, że jesteśmy niewielką organizacją, to jest tak, że te osoby są po prostu samodzielne. Od początku tak było, mają ogromny kredyt zaufania, którego się nie da nabyć z rynku. 

To jest kredyt zaufania, który się wypracowuje wewnątrz organizacji. Czyli jeżeli pracujesz z kimś 5, 6, 8 lat, to jesteś w stanie przewidzieć, jakie są potrzeby tej osoby, jakie są jej mocne lub słabe strony i mają stuprocentowe wsparcie z naszej strony. Polegamy na tych osobach, w 9 na 10 przypadków absolutnie podejmują takie same decyzje, jakie byśmy sami podejmowali i myślę, że ten kredyt zaufania jest ogromny. 

Z drugiej strony jesteśmy też świadomi – z racji tego, że znamy się, jesteśmy zespołem osób, które gdzieś funkcjonują dzień w dzień przez lata, widzimy czasami, jakie są potrzeby tych osób, widzimy, w jaki sposób możemy ich wesprzeć, o czym możemy porozmawiać. Jest też tak, że rozmawiamy o rzeczach poziom wyżej niż technologia i myślę, że staramy się wspierać nie tylko w rozwoju, ale też czasami staramy się ich wspierać w tym, żeby zmienili projekt, zmienili zespół, odetchnęli. Często zdarzało się nam wypychać osoby na jakieś przymusowe wolne, bo czuliśmy, że stres czy wypalenie nadchodzi. 

Znamy z czasem te mocne i słabe strony i myślę, że znowu to jest tak jak wspomniałeś o startupach – takie podejście bardziej do zespołów na takiej zasadzie, że jeszcze przy tej skali jesteśmy w stanie się znać i wszyscy dobrze wiemy, jakie te decyzje podejmować. 

Mamy grupę ekspertów, staramy się ich wspierać, oni wspierają nas i tak naprawdę z latami dostawali coraz większe kompetencje i w tej chwili jest tak, że część zespołów mamy absolutnie samoorganizujące się i nawet niespecjalnie wtrącamy się w ich decyzje, bo te decyzje po prostu są trafne. I dla mnie te osoby, które gdzieś tam historycznie czy zawodowo związane z programowaniem, to była najtrudniejsza decyzja, najtrudniejszy przeskok, żeby przestać się wtrącać w taki micro management i przestać doglądać i upewniać się, że na pewno decyzje zespołu są trafne, bo okazało się, że często są dużo lepsze i nie ma tutaj żadnych powodów do tego, żeby wtrącać się i decydować za ludzi, którzy pracują ze zdalnym projektem na co dzień, mają 5 lat doświadczeń, znamy ich, wiemy, że jeżeli nawet popełnią jakiś błąd, to nie zrobią go celowo. 

Myślę, że to też jest ważne – żeby wspierać takie pomyłki, a z drugiej strony ważne jest to, żeby ta osoba potrafiła podjąć decyzję, trafną na dany moment i na daną wiedzę, czyli nie jesteśmy w stanie przewidzieć wszystkiego do przodu, natomiast z mojej perspektywy jest tak, że ludzie, którzy osiągają pewien poziom doświadczenia w programowaniu podejmują takie decyzje, które są zgodne z danym momentem w czasie, jeżeli chodzi o stan ich wiedzy i podejmą tę decyzję trafnie. 

Ciężko mi sobie wyobrazić, żeby ktoś działał na szkodę jakiejkolwiek organizacji, projektu czy zespołu. To jest totalnie nienaturalne i to wszystko staramy się wspierać, nam też pozwoliło zbudować zespół, który w skali przekrojowej jest o tyle ciekawą organizacją, że mamy ludzi, którzy są z nami po 6-8 lat i nie doprowadziliśmy do momentu, w którym moglibyśmy ich w jakikolwiek sposób zmusić do tego, że kończą się opcje u nas i trzeba szukać tej zmiany, o której wcześniej rozmawialiśmy w innej organizacji. 

 

Świetnie! Łukasz – dzięki wielkie za ciekawą i mam wrażenie, partnerską rozmowę – utożsamiałem się z wieloma rzeczami, o których mówiłeś. Dzięki za poświęcony czas! 

Powiedz proszę, gdzie cię można znaleźć w internecie, jak się z tobą skontaktować?

 

Myślę, że z perspektywy osoby związanej bardziej z biznesem, oczywistym wyborem jest LinkedIn, także zapraszam do porozmawiania, zawsze chętnie odpowiem, nawet jeżeli będzie to z opóźnieniem, to myślę, że to jest dla mnie platforma pierwszego wyboru, jeśli chodzi o kontakt czy porozmawianie, opowiedzenie, podzielenie się doświadczeniem i wiedzą. 

Zawsze chętnie, więc zapraszam do kontaktu! 

 

Świetnie! Oczywiście wszystkie linki będą w notatce do odcinka. Jeszcze raz ci Łukaszu dziękuję. Do usłyszenia, cześć!

 

Dziękuję, Krzysztofie! Cześć, do usłyszenia! 

 

To na tyle z tego, co przygotowałem dla ciebie na dzisiaj. Rola senior developera jest niezwykle istotna w organizacjach i wykracza poza umiejętności techniczne. Cieszę się, że miałem okazję porozmawiać o tym z kimś doświadczonym i usłyszeć, jak podchodzi się do senior developerów w Bitnoise.

Jeśli ten odcinek był dla ciebie interesujący i przydatny, odwdzięcz się proszę recenzją, oceną lub komentarzem w social mediach. 

Jeśli masz jakieś pytania, zawsze możesz śmiało pisać na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych.

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o tym, kim jest senior developer.

Do usłyszenia w kolejnym odcinku już za tydzień! 

Cześć!