W IT liczy się zaangażowanie, kreatywność i chęć rozwoju. Historia Marka Mach

– Robię to co lubię, robię to, o czym kiedyś marzyłem i nadal chcę się tym zajmować. Ale to nie przypadek – to efekt ciężkiej i konsekwentnej pracy – powiedział nam w rozmowie Marek Mach, Director, Engineering w Ellie Mae. Jego zdaniem w pracy nad swoją ścieżką kariery ważne jest oddzielenie pracy zawodowej od własnego rozwoju.

Menedżer nie powinien decydować za pracownika, w jakim kierunku powinien się rozwijać. – Każdy musi sam się określić, jaką ścieżką kariery chce podążać i wykazać się determinacją, by robić w tym postępy. Firma zaś powinna tę drogę wspierać – dodał. Poznajcie ścieżkę kariery Marka Mach, który pracował jako programista, manager w sektorze Public, jak i manager w sektorze B2B.

Twoją ścieżkę kariery możemy podzielić na trzy etapy: deweloper, manager w projektach w sektorze Public, manager w projektach w sektorze B2B. Zacznijmy od pierwszego: jak zostałeś programistą?

Swój pierwszy komputer Atari 65xe dostałem jeszcze w podstawówce. Gry komputerowe jakoś nigdy mnie specjalnie nie wciągały, za to od samego początku wkręciłem się w programowanie. To były lata dziewięćdziesiąte, lata Polski szarej, burej i biednej, za to pełnej nadziei na lepsze jutro. Szczęśliwie się złożyło, że moje hobby wyglądało na racjonalny pomysł na przyszłość. Miałem więc fantastyczne wsparcie zarówno rodziców, jak i później, nauczycieli w liceum.

Naturalnym kolejnym krokiem były studia informatyczne na Politechnice Wrocławskiej, w których trakcie dowiedziałem się, że istnieje coś takiego jak zarządzanie projektami, które od tego momentu stało się celem mojej dalszej kariery. Kiedy kończyłem studia, bezrobocie w Polsce było gigantyczne, także w raczkującej branży IT. Po kilku miesiącach czyszczenia klawiatur, instalowania pirackich windowsów czy antywirusów, udało mi się w końcu dostać jako programista do niewielkiej wówczas firmy tworzącej oprogramowanie dla Straży Pożarnej. No, a potem to już poszło.

Pamiętasz zadanie, projekt, który dał ci największego boosta motywacyjnego?

Zdecydowanie! Pierwsze projekty, które prowadziłem, dotyczyły kolejnych rozszerzeń funkcjonalnych oprogramowania, nad którym wcześniej pracowałem jako programista. Znałem więc dobrze domenę, klienta no i cały zespół – było relatywnie łatwo. Chcąc rozszerzyć portfolio dostępnych produktów firma, w której pracowałem, wygrała przetarg na zbudowanie i dostawę oprogramowania dla pewnego urzędu miasta – to była zupełnie nowa dziedzina. Szczerze mówiąc… chyba niewiele w tym projekcie zrobiłem dobrze. Projekt oczywiście się nie udał, ale dla mnie była to potężna motywacja do dalszego rozwoju jako project managera.

Jak potoczyła się Twoja ścieżka kariery – gdzie znalazłeś pierwszą pracę jako programista i dlaczego z niej zrezygnowałeś?

To nie tak! Nie zrezygnowałem z mojej pracy jako programista, po prostu w pewnym momencie zajęcia menedżerskie zajmowały mi już tyle czasu, że przestałem kodować. Pracowaliśmy nad systemem wspomagania dowodzenia dla stanowisk kierowania Państwowej Straży Pożarnej. Aplikacja ta była zintegrowana z urządzeniami takimi jak terminale statusów na samochodach, sterowniki bram garażowych, czy centrale telefoniczne i syreny alarmowe w jednostkach. W straży pożarnej dynamika jest bardzo duża, użytkownik nie może klikać “odśwież”, albo czekać na aktualizacje odbywające się co kilkadziesiąt sekund. Wszystko musiało być widoczne na ekranie natychmiast.

Ciekawe wyzwanie, jak je rozwiązaliście?

Potrzebowaliśmy mechanizmu do błyskawicznego przesyłania powiadomień pomiędzy komponentami systemu. W zespole było nas raptem czterech programistów. Jeden z nas, zajmował się pisaniem czegoś takiego, ale widzieliśmy, że postęp prac jest mizerny, słyszeliśmy tylko, że “tego się nie da napisać w miesiąc albo dwa”. Tyle tylko, że z innym kolegą uważaliśmy, że to jest do zrobienia w raptem kilka godzin. No więc w czasach kiedy jeszcze mało kto znał słowo “hackathon” zrobiliśmy go sobie we dwójkę. Kupiliśmy pizzę, kilka piw i wieczorem, kiedy biuro było już puste, usiedliśmy do roboty.

Następnego dnia rano, kiedy ludzie przyszli do pracy zobaczyli, na swoich monitorach kartki “nie dotykać”. To były testy obciążeniowe naszego systemu powiadomień, który po kilku rozbudowach służył niezawodnie w straży jeszcze przez wiele lat. Jakoś tak naturalnie stałem się frontmanem całej tej afery, szef, chociaż niezbyt zadowolony z mojej oddolnej inicjatywy, zobaczył potencjał menedżerski i wystartował karierę, która trwa do dziś.

Gdyby nie ta historia – Twoja ścieżka kariery potoczyłaby się inaczej?

Nie sądzę. W IT wspaniałe jest to, że dla Twojej kariery nie mają znaczenia koneksje, zamożność, szczęście, kolor skóry czy płeć. Liczy się, co potrafisz, liczy się Twoje zaangażowanie, kreatywność i ciągły rozwój. Tak, robię to co lubię, robię to, o czym kiedyś marzyłem i nadal chcę się tym zajmować. Ale to nie przypadek czy pochodzenie – to efekt ciężkiej i konsekwentnej pracy. Ważne jest, aby oddzielić pracę zawodową od własnego rozwoju. W Ellie Mae przykładamy dużą wagę do tego.

Z jednej strony, oczywiście robimy co w naszej mocy, aby dostarczać najlepsze w swojej klasie, funkcjonalne, niezawodne i bezpieczne produkty dla naszych klientów. Z drugiej staramy się zapewnić każdemu członkowi zespołu przestrzeń do wzrostu w wybranym kierunku oraz intensywnie ten wzrost wspieramy. Nie działa to tak, że menedżer decyduje za Ciebie – każdy musi sam się określić, jaką ścieżką kariery chce podążać i każdy sam musi wykazać się determinacją, by robić w tym postępy – firma zaś tę drogę wspiera.

Czym zajmowałeś się, pracując w sektorze Public, a czym w sektorze B2B?

Moja przygoda z sektorem Public dotyczyła głównie, choć nie tylko, bezpieczeństwa publicznego. Pracowałem głównie ze Strażą Pożarną, Pogotowiem Ratunkowym, Policją, Centrami Powiadamiania Ratunkowego. Skupiałem się przede wszystkim na wyspecyfikowaniu wymagań użytkownika, zaproponowaniu rozwiązania i koordynowaniu prac zespołu inżynierskiego, aby produkt został dostarczony zgodnie z harmonogramem. Z czasem do naszego świata wkradło się coraz to więcej ograniczeń formalnych, a co gorsza polityka. Wtedy powiedziałem dość – chciałem i nadal chcę, budować produkty, które czynią świat lepszym, a nie politykować.

Przeszedłem więc do sektora B2B, gdzie odnalazłem utracony w Publicu świat. Klient B2B, zwłaszcza zagraniczny, gotów jest wydać dużo, poczekać długo, zaangażować swoje zasoby i zaakceptować zmianę, jeżeli tylko korzyści płynące z wdrożenia finalnego produktu przewyższą poniesione koszty. Przez lata moja rola bardzo ewoluowała, nie tylko dlatego, że otoczenie bardzo się zmieniło, ale też dlatego, że ja chyba trochę dorosłem. Dzisiaj wolę o sobie mówić leader, servant leader, albo po prostu sługa. Dzielę się tym, co mam, czyli wysokopoziomowym zrozumieniem problemu, pomagam usuwać przeszkody, motywuję, czasem nieco podnoszę poprzeczkę, aby zachęcić do niesztampowego myślenia. Ale głównie to obserwuję, jak świetne, samoorganizujące się, autonomiczne zespoły robią swoją robotę.

Jakie kroki podejmujesz, by wysokopoziomo zrozumieć problem? To kwestia zadania odpowiednich pytań, czy odpowiedniej ilości czasu?

Myślę, że jedno i drugie, dodatkowo dodałbym doświadczenie. Tak jak często klientowi wydaje się, że zna rozwiązanie, potrzebuje tylko programistów, żeby je zakodowali, tak my, inżynierowie, często zbyt wcześnie uważamy, że lepiej rozumiemy, czego naprawdę potrzeba. W rzeczywistości dobre zrozumienie rzeczywistych potrzeb klienta oraz znalezienie najlepszego rozwiązania to ciężka praca wymagająca wysoko wykwalifikowanych specjalistów.

Mam szczęście współpracować w tym obszarze z wybitnymi fachowcami tworzącymi nasz zespół Product Managerów. Co ciekawe, część tego zespołu zlokalizowana jest w Stanach Zjednoczonych, a część w Polsce. W Stanach są nasi eksperci domenowi oraz Product Menedżerowie blisko współpracujący z klientami. Natomiast tu na miejscu w Bielsku-Białej PMowie wspierają nas w przekształceniu wizji w działający produkt. Przyznam, że dzisiaj wysokopoziomowy obraz dostaję praktycznie na tacy od Product Managementu, nie wymaga to specjalnego wysiłku z mojej strony.

Pracowałeś zarówno w startupie, jak i korporacji – co podobało Ci się w tego typu organizacjach?

Moja przygoda ze startupem rozpoczęła się w PerfectGym. Gdy dołączyłem, cały zespół liczył ledwie kilkanaście osób, dziś to już inna, duża i dojrzała organizacja. Startup z dobrą kulturą, a takim moim zdaniem był wtedy PerfectGym, jest środowiskiem niezwykle kreatywnym. W startupie, jeśli tylko masz pomysły i odwagę je realizować – prawie nie ma ograniczeń, nie istnieje coś takiego jak za duże ryzyko, jeżeli tylko gra jest warta świeczki. Nie ma zbędnych (a czasem nawet niezbędnych!) procedur ani formalizmów. Nie da się czegoś zrobić za szybko. Dobrze to obrazuje odpowiedź mojego ówczesnego szefa na informacje ode mnie, że wszystko mam pod kontrolą: “Marek, jeśli wszystko masz pod kontrolą, to znaczy, że jedziemy za wolno”.

Są jednak i koszty takiego stylu, których nie ma w organizacji takiej jak Ellie Mae, to przede wszystkim work-life balance, poczucie stabilności i przewidywalności. Tutaj mam ogromne wsparcie innych działów, których w startupie w ogóle nie ma. Wreszcie start-up jest skoncentrowany na utrzymaniu się na rynku, tam trwa ciągła walka, a każdy pracownik jest żołnierzem, od którego oczekuje się gotowości do poświęcenia za firmę. W Ellie Mae pracownik to kapitał, o który się dba, w który się inwestuje i którym się nie chce nadmiernie ryzykować.

Nie da się ukryć, że słowo “zmiana” często występowała w Twoim przypadku. Z programisty szybko zostałeś managerem – z perspektywy dzisiejszej nie dokonałbyś tak szybkiej zmiany?

Chyba ostatecznie wyszło na dobre… A tak poważnie to nie wiem, trudne pytanie. Programowanie zawsze mnie bawiło, to taka przygoda intelektualna, trochę jak szachy, tylko znacznie bardziej złożona no i z perspektywy świata – szachy to marnotrawienie energii, a programiści budują coś, co ma wartość dla społeczeństwa. Myślę, że wystarczająco dużo programowałem, by dobrze rozumieć programistów, ich problemy i wyzwania. Nie sądzę, bym był lepszym menedżerem gdybym spędził kilka lat więcej jako programista.

“Coś, co ma wartość dla społeczeństwa” – to ładnie brzmiące słowa, ale dla wielu programistów… nierealne. Ta branża, według wielu, przesiąknięta jest nudnymi projektami. Co zrobić w sytuacji, gdy firma, w której pracuje, podejmuje się nudnego projektu?

Nie wiem, nigdy nie pracowałem przy nudnym projekcie. Kiedy porzuciłem pracę nad systemami wsparcia dowodzenia dla służb, na rzecz pracy dla systemów do zarządzania klubami fitness, wydawało mi się, że będzie nudno, ale nie było. Systemy dla banków też mogą wydawać się nudne, ale bardzo bym się zdziwił, gdyby ktoś z zespołu powiedział dzisiaj, że ma nudną pracę. Myślę, że to w dużym stopniu kwestia organizacji pracy, pozwolenia zespołom wzięcia odpowiedzialności za dostarczenie wartości biznesowej i podzielenia się z każdym pracownikiem naszą misją.

Prawdziwie zwinne zespoły się nie nudzą, ponieważ zawsze stawiają sobie cele, podnoszą poprzeczkę, czy wreszcie rozumieją jaką wartość ma to co robią. Czy posprzątanie logowania może być nudne? Pewnie tak, ale jeżeli dzięki wysokiej jakości logów, Twoi dobrzy koledzy z grupy SRE mogą spać spokojnie, bo nie budzą ich fałszywe alarmy – to już wyzwanie dla najlepszych! To trochę jak z przypowieścią o sprzątaczu myjącym podłogi w centrum sterowania na Cape Canaveral, który zapytany o to co robi, odpowiedział “pomagam wysyłać ludzi w kosmos”. Czy wysyłanie ludzi w kosmos może być nudne? A codziennie mycie tego samego skrawka podłogi? To część naszej, liderów, pracy, tak prowadzić zespoły, aby nie popadały w monotonię czy rutynę. Hmm… myślę, że nie ma nudnych projektów.

Opowiedz o tym, czym się dzisiaj zajmujesz.

Wraz ze wzrostem wielkości zespołu ilość zadań, którymi bezpośrednio zajmuje się lider, powinna spadać, bo i bez stałych obowiązków zawsze jest co robić. Dzisiaj przy Analyzerach projekcie, za który odpowiadam, pracuje ponad 40 osób, z czego samych tylko programistów jest prawie 30. Głęboko wierzę, że najlepsze zespoły są multidyscyplinarne, dobrze zmotywowane, autonomiczne i samodzielnie decydujące o swoim produkcie. Moim nadrzędnym celem jest dbanie o taką właśnie kulturę pracy.

To niezwykle trudne wyzwanie, bo przecież zespoły nie działają w próżni, a w praktyce każdy z nich dostarcza tylko komponent, składający się na większą całość. Jeśli miałbym w jednym zdaniu podsumować, czym się zajmuję, to poszukiwaniem złotego środka pomiędzy autonomią zespołów a spójnością docelowego produktu i większej organizacji, no i implementowaniem w praktyce kolejnych przybliżeń tego balansu.

Z jakimi wyzwaniami borykają się Program Managerzy?

W Ellie Mae tworzymy produkty dla jednej konkretnej branży, oczywiste jest więc, że wszystkie nasze produkty mniej lub bardziej są ze sobą powiązane. Pracują przy nich dziesiątki zespołów inżynierów. Jak łatwo sobie wyobrazić, w takim środowisku bardzo łatwo jest ugrząźć w “dependency hell”, czyli sytuacji kiedy przez kolejne tygodnie prace posuwają się bardzo wolno, lub wręcz wcale, ponieważ zespoły są zblokowane poprzez wzajemne zależności.

Program Manager opiekuje się właśnie programami, czyli takimi “nadprojektami” i na dobrą sprawę, nie robi nic innego, jak tylko zbiera i udostępnia w czytelnej formie informacje o programie. Upewnia się, że wszyscy zaangażowani w projekt, nie tylko rozumieją swoją rolę, ale też cały program od ogółu do szczegółu i z powrotem. To doskonale współgra z autonomią zespołów – tylko zespół, który rozumie cały kontekst zadania, gwarantuje sukces jego realizacji.

Jak zdobyte wcześniej doświadczenia wykorzystujesz w pracy?

Tak jak nie ma na świecie dwóch takich samych osób, tak w IT nie ma dwóch identycznych zespołów, projektów, organizacji, produktów czy problemów. Rozwiązanie, które zadziałało w jednym przypadku, nie musi zadziałać w innym i vice versa. To nie jest powtarzalna praca, ale oczywiście to nie oznacza, że doświadczenie się nie przydaje. Z każdym rokiem nabywam coraz większego szacunku do moich koleżanek i kolegów, oraz coraz większego dystansu do samego siebie, swojej wiedzy i umiejętności. Kolejne doświadczenia, poznani ludzie czy zrealizowane projekty poszerzają mój warsztat, ale też jeszcze bardziej otwierają mnie na to co inni mają do powiedzenia.

Nie boję się popełniać błędów, tak wiele popełniam ich każdego dnia, że chyba bym oszalał gdybym się tym przejmował, po prostu się na nich uczę. Czasem celowo naprowadzam moich mniej doświadczonych współpracowników na ślepą ścieżkę, bo umiejętność popełniania błędów, radzenia sobie z nimi i wyciągania wniosków jest nie do przecenienia.

Dużo mówi się o kulturze pracy – opowiedz o tym, w jakiej kulturze pracujesz ze swoimi zespołami.

Po pierwsze nie mogę zgodzić się z tak sformułowanym pytaniem! To nie zespoły są moje, to ja jestem zespołów. Nie jesteśmy organizacją oparta o zarządzenie typu comand and control – wręcz przeciwnie. Nie wydajemy poleceń, tylko wyznaczamy cele. Nie kontrolujemy – tylko upewniamy się, że zespoły mają pełne zrozumienie celów i nie przeszkadzają im zbędne ograniczenia. Dla kogoś, kto ma doświadczenie z klasycznym modelem zarządzania w IT, jest to wprost nie do wiary jak kreatywne, skuteczne i wydajne potrafią być autonomiczne zespoły, gdy zapewni im się przyjazne dla nich środowisko.

Kiedyś, w innej organizacji udało nam się namówić zarząd, żeby zorganizować hackathon. Później, szefowie wprost nie mogli uwierzyć jakie cuda w zaledwie 24 godziny stworzyły ich zespoły, te same zespoły, które na co dzień ich zdaniem działają tak wolno. Wystarczyło usunąć menedżerów! Servant leadership opiera się właśnie na tym spostrzeżeniu, tyle że nie pracujemy 24 godziny bez ustanku.

Co zmieniło się w tej kulturze przez wymóg pracy zdalnej?

Budując nasze biuro w Bielsku, ogromną uwagę przykładaliśmy do relacji międzyludzkich. Myślę, że udało nam się stworzyć fajne miejsce pracy, gdzie spędzaliśmy czas z ogromną przyjemnością. Nie da się przy użyciu Slacka czy Zooma odtworzyć choćby namiastki atmosfery pogawędki przy kawie w kuchni, grilla na naszym tarasie, czy wspólnego lunchu w knajpce obok biura. Oprócz budowy więzi między nami, to wszystko sprzyjało także wymianie informacji. Bardzo za tym tęsknimy.

Przecięcie tych kanałów komunikacyjnych zmusiło nas do zastąpienia ich dodatkowymi spotkaniami. Tak więc powiedziałbym, że główne zmiany dotyczą większej liczby spotkań i trochę mniej radości z pracy. Nie mogę się doczekać, kiedy znów będziemy mogli otworzyć nasze biuro, i mam nadzieję, że nawet najzagorzalsi zwolennicy pracy zdalnej, zaglądną do niego od czasu do czasu, żeby nacieszyć się byciem razem.

Czym kierujesz się, szukając kolejnej osoby do zespołu?

Mam bardzo proste zasady. Jeśli chodzi o wiedzę merytoryczną i doświadczenie całkowicie polegam na opinii moich koleżanek i kolegów, którzy realizują podobne funkcje do tej, na którą rekrutujemy. Jeżeli oni mówią “nie”, z jakiegokolwiek powodu, to jest to koniec rekrutacji, nigdy nie podważam tej decyzji. Ja sprawdzam tylko “kryterium piwa” – prowadzę z kandydatem luźną konwersację, jeżeli po niej mam ochotę pójść z kandydatem na piwo i rozmawiać dalej – to jestem na tak, w przeciwnym wypadku decyzja jest negatywna. Dziś mamy fantastyczną atmosferę w zespole, nie wybaczyłbym sobie gdybyśmy ją popsuli.

Marek Mach. Director, Engineering w Ellie Mae. Lider zespołów deweloperskich z solidnym backgroundem technicznym. Promotor silnych autonomicznych zespołów, pasjonat technik zwinnych, szukania ich własnej implementacji i eksperymentowania z nimi. Żeglarz, narciarz, kolarz szosowy i MTB, lubi odpłynąć z dobrą książką w ręce i muzyką w słuchawkach.

Oferty pracy z