Każdy poszukuje innych cech u swojego pracodawcy. Marcin Skrzypek o pracy lidera

Projektowanie własnej ścieżki kariery nie należy do zadań łatwych. Szczególnie, gdy jesteśmy na początku drogi z programowaniem. O swoją przyszłość powinni ubiegać się przede wszystkim pracownicy, ale też na rozwoju zespołu powinno zależeć pracodawcy. Zdaniem Marcina, rola lidera skupia się na tym, by poznać potrzeby zespołu.

– Kilka razy od kandydatów słyszałem, że odeszli z poprzedniej firmy ponieważ obawiali się, że nie rozwija się, ze względu na brak rozwiązań chmurowych. Brak chmury był dla nich nieakceptowalny – powiedział nam w rozmowie.

Jak z perspektywy lidera wygląda praca w branży IT? Na to pytanie odpowiedział nam Marcin Skrzypek, Lider techniczny w BGK.

Jaki był Twój pierwszy kontakt z programowaniem? Jaki był pierwszy język z jakim miałeś styczność?

Po raz pierwszy z programowaniem zetknąłem się w latach 90, kiedy jakoś pod koniec szkoły podstawowej próbowałem pisać proste programy w Assemblerze, na podstawie kursów jakie znajdowałem w czasopismach komputerowych. Było to oczywiście w formie zabawy i zaspokojenia ciekawości. Wtedy jeszcze nie miałem pojęcia, że kiedyś moja droga zawodowa będzie związana z programowaniem. Później pojawiały się Pascal, C, C++, JavaScript, ActionScript 3, aż wkońcu C#.

Porozmawiajmy właśnie o drodze programisty. Jak poszukiwałeś swojej ścieżki? W jaki sposób znaleźć technologię, język, który okaże się kluczowym w naszej karierze?

Sądzę, że nie ma złotego środka i uniwersalnej instrukcji jak taki język znaleźć, ponieważ droga każdego programisty jest inna. Moja wygląda tak, że na początku oczywiście nie wiedziałem, w którą stronę chciałbym rozbudowywać swoją ścieżkę zawodową. Nie potrafiłem jasno odpowiedzieć na pytanie, gdzie widziałbym się za 10-20 lat. Myślę, że to przychodzi z czasem, wraz ze zdobytym doświadczeniem w ogólnie pojętym IT.

Poszukiwałem więc swojej drogi programując gry, aplikacje desktopowe, później webowe.

Począwszy od prostych stron, nieco większych portali czy kampanii internetowych, jak i później dużych systemów korporacyjnych. Uważam to za duży plus ponieważ miałem okazję zobaczyć od środka różne podejścia. Porównać pracę przy programowaniu gier (od czego dość szybko odszedłem) z pracą w korporacji świadczących usługi dla klientów indywidualnych, czy korporacyjnych.

Język programowania z kolei był dla mnie zawsze narzędziem do wykonania danego zadania. Zupełnie jak rodzaj śrubokręta dopasowanego do rodzaju śrubki.

W trakcie poszukiwań nie sposób nie podjąć trudnych decyzji. Jakie to były decyzje w Twoim przypadku (mówimy cały czas o początkach kariery)?

Każda zmiana pracy jest trudną decyzją. Z jednej strony chcemy coś zmienić, rozpocząć nowe projekty, być może zacząć pracować w nowej technologii, z drugiej, nie wiemy jak będzie w nowym miejscu. Na rozmowie kwalifikacyjnej możemy oczywiście dopytać o jak największą ilość rzeczy, ale to nie zawsze oddaje realia panujące w tej firmie.

Musimy też odpowiedzieć sobie na pytanie czy chcemy jeszcze pogłębiać swoje doświadczenie w obecnej firmie, przy kolejnych lub tych samych projektach czy może to dobry moment na zmianę, spróbowanie czegoś nowego i tym samym poznanie nowych możliwości.

Każdy ma obawy przed zmianą pracy. Pojawiają się w głowie pytania “a co jeśli tam będzie niefajna atmosfera?”, “a co jeśli sobie nie poradzę?”, “nie znam tego biznesu, może to okaże się nie dla mnie?”. Jest to całkowicie normalne. Uważam jednak, że szczególnie na początku naszej kariery powinniśmy sprawdzić różne możliwości. Budujemy wtedy bazę, na której będziemy opierać nasze dalsze doświadczenie. Kiedy jak nie teraz?

Polecasz podejmowanie się różnych ról w różnych firmach czy rozwijanie swojej ścieżki kariery w jednej firmie?

Na to pytanie każdy powinien odpowiedzieć sobie sam, ponieważ każdego motywuje coś innego. Muszę jednak podkreślić, że czym innym jest praca w jednej firmie prowadzącej wąski biznes, z niewielką liczbą aplikacji, gdzie może pojawić się (ale wcale nie musi!) ryzyko stagnacji zawodowej. Czym innym jest praca w software house, gdzie mamy różnorodność projektów dla wielu klientów różnych typów biznesu.

Jeśli ktoś ceni sobie stabilizację, a firma, w której pracuje przynosi mu satysfakcję z pracy, nie ma absolutnie niczego złego w tym, że pracuje w niej kilkanaście czy kilkadziesiąt lat.

Warto jednak uważać, by nie zostać w jednej technologii, która w pewnym momencie zostanie uznana za, na tyle starą, że możemy okazać się mało atrakcyjni na rynku pracy.

Możemy wybrać też mniej popularny język, zawęzić swoją specjalizację, dzięki temu być w gronie bardziej pożądanych, ale trudnych do pozyskania (ze względu na ich ilość na rynku) specjalistów.

Trochę innym podejściem jest praca dla różnych firm. Tu z kolei mamy możliwość zobaczenia wielu organizacji od środka. Zobaczyć różne podejścia w IT. Porównać je, wyciągnąć wnioski, zaadaptować w innej firmie. To według mnie bardzo cenne doświadczenie. Podobnie jak poznanie specyfiki różnych biznesów. Inaczej pracuje się w branży finansowej, a inaczej w branży medycznej.

Czym dla programisty różni się praca w firmie rozwijającą własny produkt od pracy w firmie, która realizuje projekty dla różnych klientów?

Jako programiści w firmie rozwijającej własny produkt możemy lepiej poznać, zrozumieć biznes tej firmy. Czujemy też większą odpowiedzialność za ten produkt. Niejako sami rozwijamy system, z którego później korzystają klienci. Czujemy, że mamy wkład w ten biznes, jesteśmy odpowiedzialni za ten system. Projektując coś patrzymy przyszłościowo, wiemy, że ten system będziemy utrzymywać przez jakiś czas. Wiemy jakie są jego powiązania z innymi systemami w firmie i jakie są tego konsekwencje.

W przypadku firmy realizującej projekty dla różnych klientów, np. software housie, sprawa, z mojego doświadczenia, wygląda trochę inaczej. Projektując oprogramowanie dla firmy zewnętrznej kluczowe jest odpowiednie zebranie wymagań klienta, co w praktyce wcale nie jest takie proste. Zdarza się, że zaczynamy projekt dla klienta z branży, o której niewiele wiemy i tutaj znaczenie mogą mieć nawet drobne szczegóły. Dla klienta coś może być oczywiste, dla nas nie.

Zdarza się też, że pracując w zespole wytwórczym nie zajmujemy się później utrzymaniem tego systemu, albo utrzymujemy go przez jakiś, określony w umowie czas. Dużym plusem takiej pracy jest różnorodność projektów, która może oznaczać również różnorodność technologii, rozwiązań, typów architektur systemu. Ale czasem nie mamy możliwości obserwowania, jak sprawdza się nasz system po latach.

Jednym z ciekawych doświadczeń na mojej drodze zawodowej było to, że kiedy pracowałem dla software house, miałem okazję brać udział w programowaniu systemu dla klienta ubezpieczeniowego, a później, pracować jako pracownik tego właśnie klienta. Jednym z moich obowiązków był m.in. rozwój, rozbudowa i utrzymanie tego właśnie systemu. Ciekawe doświadczenie poznania podejścia dwóch stron do tego samego projektu.

Porozmawiajmy o perspektywie pracodawcy. Co jest kluczowe dla pracodawcy by utrzymać pracownika w firmie?

Osobiście uważam, że poznanie motywacji swoich pracowników. Moim zdaniem pracodawcy często zakładają, że zawsze chodzi o motywację finansową, co jest bardzo mylne. Pracownik przynosi wypowiedzenie, wtedy dostaje propozycję zwiększenia wynagrodzenia, ale odrzuca tę propozycję i odchodzi. To częsta sytuacja. Nawet jeśli pieniądze to częsta przyczyna to jednak nie jedyna i wielu programistów da się zatrzymać, stworzyć dla nich idealne miejsce pracy bez znacznego zwiększania swoich nakładów finansowych.

Czasem naprawdę konkurencyjne może być zapewnienie programistom rozwoju, odpowiedniego budżetu szkoleniowego, zapewnienie odpowiedniego zestawu narzędzi, danie możliwości rozwoju i możliwości wykorzystania swojego potencjału, by zwiększyć morale pracownika.

Możesz podać jakieś przykłady?

Na przykład dla jednego z UX Designerów w moim zespole bardzo motywujący był zakup licencji na cały pakiet Adobe. Dało mu to możliwość nauki nowych narzędzi z pakietu popularnego producenta, otworzyło możliwości zdobycia nowego doświadczenia i usprawniło jego dotychczasową pracę.

Kiedyś zauważyłem, że u części programistów pracujących w zespole utrzymania, mającego już kilka lat systemu, ich motywacja zaczęła spadać. Trwały wówczas rozmowy na temat przebudowy tego systemu, na nową architekturę, nowy stack technologiczny, z dorzuceniem do zespołu odpowiedzialności za rozwój aplikacji hybrydowej. Gdy koncepcja została zaakceptowana, nagle również z innych zespołów zaczęły pojawiać się pytania, czy mogliby dołączyć do tego projektu. M.in. ta sytuacja utwierdziła mnie w przekonaniu, że naprawdę nie zawsze chodzi o zwiększenie wynagrodzenia.

Pamiętasz projekt, który dał Tobie najwięcej motywacji?

Myślę, że w każdej firmie, dla której miałem okazję pracować, mógłbym wskazać taki projekt. Staram się czerpać motywację z różnych zadań. Każdy wysiłek, trud włożony w dane zadanie, który później zaowocuje jest motywujący.

Gdy poświęcasz długi okres czasu na rekrutacjach i budowaniu zespołu, po to by za jakiś czas widzieć zgrany i sprawny sztab ludzi, złożony z kilkudziesięciu zmotywowanych osób, realizujący sprawnie zadania, masz poczucie, że robisz dobrą robotę.

Gdy opracowujesz architekturę dużego systemu, proponujesz w firmie nowe rozwiązania techniczne (czasem będące pewną rewolucją w skali całej firmy), a później widzisz system świetnie realizujący zadania, do których został przeznaczony, chcesz robić to dalej.

Kiedy podejmujesz trudne decyzje czy managerskie czy techniczne i z czasem widzisz ich pozytywny efekt w przyszłości, to również jest budujące.

Miałem okazję pracować przy systemach przeznaczonych do kształcenia słuchu w szkołach muzycznych, planery dla agencji pracy, kalkulatory ubezpieczeniowe, aplikacje bankowe i wiele innych. Każdy z tych projektów na swój sposób dawał mi satysfakcję, ponieważ każdy był inny, każdy stawiał przede mną inne wyzwania i problemy. Może właśnie ta różnorodność była głównym napędem motywacyjnym.

Opowiedz o projekcie, nad którym pracowałeś najdłużej. Czego się wtedy nauczyłeś?

Nie jestem pewny czy najdłużej, ale na pewno jednym z większych było połączenie systemów kilku spółek podczas ich fuzji. Wiązało się to z architekturą integracji systemów, zbudowanych w różnych stackach technologicznych, wyniesieniem systemu w chmurę, po uprzednim researchu dostępnych możliwości. Była to jedna z większych inicjatyw, którą wspominam do dzisiaj.

Co skierowało Ciebie do podjęcia roli lidera?

To wyszło naturalnie. Po kilku latach jako programista zaczęto mi powierzać obowiązki architekta, co zaowocowało zmianą stanowiska, zacząłem brać udział w rekrutacjach, początkowo jako wsparcie dla managera, z czasem przeprowadzając rozmowy z kandydatami samodzielnie. Po pewnym czasie również przejąłem obowiązki managerskie.

To wszystko działo się stopniowo i przechodziło raczej płynnie i naturalnie na przestrzeni czasu, w różnych firmach. Dziś pełnię rolę lidera technicznego by wesprzeć swoim doświadczeniem szeroko pojętą transformację cyfrową banku. Chętnie dzielę się wiedzą, lubię pracować z zespołem dlatego w tej chwili ta rola wydaje mi się atrakcyjna dla mnie zawodowo.

Jednym z zadań lidera jest uczestniczenie w procesie rekrutacji. Jakimi doświadczeniami z tego procesu mógłbyś się podzielić?

Przede wszystkim tym, że każdy człowiek jest inny, ma inne potrzeby zawodowe, każdego motywuje coś innego i każdy poszukuje innych cech swojego pracodawcy. Coś co dla kogoś może być nieakceptowalne, dla kogoś innego może nie mieć większego znaczenia.

Kilka razy od kandydatów słyszałem, że odeszli z poprzedniej firmy ponieważ obawiali się, że nie rozwija się, ze względu na brak rozwiązań chmurowych. Brak chmury był dla nich nieakceptowalny i u niektórych powodował nawet pogorszenie zdania o tym pracodawcy. Inni kandydaci motywowani byli zupełnie innymi kryteriami, a brak, w tym przypadku, rozwiązań chmurowych, nie miał dla nich żadnego znaczenia. Myślę, że to dobry przykład.

Dlatego staram się by moje rozmowy rekrutacyjne przebiegały w charakterze rozmowy, której celem jest wzajemne poznanie siebie. Swoich potrzeb, oczekiwań, doświadczeń. Efektem takiej rozmowy ma być nawiązanie współpracy, z której obie strony będą zadowolone i w której obie strony muszę od siebie dawać coś wartościowego dla drugiej strony.

Czego lider szuka w kandydatach? Co docenia, a co sprawia, że kandydat traci w oczach?

Nie tylko lider, ale również manager/pracodawca poszukuje specjalisty, który pomoże mu rozwiązać jego problemy techniczne i wzmocni skład aktualnego zespołu. Zadaniem lidera może być po prostu odpowiedni dobór takiej osoby. Częstym pytaniem kandydatów (również moim, gdy sam zmieniam pracę), jest pytanie o stack technologiczny. Każdy chce rozwijać się używając nowych rozwiązań i iść do przodu. To zrozumiałe i słuszne podejście.

W każdej firmie jednak znajdą się systemy, które możemy zaliczyć już do kategorii Legacy. Czasem w takim systemie zachodzi konieczność wprowadzenia zmiany, która jest z punktu widzenia dużo tańszym wyborem niż np przepisanie całego systemu na nowsze rozwiązania.

Zdarzało się, że kandydaci wyrażali całkowity sprzeciw co do potencjalnej konieczności wykonania takich zmian w przyszłości. Rozumiem to podejście ponieważ oczywistym faktem jest, że wykonanie zmiany w starym systemie jest mniej przyjemną pracą niż pisanie w najnowszych technologiach.

Wyobraźmy sobie jednak, że zatrudniamy fachowca do domu w celu naprawy cieknącego kranu. Jeśli usłyszelibyśmy od niego, że nie podejmie się zadania ponieważ kran jest starszego typu, a on chce pracować tylko przy najnowszych, pewnie uznalibyśmy, że nie jest odpowiednim kandydatem do rozwiązania naszego problemu.

Dokładnie tak samo pracodawca może odebrać programistę.

Nie chcę tutaj powiedzieć, że programista ma godzić się na pracę głównie w systemach legacy. Zmierzam do tego, że pracodawca chce móc liczyć na swojego specjalistę w każdej sytuacji, nawet wtedy gdy wyjątkowo trzeba będzie poświęcić tydzień pracy na modyfikację starszego systemu. Brak takiej chęci nie jest jednak powodem, dla których ktoś miałby stracić w moich oczach jako osoba. Staram się nie oceniać ludzi i w pełni rozumiem to, że potrzeby, jak również oczekiwania i obrana ścieżka kariery każdego programisty jest inna.

Osobiście cenię osoby otwarte, potrafiące nawiązać dobry kontakt z resztą zespołu, z dużą chęcią rozwoju i poszerzania swoich kompetencji. Ważna jest również komunikatywność. Programista, który potrafi rozmawiać z ludźmi, potrafi współpracować z biznesem, na pewno zyskuje jako profesjonalista.

Jak poza pracą programista może/powinien rozwijać swoje umiejętności?

Przede wszystkim, wykonywać jak najwięcej projektów prywatnych. Pisać, pisać i jeszcze raz pisać. To właśnie podczas pisania kodu i tworzeniu nowych projektów utrwalamy sobie zdobytą dotychczas wiedzę, jak również napotykamy na nowe problemy, które musimy rozwiązać, co z kolei przekłada się na zdobywanie nowego doświadczenia. Samo przeczytanie książki czy kursu, nie wystarczy. Może jedynie pomóc jako start do praktyki.

Uważam, że kluczowym elementem w pracy programisty jest to by programowanie było jego pasją. Wtedy rozwój na własną rękę przychodzi naturalnie, jako zaspokojenie wewnętrznego głodu wiedzy. Dziś możliwości jest naprawdę dużo: konferencje z różnych dziedzin IT, spotkania grup entuzjastów danej technologii, blogi i vlogi znanych specjalistów, w tym zagranicznych. Tony kursów, które można znaleźć w internecie na wielu portalach.

Pracodawcy rzeczywiście zwracają uwagę na to, czy programista rozwija swoje umiejętności po pracy?

Nie. Pracodawców raczej interesuje czy ten właśnie programista będzie w stanie pomóc w realizacji założonych celów i sprawnie realizować swoje zadania. A to czy w domu spędzi kilka godzin przerabiając kursy, czy po prostu nauczy się wszystkiego w pracy przy realizacji aktualnych projektów, nie powinno mieć znaczenia. Wiadomo jednak, że programista rozwijający się, będący na bieżąco, proponujący w firmie nowe rozwiązania, jest z czasem bardziej przydatny niż ten, który stoi w miejscu.

Takie podejście programisty sprawdza się na każdym etapie rozwoju? Co poleciłbyś midom i seniorom?

Myślę, że to co głównie wyróżnia mida, czy seniora to przede wszystkim samodzielność. Chęć i umiejętność zdobycie wiedzy i rozwiązania problemu oraz większe nastawienie przede wszystkim na wsparcie biznesu niż konkretnie na technologię. Mam tu na myśli bardziej podejście raczej w stronę: “do realizacji tego zadania proponuję użycie technologii B, ponieważ da nam to benefity: X,Y” niż podejście “nie róbmy tego, bo w technologii A, nie da się tego zrobić” lub “przebudujmy system na technologię C, bo jest fajna”. A z takimi podejściami też się spotkałem.

Dużym atutem jest zrozumienie, że biznes, zainteresowany jest realizacją założonych celów i wynikami. Potrzebuje realizacji danego zadania, by ta, przełożyła się w pośredni lub bezpośredni sposób np. na wynik finansowy. To w jaki sposób coś zostanie zrealizowane technicznie, ma drugorzędne dla niego znacznie.

Tę decyzję powinniśmy zapewnić my, jako specjaliści, ale wybierając rozwiązania właśnie do realizacji tego założonego celu. A nie dla samej przyjemności, np. wdrożenia interesującej nas technologii. Jeśli jednak jedno z drugim uda się połączyć i czerpać benefity po obu stronach, to pewnie będzie to układ idealny.

Czy gdy dziś patrzysz wstecz na swoją ścieżkę kariery, myślisz, że zaplanowałbyś ją inaczej? Czy żałujesz jakiegoś swojego wyboru na przestrzeni lat? Np. nawiązując współpracę z inną firmą niż, któraś w przeszłości?

Absolutnie nie. Każda podjęta decyzja, nawet jeśli dziś mogłaby nie wydać się najlepsza, dała mi cenne doświadczenie, które było schodkiem do miejsca, w którym jestem dzisiaj. Ważne by czerpać doświadczenie z każdej swojej decyzji, zarówno tej, z której jesteśmy zadowoleni, jak również z tej, którą dziś podjęlibyśmy inaczej.

Marcin Skrzypek. Lider techniczny w BGK. Ekspert IT z kilkunastoletnim doświadczeniem w wielu rolach (programista, lider techniczny, architekt, manager) zdobywanym w pracy dla dużych korporacji. Swoje doświadczenie zdobywał m.in. w branży: ubezpieczeniowej, medycznej i bankowości. Głównie zajmuje się programowaniem i projektowaniem architektury systemów korporacyjnych oraz zarządzaniem zespołami developerskimi.

Oferty pracy z