– Nie mówimy o tym za często, ale prawda jest taka, iż to ryzykowne przedsięwzięcie. Startup ma w założeniu przynieść duże zyski tym, którzy w niego inwestują. Jest to inwestycja obarczona dużym ryzykiem – powiedział nam Mateusz Gostański, Senior Software Engineer w Alokai.
Jak z perspektywy doświadczonego inżyniera wygląda praca w startupie? Dlaczego – mimo wielu ryzyk – seniorzy wybierają startupy? Tego dowiecie się z naszej rozmowy.
Jak myślisz, dlaczego sporo inżynierów z wieloletnim doświadczeniem wybiera pracę w startupie?
Powodów, moim zdaniem, jest przynajmniej kilka. Od strony technologicznej startupy są bardzo kuszące, ponieważ używają najnowszych technologii. Niezwykle często są to popularne technologie open-source. Da się tu również znaleźć pierwsze (lub jedne z pierwszych) zastosowanie frameworków, które zyskują popularność. jeżeli ktoś szuka świeżości technologicznej, bo siedzi w jakimś projekcie legacy lub siedzi tak długo w projekcie, iż on staje się legacy, przynajmniej pod względem stacku — to jest to wręcz naturalny wybór.
Co więcej, startupy pozwalają bardzo gwałtownie się rozwinąć. Jest takie powiedzenie, iż rok w startupie, to jak 3 lata w tradycyjnej firmie. Dynamika zmian, rozwoju, wszelakich pivotów jest naprawdę spora. Startup, który chwyci, będzie rósł także osobowo — to szansa dla seniorów, którzy chcą iść w Tech Leada lub Engineering Managera. Tak więc to jest kolejny czynnik — jeżeli szukamy rozwoju i dynamiki.
Następny czynnik to podejście do work life balance i niecodzienne benefity. Myślę, iż numerem jeden jest tutaj tzw. Unlimited PTO — czyli nielimitowany urlop. Większość moich znajomych, gdy słyszą o tej polityce rozumie ją jako nielimitowany bezpłatny urlop. Nie mogą uwierzyć w to, iż taka polityka naprawdę istnieje i można mieć więcej niż 20/26 dni urlopu w roku lub płatne chorobowe przy umowie B2B. W startupach to możliwe — Alokai jest tutaj świetnym przykładem, iż można taką politykę wprowadzić i ona zdaje egzamin.
Tylko w startupie mamy przestrzeń, swobodę wyboru najnowszych technologii?
Taką swobodę mamy w każdym greenfieldowym projekcie — on nie zawsze musi być startupem. Nieraz zdarza się, iż przepisujemy system legacy na nowy stack lub budujemy produkt na bazie doświadczeń z poprzedniego. Wtedy zespół, który zaczyna taki projekt, często ma swobodę decydowania o wielu składnikach stosu technologicznego. Jednak to start-upy stanowią dużą część tych greenfieldowych przedsięwzięć.
Oczywiście w grę wchodzą też inne czynniki takie jak architektura. W jej skład wchodzą możliwości, umiejętności i predyspozycje zespołu, zarówno obecnego, jak i przyszłego, czyli możliwości zatrudnienia deweloperów w określonym stacku. Nie ma sensu budować backendu w Rust czy Go, jeżeli nie potrzebujemy super wydajności, ponieważ znacznie trudniej będzie znaleźć nam deweloperów w tym języku. To widać na rynku, gdzie do startupów szuka się najczęściej JavaScript/TypeScript deweloperów — bo jednak to frameworki, narzędzia i całe stacki w tych językach pozwalają na szybką iterację i budowanie MVP.
Da się w jakiś sposób przygotować do pracy w startupie? Do czego porównałbyś pracę w takiego rodzaju firmie?
W pewnym stopniu na pewno – moim zdaniem pomaga tutaj wiedza z zakresu strategicznego DDD. Startupy często szukają najlepszego rozwiązania dla swoich klientów. Znajomość narzędzi, warsztatów, różnych wzorców architektonicznych pozwoli uniknąć, z jednej strony budowania czegoś w określony sposób tylko dlatego, iż jest popularny, czy znany dla nas, a z drugiej zbudowania takiej architektury, iż aplikacja stanie się nierozwijalna po pewnym czasie, ponieważ nie uwzględniliśmy potrzeb biznesu czy po prostu skalowalności.
Prowadzenie warsztatów takich jak Big Picture Event Storming jest bardzo pomocne. Szczególnie gdy startup zaczyna rosnąć, ludzi przybywa i trzeba dobrze zdefiniować produkt, jego core’owe i wspierające domeny. Trzeba też jasno powiedzieć sobie, czego nie warto robić. Które domeny są generyczne i jakich rozwiązań na rynku jest kilka.
Także zrozumienie konceptu Bounded Contextu, tego, jakie formy współpracy mamy pomiędzy nimi, jak to się przekłada na rzeczywistą współpracę między zespołami, bardzo pomaga odnaleźć się w startupie, który już działa od pewnego czasu i ma dosyć spory zespół deweloperski. Doświadczyłem tego dołączając do Alokai (wtedy jeszcze VueStorefront). Dzięki mappingowi całego produktu na Bounded Contexty i określonych rodzajów współpracy, o wiele łatwiej było zrozumieć zależności pomiędzy zespołami. Było to ważne, bo trafiłem do nowego tworzonego zespołu, który miał iterować nad kolejną wersją naszego produktu.
Uważasz, iż praca w startupie wiąże się z ryzykiem? Nie zaliczasz startupów do stabilnych miejsc pracy?
Nie mówimy o tym za często, ale prawda jest taka, iż to ryzykowne przedsięwzięcie. Startup ma w założeniu przynieść duże zyski tym, którzy w niego inwestują. Jest to inwestycja obarczona dużym ryzykiem. Wchodząc do takiej firmy, musimy o tym pamiętać. Jednak często jesteśmy bardzo zafascynowani dobrymi rzeczami — nowoczesnym stackiem, w którym zawsze chcieliśmy pracować, swobodą, elastycznością, fajnym teamem, dynamiczną atmosferą itd., więc naturalnie bardzo łatwo zapomnieć o tym, iż to ryzykowna gra.
Inwestorzy w start-upach mają wpływ na decyzje CEO i choćby on chciał nieraz utrzymać wszystkich na pokładzie — to musi zrobić cięcia i wtedy pojawiają się layoffy. Nie są one tak dramatyczne liczbowo, jak w przypadku FAANG, ale przez cały czas dotyka to życia prawdziwych ludzi, naszych kolegów a może i nas samych. Doświadczyłem tego w dwóch ostatnich firmach, choć różniły się wielkością zespołów deweloperskich, typem produktu, źródłem finansowania — to niestety popandemiczny kryzys ekonomiczny dał się odczuć w roku 2022 i 2023.
Nie jest to reguła, iż teraz każdy startup jest obarczony ogromnym ryzykiem i najlepiej do niego nie wchodzić — byłbym hipokrytą, bo sam pracuje w startupie (no w sumie do Alokai bardziej pasuje określenie scaleup w tym momencie, ale niech będzie). Moim zdaniem, należy to dokładnie rozważyć i świadomie do tego podejść.
Przykład FAANG pokazuje też, iż również wielkie firmy typu Enterprise mogą mieć problemy i stać się niestabilne. Jednak dotyczy ich taka sama zasada. To logiczne, iż firmy, które w trakcie pandemii podwoiły personel IT, będą go redukować, gdy podaż, zapotrzebowanie, i co najważniejsze, zyski zaczęły spadać. Zatem to ogólna reguła, aby sprawdzać sytuację finansową firmy, do której się rekrutujemy.
Domyślam się zatem, iż już podczas etapu rekrutacji zwracasz uwagę na sposób finansowania firmy, do której aplikujesz. O co dokładnie pytasz?
To zależy. Moim zdaniem tego rodzaju pytania, są bardzo różnie odbierane przez rekruterów. Niektórzy z nich, sami szczerze i otwarcie omawiają sytuację firmy już na etapie pierwszej rozmowy tzw. screeningu. Mówią np. iż to świeży startup albo, w której turze finansowania w tej chwili się znajduje. Wtedy warto dopytać o runway — czyli na ile miesięcy mamy jeszcze kasy, żeby firma funkcjonowała tak, jak to jest aktualnie bez zmiany przychodów.
Czasami jednak trafiamy do firmy, która sprzedaje jakiś produkt i odpala teraz coś dodatkowego, kolejny produkt lub chce „zaktualizować” swój produkt legacy. Wtedy zwykle finansowanie jest własne lub niejawne — wobec czego pytanie o stabilność finansową może być źle odebrane przez rekrutera lub dostaniemy bardzo ogólną odpowiedź. Lepiej wtedy zapytać ilu mamy klientów, którzy korzystają z produktu, jak duży jest to rynek, jakie są oczekiwania wzrostu sprzedaży itd. To pokaże, jakie są plany sprzedażowe, jakie jest ciśnienie wewnątrz firmy na budowanie zysku z produktu. jeżeli deadline-y są bardzo napięte albo oczekiwania wydają się nierealne — to może być dla nas red flag, iż zespół może być gwałtownie zawinięty lub będziemy pracować pod olbrzymią presją.
Warto też wykorzystać pewne aspekty prawne. jeżeli firma jest spółką kapitałową, to musi składać sprawozdania finansowe. Dostęp do tych sprawozdań jest możliwy na różnych portalach specjalizujących się w tej materii. Możemy zobaczyć, jaka jest sytuacja finansowa spółki. To samo dotyczy spółek osobowych oraz firm, które przekraczają 2 mln euro przychodu.
Na co jeszcze zwróciłbyś uwagę wybierając nowy startup, w którym będziesz pracować? Co jeszcze pracownik jest w stanie zweryfikować, by poczuć, iż podejmuje bezpieczną decyzję?
Na pewno dobrym ruchem jest dobre poznanie domeny biznesowej, warto spróbować dopytać, jak duży to rynek, poświęcić czas na research tego obszaru – to pomoże nam też dobrze wypaść na rozmowie.
Kolejną kwestią jest struktura zespołu. Zarówno deweloperskiego, jak i całej firmy. Odpowiedź na te kwestie pokaże nam jak dobrze jest zorganizowane przedsięwzięcie. To jak ustrukturyzowane są zespoły (wracając do strategicznego DDD) pokaże nam dojrzałość startupu, a prawdą jest, iż im startup dojrzalszy, tym bardziej jego szanse na sukces rosną. Prawdopodobnie ma też już stabilne dochody.
Czy jest z kolei coś, co warto zabrać ze świata startupów i przenieść do innych firm?
Zdecydowanie warto przynieść dobry work life balance, swobodę, elastyczność i zdrowe podejście do wypoczynku. Wiadomo, nie uda się wdrożyć „Unlimited PTO” w każdej firmie, ale zasadniczo mniej ofert „czystego B2B” na pewno byłoby zbawieniem dla wielu.
Inna rzecz, bardziej technologiczna, to wybieranie frameworków, stosów, rozwiązań, które pomagają gwałtownie iterować. W tej materii często zdarza się, iż wchodzimy z za bardzo skomplikowaną technologią do obecnego stanu projektu. Pracowałem w firmie, w której tworzyliśmy nową wersję jednego z produktów sprzedawanych przed laty. Decyzja padła, aby backend pisać w Javie. Mimo iż proces i sposób działania był nastawiony na mocną iteratywność, odkrywanie rynku na nowo, szukanie miejsca na innowacje — to i tak wybrano technologię mocno enterprise’ową. I tak też podchodzili do niej zatrudnieni backend deweloperzy.
Wobec czego to frontend przejmował mnóstwo rzeczy, które klasycznie powinny dziać się na backendzie – po to, aby szybciej dostarczyć funkcjonalność i sprawdzić ją w boju. Potem naturalnym było przejście na wiele serwisów backendowych, w końcu także w innych językach. A można było od początku iść w rozwiązania typu tRPC i działać w jednym monorepo, oszczędzać czas na dogadywanie się między dwoma innymi światami.
Potrafiłbyś określić, czy startup to dobre miejsce dla juniorów?
Trudne pytanie. Szczerze mówiąc – to zależy. Oczywiście, startup to na pewno dobre miejsce dla juniora. Da się dużo nauczyć i to w bardzo szybkim czasie. Kandydat na tym poziomie powinien być tego świadomy i gotowy czasami na niezły rollercoster.
Z drugiej strony, junior w takim dynamicznym środowisku może być utrudnieniem. Seniora można wysłać gdziekolwiek i szanse na zwycięstwo są raczej wysokie. Mając dojrzalszy team na pewno pracuje się wygodniej, szybciej iteruje i prawdopodobieństwo zrobienia czegoś przełomowego rośnie.
Jednakże to kosztuje, a w startupie (i nie tylko) pieniądze są ważne. Więc dobre miksowanie deweloperów na różnym poziomie, może być najlepszym dostępnym rozwiązaniem.
Pracowałem w obu konfiguracjach – będąc jednym seniorem na 6-osobowy zespół, jak w i teamie, gdzie byli wyłącznie seniorzy. Każde z tych rozwiązań ma swoje plusy i minusy. Dobrze wspominam oba te przypadki.
Mateusz Gostański. Senior Software Engineer w Alokai (do niedawna znany jako VueStorefront), entuzjasta technologii, programista od 11 roku życia, lubujący się w architekturze oprogramowania. Naturalny full-stack dev, ostatnio zasiedział się na frontendzie.
