Od developera do lidera, czyli o rozwoju i budowaniu zespołu słów kilka

Metapack stoi backendem, ale rozwój naszych produktów spowodował, że pojawiła się potrzeba zbudowania zespołów frontendowych. Nie było to łatwe zadanie, ale powierzyliśmy je Marcinowi, który ma na tym polu pewne doświadczenie.

Jakie? Dowiesz się z poniższej rozmowy. Marcin, nasz Frontend Team Leader opowie też, jak wygląda proces rekrutacji na stanowisko Frontend Developera w Metapack, jakich umiejętności szuka u kandydatów oraz jakie możliwości rozwoju oferuje członkom swoich zespołów.

Marcinie, zacznijmy od początku. Jak trafiłeś do Metapack?

Tak naprawdę już od początku studiów interesowałem się tematami zarówno z branży IT, jak i z branży menedżerskiej. Rozwijałem się równolegle w obu tych dziedzinach, chociaż z większym naciskiem na IT. W Metapack znalazłem się natomiast z polecenia znajomego. Na którymś spotkaniu z rzędu zauważył, że dobrze się mnie słucha, fajnie się ze mną rozmawia. Dostrzegł, że potrafię znaleźć źródło problemu zawodowego i ten problem dość szybko rozwiązać. Od razu zasugerował mi, żebym wystartował w rekrutacji na Frontend Team Leadera w Metapack. Na początku było to dla mnie zabawne, ale z czasem propozycja nabierała sensu. No i okazało się, że ze wszystkich kandydatów byłem najlepszy i oto jestem (śmiech).

Jak myślisz, co takiego nasi koledzy w Tobie dostrzegli podczas procesu rekrutacji? Jaką wiedzą lub doświadczeniem się wykazałeś, żeby zrobić na nich dobre wrażenie?

Jak już wspominałem, starałem się rozwijać w dwóch obszarach. Początkowo jako specjalista IT, żeby zdobyć niezbędną wiedzę i móc ją później wykorzystywać. Kiedy przyszedł moment, żeby działać już nieco bardziej menedżersko, założyłem organizację pożytku publicznego, którą nazwałem PingWin IT. Jej celem było zrzeszanie ludzi z całej Polski, którzy są na początku swojej kariery lub chcą się przebranżowić, albo po prostu rozwinąć określone kompetencje. Następnie znajdowałem im nieodpłatne zlecenia i tworzyłem grupy projektowe, w których mieli okazję zobaczyć jak wygląda prawdziwa praca w IT, a nie kolejny tutorial z Internetu. Cała idea okazała się strzałem w dziesiątkę. Zgłosiło się bardzo dużo osób, chętnych do podjęcia wyzwania.

A propos nieodpłatnych zleceń – kolejnym krokiem było pozyskanie przedsiębiorców, którzy potrzebują strony internetowej, sklepu online albo aplikacji i którzy – w zamian za darmowy produkt – zaangażowaliby do tego osobę początkującą. Ogłaszaliśmy się na portalach różnej maści, zarówno na grupach tematycznych na Facebooku czy choćby na Fiverr. Szukaliśmy również pocztą pantoflową ciekawych projektów. To miała być taka transakcja win-win. Przedsiębiorcy dostawali aplikację bądź stronę za darmo, natomiast byli oni informowani od samego początku, że projekt będzie tworzony przez osoby kompletnie niedoświadczone. Wiązało się to z tym, że nie jesteśmy w stanie podać konkretnych ram czasowych, choć na pewno dowieziemy projekt do końca. Wbrew pozorom, chętnych przedsiębiorców było mnóstwo. Z czasem do organizacji zaczęły zgłaszać się osoby bardziej doświadczone, seniorzy/eksperci, którzy chcieli prowadzić nasze grupy projektowe. Organizacja odbiła się dużym echem i funkcjonuje do dzisiaj.

Stałem na jej czele od samego początku. Pomagałem wszystkim zaangażowanym, wspierałem ich w realizacji projektów. Z czasem moje obowiązki sprowadziły się do nadzorowania czy wszystko działa jak powinno, a mentoringiem zajęli się seniorzy.

To bardzo imponujące. Powiedz nam, jak się wpada na takie pomysły i skąd znaleźć w sobie motywację, by podjąć taką inicjatywę i tak spore wyzwanie?

Mam taką cechę charakteru, że kiedy coś mnie irytuje to ciężko mi to tak po prostu zostawić. Wówczas siadam i zastanawiam się, co mogę zrobić, żeby to poprawić. Robię tak praktycznie w każdej dziedzinie mojego życia, stosując koncepcję ciągłego doskonalenia Kaizen. W przypadku PingWin IT bodźcem do działania był fakt, że jest tak wiele osób, które chciałyby rozpocząć swoją karierę, ale brak praktycznego doświadczenia je przed tym wstrzymuje. Owszem, jest dostęp do Internetu, wiedzy z YouTube’a, blogów czy książek, ale ta wiedza jest – w mojej ocenie – bardzo syntetyczna. Można wykuć na pamięć formułki, ale doświadczenie pokazuje, że nijak się to ma do rzeczywistości biznesowej. To są dwa różne światy i wiedza zdobyta z tutoriali internetowych to za mało, żeby rozwijać umiejętności praktyczne.

Postanowiłem więc wyjść temu problemowi naprzeciw i pomóc takim osobom jednocześnie uczyć się i zdobywać doświadczenie. Jest to o tyle cenne, że wiąże się nie tylko z samym programowaniem, ale też z rozmowami z klientem, wieloma spotkaniami projektowymi (najczęściej w środowisku SCRUM-owym). To okazja, żeby dostać swój pierwszy code review, ale również żeby przełknąć tę pierwszą gorycz po usłyszeniu od klienta, że dane rozwiązanie mu się nie podoba albo że trzeba je zmienić.

Nie tylko uczestnicy projektów mieli okazję się uczyć dzięki tej inicjatywie. Ty również dzięki projektowi PingWin IT zyskałeś doświadczenie w pracy menedżerskiej. Czy to Twoja jedyna styczność z takim stanowiskiem?

Poza PingWinem pracowałem również komercyjnie, w większości na stanowiskach developerskich. Co ciekawe, w każdej takiej pracy dosyć szybko stawałem się niepisanym liderem. Przypomina mi się ostatnia sytuacja, kiedy trafiłem do drużyny jako Frontend Developer. Miałem przydzielonego mentora, który był już dwa lata w firmie. Po około dwóch miesiącach nasze role się odwróciły – to ja stałem się jego mentorem. Najśmieszniejsze jest to, że było to zupełnie naturalne i niewymuszone. Kiedy wyjaśniał mi jakiś proces, zaczynałem z nim dyskutować, szukać rozwiązań, które sprawią, że zrobimy coś lepiej. Było tak również w poprzednich firmach, w których pracowałem. Dosłownie zawsze stawałem się niepisanym liderem i zawsze bardzo dobrze się w tej roli czułem. Nie trawi mnie stres, niepewność. Lubię mieć realny wpływ na projekt, rozmawiać z klientem, dyskutować na przeróżne tematy projektowe.

Myślę, że doświadczenie zarówno w IT jak i w byciu liderem to duża zaleta. Pracowałem po jednej i drugiej stronie „barykady”. Jeżeli klient czegoś chce, to potrafię to sobie wyobrazić z perspektywy developerskiej. Jestem w stanie z większą lub mniejszą dokładnością oszacować nakład pracy. Myślę, że jest to bardzo ważne. Moim zdaniem, żeby być dobrym przywódcą, trzeba kilka razy „pomachać łopatą”.

Wygląda na to, że jesteś odpowiednią osobą na odpowiednim miejscu. No właśnie, trafiasz do Metapack – do firmy, która tak naprawdę backendem stoi – i otrzymujesz zadanie stworzenia zespołu frontendowego. Brzmi jak nie lada wyzwanie.

Zgadza się, ale ja lubię wyzwania. Mimo tego, że Metapack stoi backendem, to wiele procesów deweloperskich jest tutaj bardzo dobrze przygotowanych i udokumentowanych. Praktycznie po miesiącu wdrożenia czułem się bardzo dobrze w całym organizacyjnym flow.

To porozmawiajmy chwilę jeszcze o produkcie, który będziecie w Twoim zespole rozwijać. Czym on jest i do czego służy?

To jest aplikacja do śledzenia przesyłek, która służy zarówno sprzedawcom jak i użytkownikom końcowym, czyli kupującym. Kiedy klient kupi produkt, wówczas ma możliwość monitorowania jego statusu od momentu nadania, aż do odbioru. Natomiast z perspektywy sprzedawcy, czyli klienta Metapack, aplikacja umożliwia spersonalizowanie swojej strony do śledzenia paczek. To trochę jak układanie klocków.

Aplikacja jest mocno rozbudowana. Umożliwia śledzenie kilku paczek naraz, wysłanych jednocześnie. Załóżmy, że klient kupi sobie na stronie trzy pary koszulek i sprzedawca wyśle je z trzech osobnych magazynów. Wtedy użytkownik może obserwować każdą taką paczkę jako część wielkiej przesyłki. Oczywiście po drodze pojawia się całe mnóstwo wyjątków. Dla przykładu, kiedy przesyłka jest wysłana do placówki odbioru, tzw. PUDO (PickUp DropOff), może się okazać, że w systemie przesyłka zmieni status na „Gotowa do odbioru”, a tak naprawdę jeszcze jej nie ma. Dzieje się tak najczęściej z błędów ludzkich. I to jest wyjątek. Dlaczego? Bo my jako Metapack nie możemy sobie tak po prostu cofnąć statusu, to jest wprowadzenie klienta w błąd, przecież mógł już sprawdzić status zamówienia. Aby zapewnić możliwie najwyższą jakość usługi musimy wyświetlić komunikat typu „Przepraszamy za powstały błąd, przesyłka jest nadal w trakcie realizacji”. To jeden z wielu wyjątków.

Czy zdobywasz już w tej chwili insight od klientów odnośnie aplikacji? Planujecie ją rozwijać zgodnie z trendami na rynku e-commerce?

Tak, zdecydowanie. Dla przykładu – badanie zachowań klientów oraz rozmowy z nimi pokazują, że częstą praktyką jest zwracanie towaru. Spory odsetek paczek kończy w ten sposób, zatem musi zostać to ujęte w naszym rozwiązaniu. Aplikacja ma więc zapewniać możliwość śledzenia przesyłki zwrotnej, jak i również możliwość nadania tego zwrotu. Poza tym aplikacja posiada jeszcze funkcje dodatkowe, takie jak np. ocena sprzedawcy.

Znamy już funkcjonalności, to teraz od strony technologicznej. Na czym stoi aplikacja do śledzenia przesyłek? Jakich technologii i narzędzi używacie?

Cała aplikacja jest napisana w React. Architektura i kwestie bezpieczeństwa oraz spójności danych zostały dobrze przemyślane, ponieważ komunikując się z zewnętrznym serwisem backendowym po drodze stoi jeszcze warstwa pośrednicząca – mikro serwis napisany w NodeJS, który również my obsługujemy. Ten backend jest niezwykle przydatny także przy zawiązywaniu sesji lokalnej, bez niepotrzebnego tworzenia kont zdalnych. W dodatku ewentualne zmiany, które będą przychodziły z zewnętrznych serwisów wymuszają na nas zmiany (prawie) wyłącznie w naszej warstwie NodeJS, bez ingerencji we frontend.

Wiemy już wszystko o aplikacji, nad którą pracujesz, to przejdźmy może płynnie do rekrutacji. Jesteś liderem zespołów, które budujesz, więc bierzesz czynny udział w procesie zatrudniania nowych osób. Powiedz, kogo szukasz w tej chwili.

Szukamy osób gotowych przyswoić sporą dawkę wiedzy o aplikacji. Liczy się tutaj przede wszystkim sumienność i otwartość. Doświadczenie również jest istotne, ale odnajdzie się u nas zarówno junior jak i senior. Jeżeli rozmawiamy o projekcie, to większość pracy została już wykonana. Nie ma więc parcia na terminy. W tej sytuacji osoba początkująca miałaby czas się wdrożyć, natomiast wymagałoby to od niej dużej ilości pracy i zapału. Mówiąc „osoba początkująca”, nie mam przy tym na myśli kogoś, kto nigdy nie pracował w technologiach, o których rozmawiamy. Mam na myśli osobę, która już w temacie działała, ale ma w tej materii jeszcze pole do rozwoju. Jeśli słowa docker, typescript czy hooki nie robią na kandydacie wrażenia to istnieje spora szansa, że się dogadamy.

Natomiast jeżeli chodzi o bardziej doświadczonych kandydatów, to myślę, że również dla takich osób znajdę tutaj obszary do rozwoju. Używamy mniej i bardziej skomplikowanych mechanizmów. Zadania deweloperskie dostosowuję, oczywiście w granicach rozsądku, pod kandydata i jego preferencje.

To jak w takim razie planujesz onboarding? Jak będą wyglądały pierwsze tygodnie pracy w Twoim zespole?

To jest wbrew pozorom bardzo złożone pytanie, bo każdy kandydat jest inny i budując zespół, staram się szukać w każdym z nich dodatkowych talentów. Pozycja nazywa się Frontend Developer. Natomiast jeden frontend może mieć zacięcie do backendu (Node’a), inny może mieć smykałkę do testowania. Jeszcze ktoś inny jest Frontend Developerem, ale lubi działać w tematach devopsowych. Są również kandydaci nastawieni stricte na frontend i poświęcających całą swoją energię na działania tylko w tym zakresie.

Zatem jeśli rozmawiamy o onboardingu to, w zależności od tych właśnie predyspozycji, będzie on wyglądał nieco inaczej. Dla przykładu, jeżeli zatrudniona osoba będzie wykazywała zainteresowanie NodeJS, to wprowadzam ją głównie w struktury backendowe. Jeżeli ktoś miałby podłoże testerskie, skupialibyśmy się – poza frontendem – również na tym, jak taką aplikację testować. Quality Assurance dla takiej aplikacji to bardzo złożony proces. Jeżeli z kolei dana osoba chciałaby rozwijać się dodatkowo w obszarach infrastruktury to pokazuję jej choćby to jak zachodzi cały proces release’u.

Oczywiście osobne kwestie wdrożeniowe związane z całą branżą i kierunkiem działania Metapack są prowadzone przez osoby trzecie, działające stricte w tych obszarach. Tutaj wygląda to dość jednolicie dla każdego kandydata.

Czyli cały onboarding podporządkowujesz pod kandydata. A jak wygląda proces rekrutacyjny? Czy jest on taki sam dla wszystkich? Czego kandydaci mogą się spodziewać krok po kroku?

Jestem fanem minimalizmu i prostoty, więc kolejne etapy też są uproszczone. Pierwszy to rozmowa z rekruterem. Celem takiej rozmowy jest weryfikacja obustronna. Dowiadujemy się, czy kandydat już ze szczątkowych informacji się nadaje oraz czy nasze podejście odpowiada kandydatowi. Weryfikujemy tutaj również znajomość języka angielskiego. W zasadzie ciągła praca na tym stanowisku tego wymaga i bez języka będzie takiej osobie bardzo ciężko wdrożyć się do obowiązków i je wykonywać. Komunikatywna, absolutnie minimalna znajomość angielskiego powinna wystarczyć na początek.

Drugi etap to zadanie rekrutacyjne. Jest ono tak stworzone, aby sprawdzało umiejętności przekrojowo, od osoby początkującej do eksperta. Sprawdza wiele obszarów wiedzy z zakresu frontendu. W treści zadania jest wyraźnie napisane co należy wykonać. Zostało również wyraźnie zaznaczone, co wchodzi w zakres umiejętności juniorskich/mida/seniora. To też jasno podkreślamy. Nie chciałbym, aby kandydaci niepotrzebnie się frustrowali. Kandydat wykonuje zadanie i zamieszcza projekt na GitHubie, dodaje mnie jako osobę współtworzącą. Wówczas ja mam wgląd do listy commitów (historii wykonanej pracy), do kodu, no i oczywiście mogę sobie to repozytorium pobrać, odpalić, sprawdzić czy w ogóle działa.

Po tym etapie wypisuję uwagi. Mam takie trzy rubryki: mocne strony, drobne minusy, które mogły być zrobione lepiej oraz poważne błędy, wynikające najczęściej z niewiedzy kandydata. Taką notatkę kandydat zawsze dostaje w odpowiedzi, bez względu na to, czy dostał się dalej czy nie.

Ostatni etap to rozmowa rekrutacyjna, której ogólnym zamysłem jest to, żeby ta osoba nas zobaczyła, żebyśmy my ją zobaczyli, żebyśmy mogli porozmawiać, zobaczyć, jak nam się rozmawia. Nie jestem zwolennikiem rzucania pytaniami jak z karabinu, to nie ma sensu. Taka rozmowa pozwala mi przede wszystkim sprawdzić, czy kandydat sam wykonał zadanie czy zrobił to za niego ktoś inny, bo niestety takie sytuacje się zdarzają. Już po pierwszych kilku pytaniach wszystko staje się jasne, więc naprawdę nie warto stosować takich praktyk. Lepiej zrobić mniej i się nie dostać niż zrobić dużo, ale później po prostu wygłupić się na spotkaniu. Przebieg ma charakter rozmowy jak developer z developerem. Pytam jak dbają o swoją wiedzę, z jakich źródeł korzystają, o ulubionych twórców internetowych, projekty komercyjne i niekomercyjne i tak dalej.

Rekrutacja zawsze jest wyzwaniem, bo musimy w bardzo krótkim czasie poznać kandydata i stwierdzić czy się nadaje. Myślę, że te etapy pozwalają w miarę rzetelnie sprawdzić czyjąś wiedzę, ale też umożliwiają zainteresowanemu ustalenie czy chce pracować z nami.

Ile średnio trwa taki proces na jednego kandydata?

Wiele zależy od dostępności osoby aplikującej. Na wykonanie zadania są dwa tygodnie, a to i tak jest duży zapas czasowy. Można je zrobić w 3 dni, ale liczymy się z tym, że kandydat może nie być wystarczająco dyspozycyjny, stąd dodatkowy czas. Na rzetelną ocenę zadania potrzebuję jeden, góra dwa dni. Cały proces powinien zamknąć się zatem w dwóch tygodniach, ale wszystko zależy od kandydata.

Twoje zespoły są budowane i przystosowywane do pracy zdalnej, co oznacza, że otwierasz się na kandydatów z całej Polski. Jak Ty to widzisz? Jakie masz podejście do pracy zdalnej i rozproszonego zespołu?

Zawsze śmieję się wśród znajomych, że wyprzedziłem czasy COVID. Od początku pracy jako developer, bardzo cenię sobie pracę zdalną. Lubię programować w zaciszu domowym. Oczywiście chętnie przychodziłem do biura, ale zauważyłem, że skupiałem się wówczas przede wszystkim na rozmowach z developerami, wymianą doświadczeń, a nie samym developmencie. Po prostu w biurze mam ochotę dużo rozmawiać. W moim przypadku praca z domu jest więc bardziej wydajna.

Jeżeli chodzi o utrzymanie zintegrowanego zespołu, obecnie jest wiele narzędzi, które to umożliwiają. Podstawową rzeczą jest zbudowanie zarówno z pracownikiem, jak i zespołem takiej więzi, żeby nie wymuszać, ale zachęcać do feedbacku i rozmów. Nie traktować spotkań online jako zła koniecznego, ale miejsca do wymiany doświadczeń. Na pewno będę chciał budować takie nastawienie w swoim. W PingWinie zespoły też były rozproszone, a współpracowały ze sobą bez najmniejszych problemów.

Dobrze sprawdzają się przy tym takie narzędzia liderskie, jak np. „coffee roomy”, gdzie cały dzień pokój online jest otwarty, można wejść z kawą w ręku i porozmawiać z inną osobą, niekoniecznie na tematy techniczne. Co jakiś czas organizuję też z developerami spotkania, „one to one”, które mają na celu dbanie o well-being pracowniczy i możliwie szybkie lokalizowanie i rozwiązywanie problemów.

Oczywiście praca zdalna nie wyklucza prawdziwej integracji. Nie wykluczam organizowania kilkudniowych wyjazdów. Wiadomo, widzimy się, zbijamy piątkę i wychodzimy na kolację.

Pewnie, a wiemy, że Metapackersi chętnie się ze sobą spotykają również po godzinach. Wracając jeszcze do rekrutacji, bo w całym tym procesie trochę aplikacji już przejrzałeś. Jakie masz takie pierwsze wrażenie, pierwszą opinię o kandydatach, czy o rynku kandydatów. Jest coś, co Cię zaskoczyło?

Z pozytywnych zaskoczeń, zdarzyło mi się kilku kandydatów, którzy napisali zadanie trochę gorzej, ale mimo wszystko przeszli do kolejnego etapu i na rozmowie okazali się dużym wulkanem wiedzy. Potrafili krótko i treściwie odpowiadać na pytanie, wyczerpując temat w zasadzie w kilku zdaniach. Niestety zdarzali się również kandydaci, którzy najprawdopodobniej wysyłali CV z góry na dół wszędzie, nie czytając, na jakie stanowisko aplikują. Na przykład, programista Pythona z rocznym doświadczeniem, który nie ma nawet wzmianki o JavaScript w CV. Miałem również okazję rozmawiać z programistą, który wykonał zadanie perfekcyjnie, ale na rozmowie po dziesięciu minutach wiedziałem, że to nie był on.

Co smutne, trafiło do nas też kilku kandydatów skrzywdzonych przez poprzedniego pracodawcę i albo to akurat nam się tacy trafiają, ale sytuacja jest bardziej powszechna niż mogłoby się wydawać. Mam tutaj na myśli sytuację, gdzie firma nie docenia pracownika, nie dba o jego rozwój. Ciężko jest rozwijać się bez mentora, który wskaże kierunek i znajdzie obszary do poprawy. To jak błądzenie w lesie. Moim zdaniem – lekkie szaleństwo.

Wiedza jest dzisiaj powszechnie dostępna, ale jest też w Internecie wiele informacji „śmieciowych”. Problem polega na tym, że skąd osoba początkująca ma wiedzieć, co jest dobre, a co nie? Coś, co dla nas jest zupełnie naturalną rzeczą, dla wielu kandydatów okazało się więc profitem.

No właśnie, co takie młode, zdolne osoby mogą zrobić, żeby się rozwijać i odnaleźć w tym gąszczu wiedzy i informacji? Co byś im polecił jako pracownik już z dużym doświadczeniem i wiedzą?

Podejść do tematu najbardziej ambitnie jak to możliwe. Nawet mając niewielkie doświadczenie. Można spróbować znaleźć jakiś projekt albo przyłączyć się do znajomego, który nad jakimś projektem pracuje. Być może uda się znaleźć grupę osób na forach czy grupach tematycznych, które chciałyby wspólnie podziałać. Cały czas zmierzajmy w kierunku podejścia projektowego. Naprawdę nie jestem fanem wiedzy z tutoriali internetowych.

Równie istotne jest znalezienie sobie mentora. Im bliżej znamy się z tą osobą, tym lepiej. Może to być członek rodziny, znajomy z większym doświadczeniem, osoba publiczna z Internetu. Chodzi o to, żeby ta wiedza była możliwa do skonsultowania z autorem. Kiedy rozmawiam z developerami, często podaję tutaj metaforę tablicy szkolnej jako naszego mózgu i wiedzy, która się w nim znajduje. Jeżeli już coś na takiej tablicy zapiszemy, to później ciężej jest pewne złe nawyki czy „śmieciową” wiedzę zastąpić już tą właściwą. Tablicę można wymazać – ludzką pamięć, przynajmniej na ten moment, nie.

Dziękujemy za rozmowę.