Kiedyś uważałem, że częsta zmiana pracy jest dobra. Zmieniłem zdanie

Artur Ptaszek, Team Leader w Synergy Codes, miał okazję pracować w różnych firmach, z wieloma technologiami. – Było to wartościowe doświadczenie, ale w żadnej chwili nie czułem, że jest to “ostateczne” miejsce pracy. Zawsze miałem potrzebę większej swobody, środowiska motywującego do rozwoju i pracy w firmie, która jest inkubatorem developera – powiedział w rozmowie z nami. Dlaczego zmienił zdanie? Dlaczego dziś uważa, że więcej korzyści osiąga, pracując cztery lata w jednym projekcie? Tego dowiecie się z naszej rozmowy z Arturem.

Od lat w społeczności IT powraca wątek pracy w jednej firmie i pracy w różnych firmach. Ty jesteś zwolennikiem tego pierwszego rozwiązania – dlaczego?

Społeczność szumnie dywaguje nad jednym lub drugim, ale wydaje mi się, że jest to kwestia osobistej preferencji. Uważam, że dla ludzi nastawionych na rozwój bycie w jednej firmie jest rozwojowe tak długo, jak długo projekty, w których się znajdujemy, pchają nas do przodu, a potencjał firmy pozwala na rozwój. Dlaczego preferuję to pierwsze? Lubię mieć kontrolę nad własnym rozwojem, podążać ścieżkami wyznaczonymi przez siebie. Zmieniając firmę, nigdy nie wiem co zastanę, jak firma podchodzi do rozwoju ani czy współpracownicy będą także nastawieni na akcelerację rozwoju zespołu.

Stabilne środowisko pozwala nam przestać myśleć o zmianie i ponownym wdrożeniu, poznawaniu procesów itp., a bardziej się skupić na realizowaniu własnego planu rozwojowego. Dlatego tak cenię sobie moją wieloletnią współpracę z Synergy Codes, bo dzięki temu mogłem poznać też aspekty niezwiązane bezpośrednio z programowaniem per se, ale rozwój procesów, automatyzacji, zagłębić się w budowanie planów rozwojowych. Dodając fakt, że jestem zwolennikiem podejścia modelu T-shape, który zakłada szeroki rozwój kompetencji a wąską specjalizację, pozwala mi to na realizację siebie w tym modelu.

Nie masz wrażenia, że coś tracisz przez to, że nie masz okazji poznać kultury pracy innych firm?

Nie, nie mam, a nawet uważam, że zyskuję. Przez swoją karierę miałem okazję pracować w różnych firmach, z wieloma technologiami. Muszę przyznać, że było to wartościowe doświadczenie, ale w żadnej chwili nie czułem, że jest to “ostateczne” miejsce pracy. Zawsze miałem potrzebę większej swobody, środowiska motywującego do rozwoju i pracy w firmie, która jest inkubatorem developera. Kiedyś nawet byłem po tej drugiej stronie muru, uważając, że częsta zmiana jest dobra. Szybko jednak zmieniłem zdanie, natrafiając na środowisko spasowane pode mnie.

Po dłuższym czasie zacząłem zauważać, co straciłem zmieniając firmy. W Synergy Codes miałem okazję budować od zera i utrzymywać aplikację rozwijaną cztery lata, a w IT przeciętna rotacja to dwa lata. Nie dowiedziałbym się w jaki sposób moje decyzje wpłynęły na ostateczne rozwiązanie, ani nie mógłbym uczestniczyć przy większym refaktorze rozwiązań przy dostosowaniu do nowych wymagań. Projekt ten dotykał wielu aspektów developmentu, a rozwijaliśmy korzystając z najlepszych praktyk: testy jednostkowe/e2e, code review, devops.

Później zacząłem pracować w większej dynamice, poznając wiele projektów, ludzi i klientów, co daje wrażenie znalezienia się w całkowicie innej firmie. Pozwala nam to spojrzeć e do środka firm klientów, zapoznać się z kulturą organizacyjną, a nawet zaczerpnąć dobrych praktyk wypracowanych przez inne organizacje.

To firma powinna dbać o to, by pracownik “nie zasiedział się”? Jeśli tak, to w jaki sposób może to robić?

Stwarzać środowisko do rozwoju i luźnej niepohamowanej wymiany wiedzy. W naszej firmie organizujemy dev-meetingi, lightning talki, angażujemy się w wewnętrzne inicjatywy, projekty, ustalamy cyklicznie cele rozwojowe podczas tzw. rozmów MOCy z liderem. Wszystkie te metody motywują do działania i ustalają jakiś rytm rozwojowy. Największym jednak wyzwaniem dla każdej firmy jest pogodzenie projektów klienckich i zaspokojenie żądzy wiedzy, jednakże ze zdrowym podejściem zawsze znajdują te godziny miesięcznie na rozwój.

Zwolennicy częstszej zmiany pracy argumentują, że to najszybszy sposób na podniesienie wynagrodzenia – jak odniesiesz się do tego stwierdzenia?

Przyznam rację! Jako programiści lubimy liczby, a te są bezwzględne. Jest to najszybsza/najłatwiejsza droga, aby podnieść wynagrodzenie. Czy jednak jedyna? Uważam, że jak ze wszystkim, prawda leży gdzieś pośrodku. Decydując się na podjęcie współpracy z nową firmą, trzeba zastanowić się nad każdym aspektem pracy, poza wynagrodzeniem trzeba też pomyśleć o perspektywie rozwoju, projektach, klientach oraz atmosferze. Zbyt wiele czynników do rozpatrzenia, żeby móc spłycić rozmowę tylko do pieniędzy. Czasami niewielki awans finansowy nie jest w stanie przekonać do zmiany, lecz intratna propozycja może wpłynąć pozytywnie na decyzję o zmianie. Jest to sprawa indywidualna i podchodziłbym do tego bardziej analitycznie.

Komu nie polecasz pracy w jednej firmie przez 5 czy 10 lat? Dla kogo nie będzie to dobre rozwiązanie?

Nawiązując do poprzedniego pytania: ludziom, którzy chcą szybko i dużo… pieniędzy. Dla osób, dla których to główna pobudka w życiu, model moich preferencji nie będzie odpowiedni. Gdy jednak liczy się dla nas coś więcej, wydaje mi się, że warto wykonać rachunek zysków i strat.

Bierzesz udział w rekrutacjach. W jaki sposób sprawdzasz, czy dany kandydat/kandydatka chce pracować właśnie w Synergy Codes, a nie tylko zmienić obecną pracę?

Rozpoczynam już od wstępnego screeningu CV. Jeżeli kandydat jest typowym skoczkiem, to zazwyczaj nie przechodzi tego etapu. Następnie już na rozmowie staram się spytać o pobudki do zmiany pracy. Niby proste pytanie, ale jednak bardzo wiele potrafi powiedzieć. Jeżeli pieniądze są jednym powodem do zmiany, to zapala mi się od razu lampka ostrzegawcza. Jeżeli jednak mam poczucie, że motywacji do zmiany pracy jest inna, to p, zaczynam się bardziej skupiać na tym czy kandydat starał się poczynić jakieś kroki, żeby poprawić sytuację u aktualnego pracodawcy, a być może nie spotkało się to z pozytywnym odbiorem. Dlaczego jest to dla mnie ważne? Bardzo łatwo wpaść w błędne koło narzekania. Wtedy każda kolejna praca będzie posiadać wady. To, w jaki sposób staramy się sobie radzić, czy walczymy o lepsze miejsce pracy jest kluczowe.

Oferty pracy z

Czego jeszcze szukasz wśród kandydatów? Jakie cechy sprawiają, że jesteś przekonany o tym, że kogoś warto zatrudnić?

Wszystkich rekrutujących w Synergy Codes łączy wspólny cel – zatrudnić sobie kolegę lub koleżankę do zespołu, dlatego lwia część rekrutacji stanowi sprawdzenie dopasowania do zespołu i naszej kultury organizacyjnej. Wiele z tych rzeczy jest nieoczywiste i wychodzi z rozmowy. Rzadko się zastanawiamy nad gestami, emocjami, które przekazujemy, a jednak jesteśmy w stanie stwierdzić, jakie zamiary ma druga strona.

Jednakże ciężko byłoby to przetestować, gdyby nie atmosfera, którą staram się tworzyć – każdy kandydat jest przeze mnie “zaopiekowany” i traktowany jak kumpel z zespołu. Rekrutacja odbywa się poprzez realizację praktycznych zadań, oczywiście można korzystać z Internetu, a na samym początku nie oczekuję nawet pięknego kodu. Tak jak w pracy, refaktoryzacja przychodzi jako kolejny aspekt i tutaj otwiera się dyskusja, bo dosyć często można porozmawiać o ulubionych wzorcach, praktykach z poprzednich firm, przekonaniach w kierunku konkretnego paradygmatu programowania.

Nie oczekuję zrobienia czegoś od linijki albo w paradygmacie, który sam stosuje w projektach, próbuję nawiązać z drugą osobą koleżeńską relację, w której oboje możemy się czegoś nauczyć. Gdy jest między nami chemia, a pasja programowania wylewa się ze zlewki, dla mnie jest to jednoznaczny sygnał – chcę z tą osobą pracować!

Umiejętności miękkie są ważniejsze od umiejętności twardych? Dla wielu to nielogiczne zatrudniać kogoś z brakami w znajomości stacku, ale ze świetnymi skillami związanymi np. z komunikacją.

Rekrutując, stawiam na osoby sympatyczne, otwarte, perspektywiczne i stawiające na rozwój. W rekrutacjach zależy nam na dopasowaniu do naszej kultury organizacyjnej. Trudniej mi jest sobie uzasadnić wybór osoby bardzo mocnej, która wykona większość pracy w projekcie, podczas gdy jej postawa doprowadzi do tego, że morale całego zespołu ucierpią. Miałem okazję pracować z takimi osobami, a jedyne co mi zapadło w pamięci to ich wywody i brak nastawienia na współpracę. Umiejętności, kompetencje automatycznie zeszły na dalszy plan, ponieważ ich szorstkość wchodziła do pomieszczenia jako pierwsza.

Stawia mnie to jako Team Leadera w trudnym położeniu, bo ostatecznie moją rolą jest dbać o samopoczucie każdego członka zespołu, a dokonanie zmiany w kompetencjach miękkich jest zdecydowanie trudniejsze do wypracowania, aniżeli przejście z Angulara na React’a. Jestem przekonany, że kandydaci z szerokim doświadczeniem w różnych technologiach bardzo szybko nadrabiają wszelkie zaległości, a pod okiem innych ekspertów w zespole ich wiedza wystrzeli!

Dla pracodawcy – wieloletni pracownicy – to najlepsze rozwiązanie? Firma nie traci na tym, że zespoły przez wiele lat składają się z tych samych osób?

Oczywiście, że nie traci. Ważne jest jednak, żeby organizację podsycać “nową krwią”. Nowi ludzie w zespołach przynoszą ciekawe spojrzenie, inne doświadczenia, metody wtedy czujemy to podniecenie z nowego związku. Dodaje to powiewu świeżości, a przy okazji rozwijamy… siatkę znajomych. Dodatkowo jako firma nie skupiałbym się na zatrzymywaniu osób w jednym projekcie/zespole. W Synergy Codes jeżeli ktoś wyraża chęć zmiany lub czyjeś kompetencje są wymagane do założenia całkowicie nowego zespołu, to po prostu to robimy.

O czym, Twoim zdaniem, za mało mówi się w kontekście pracy programisty?

Zdecydowanie o relacji biznesu i IT, bo ostatecznie strzelamy do tej samej bramki, chociaż czasami może wyglądać to zupełnie odwrotnie. Tak długo jak naszym biznesem nie jest biblioteka Open Source, tak długo powinniśmy poszerzać umiejętności miękkie, wiedzę z zakresu modelowania i zwinnego działania. Programista będzie miał pracę tylko wtedy, gdy będzie za tym stała potrzeba biznesowa, a klient otrzyma za stworzony produkt pieniądze. Poznając klienta i jego biznes, niejako stajemy się także jego integralną częścią, a problemy techniczne zamieniają się często na te biznesowe. Technologia pomaga nam w ich realizacji, lecz relacja ta nie działa w stronę przeciwną.

Sam czasami wpadam w tę pułapkę, ale kubeł zimnego strumienia bitów szybko studzi moje zapały. Niech nikogo nie zmyli to podejście, bo nie oznacza ono nagłej rezygnacji z wszelkich dobrych praktyk! Testy jednostkowe, code review, architektura aplikacji nadal są narzędziami rzemieślnika jakim jest programista, lecz uważam, że nie można się w tym wszystkim zatracić, tak samo jak nie rzucamy się z armatą na muchę. Gdy aplikacja klienta to prosty CRUD to niech takim zostanie!

O czym za mało mówi się w kontekście pracy Team Leadera?

O tym jak ciężko jest wyjść z roli specjalisty do roli człowieka, który zarządza zespołem. Od momentu, w którym zostałem Team Leaderem, to nie ja ciągnę ten projekt. Dla mnie to był szok! Ale jak to? Tyle czasu uczyłem się programowania, żeby po prostu przestać? Po objęciu tej roli najważniejszym celem stało się zatrudnienie ludzi, którzy będą mieli kompetencje do realizowania projektu, a ja stałem się latarnią kierującą ich do celu.

Wspieram zespół moją ekspertyzą, pomagam przy podejmowaniu poważnych decyzji projektowych, dbam o ich rozwój. Porównałbym to trochę do zakładania rodziny. Teraz nie jestem odpowiedzialny za siebie i swój czubek nosa, ale za ludzi, do których nie mówi się JavaScriptem czy Assemblerem. Jest to całkowicie inna klasa wyzwania, nadzwyczaj miękka, która z trudnością przychodzi inżynierom, do których przemawiają liczby.

Co sprawia, że nadal chcesz pracować w jednej firmie? Co jest takiego w pracy w Synergy Codes, co mogłoby przyciągnąć kandydatów?

Ogromna elastyczność, sympatyczni ludzie i skupienie firmy na samorozwoju! Jak wspomniałem wcześniej, sam lubię zadbać o swój rozwój, a firma stwarza mi do tego warunki. Podczas swojej prawie 6-cio letniej kariery w tej firmie miałem okazję wykonywać szeroki wachlarz projektów i pracować z różnymi technologiami. Zatrudniony zostałem na stanowisko JavaScript Developer’a, otrzymując projekt do stworzenia od zera. Doborem technologii zająłem się sam. Co więcej, zostałem postawiony przed bardzo ambitnym zadaniem, jakim było wytłumaczenie klientowi moich decyzji. Do dzisiaj pamiętam, jaki był to dla mnie stres, lecz cały czas był ktoś, kto mógłby mnie wspomóc. Była to niezła lekcja życia!

Dalej to było już tylko ciekawiej, bo ze swoim zapleczem zacząłem wykonywać projekt stricte DevOpsowy automatyzujący proces deploymentu aplikacji, nad którą pracowaliśmy. Moją decyzją podjąłem się Kubernetes, z którym pracuję po dziś dzień. Miałem okazję zaproponować i realizować projekty optymalizującym pracę programistów SC. Wymieniając dalej, poznałem GraphQL, Terraform, Docker, Azure, Google Cloud, Bitbucket Pipelines, Sentry, PostgreSQL, Typescript, React, Redux, Jest, TDD, Bash, Ansible, Express, Node.js, Selenium, Web Extensions, a nie wymieniłem jeszcze technologii, z którymi miałem jedynie przelotne doświadczenie.

Abstrahując od kompetencji twardych, osiągnąłem bardzo wiele w kontekście miękkich aspektów. Zostanie Tech Leadem, dbanie o architekturę rozwiązań naszych klientów, nabranie myślenia biznesowego, umiejętność prezentacji, kompetencji menedżerskich, uczestniczenie w rekrutacjach, dalej zostanie Team Leaderem, czynny udział w rozwoju technicznym firmy, obecność w planowaniu strategicznym, zarządzanie gildią techniczną to tylko niektóre z możliwości, jakie daje mi praca w Synergy Codes.

Jakbym miał krótko to podsumować, jest jeden czynnik, który pozwolił mi w tej firmie na osiągnięcie tak wielu rzeczy: wsparcie ludzi, chcących się rozwijać. Jest to zakorzenione w fundamentach firmy, że każdy, kto wykazuje chęci, dostaje ogromnego kopa od firmy!! Każdy mój pomysł, czy idea były wysłuchane, a większość z nich została lub jest realizowana. Taka ogromna otwartość na działanie i elastyczność są naprawdę rzadkie, a to, co nasza organizacja sobą reprezentuje, pozwoliło mi przejść do obozu “długodystansowców” lub jak kto woli “ludzi zasiedziałych” i powiem krótko – nie żałuję!

Artykuł został zaktualizowany 23.08.2022. Pierwotna data publikacji artykułu to 19.05.2021

---

Artur Ptaszek. Team Leader w Synergy Codes. Programista z pasją, którą realizuje już od ponad 16 lat. Podczas swojej 10-cio letniej kariery komercyjnej nabierał doświadczenia głównie małych i średnich firmach obracając się w technologiach zarówno frontendowych jak i backendowych. Poza odpowiedzialnościami związanymi z zarządzaniem zespołu planowaniem architektury i estymacjami projektów – lider gildii technicznej, katalizator rozwoju i automatyzacji. Ostatnio jego uwaga jest skupiona na DevOps, Cloud i programowaniu funkcyjnym.