„Jesteśmy rozpędzeni jak nigdy wcześniej” – rozmowa z Tomaszem Rogozikiem
Tomasz Rogozik na co dzień pracuje jako Senior Engineering Manager w polskim oddziale firmy Bolt. Odpowiada on między innymi za zarządzanie zespołami programistów w trzech różnych krajach – w tym w biurze w Warszawie. My postanowiliśmy zapytać Tomasza o to, jak od środka wygląda praca w tak dynamicznym startupie, jak wyglądają plany Bolta na przyszłość oraz jakich cech firma szuka u programistów podczas rekrutacji.
Spis treści
Cześć Tomku. Zacznę bez ogródek. Czy pandemia Was zaskoczyła? Jak COVID odbił się na pracy zespołu i wdrażania samych nowości w przypadku Bolta – we wszystkich segmentach?
Pandemia była dla wszystkich zaskoczeniem, nasz zespół w Bolcie nie był tu wyjątkiem. Na początkowym etapie, gdy nie byliśmy pewni, jak będzie wyglądała przyszłość rynku przewozu osób, podjęliśmy wszelkie możliwe działania, aby mimo wszystko nie zwolnić ani jednej osoby. Nasz zespół docenił ten gest i odwdzięczył się zdwojonymi wysiłkami. Równie ważne było, by znaleźć sposoby, aby także kierowcy współpracujący z platformą mogli utrzymać swoje źródło utrzymania i jednocześnie zapewnić bezpieczny transport osobom, które nie mogły zostać w domach.
Mimo tego, że jesteśmy już dojrzałą organizacją, to zachowaliśmy nasze startupowe podejście do rozwiązywania trudnych sytuacji. Dzięki położeniu dodatkowego nacisku na nowe linie biznesowe – uruchomiliśmy dostawy jedzenia (Bolt Food) i hulajnogi (Bolt Rentals) w Polsce, a w Estonii car-sharing (Bolt Drive). Aktualnie testujemy też koncept dark stores w Tallinie – błyskawiczne dostawy zakupów spożywczych (Bolt Market). Jesteśmy rozpędzeni jak nigdy wcześniej, również pod względem skali i szybkości zatrudniania inżynierów we wszystkich naszych hubach – obecnie mamy otwartą rekrutację na ponad 50 ról w samej inżynierii.
Śmiało mogę powiedzieć, że całkowicie zmieniło się nasze podejście do pracy zdalnej i do sposobu, w jaki formowane są zespoły. Obecnie promujemy model hybrydowy – oczekujemy od pracowników spędzania co najmniej 20% czasu w biurze, ale jesteśmy bardzo elastyczni jeśli chodzi o sposób rozłożenia tego czasu w ramach danego miesiąca. Dzięki temu mogliśmy otworzyć się na zatrudnianie w innych miastach w Polsce, jak Kraków, Gdańsk czy Wrocław.
Z jakiego rozwiązania chmurowego korzysta Bolt i skąd ta decyzja?
Większość infrastruktury Bolta oparta jest o chmurę AWS, wykorzystujemy również elementy chmur Azure oraz GCP. Decyzja o wyborze chmury podyktowana jest wieloma czynnikami: stabilnością, łatwością skalowania, szybkością reakcji na zgłoszenia, elastycznością w dostosowaniu polityki cenowej do naszych potrzeb, łatwością zarządzania poprzez podejście infrastructure as code, ale też ofertą wysoce wyspecjalizowanych usług zarządzanych. Dodatkowo, zwracamy uwagę na wsparcie konkretnych regionów na świecie, mając na uwadze naszą dalszą ekspansję na nowe, czasem bardzo odległe od Warszawy czy Tallina rynki, jak uruchomione w zeszłym roku – Ekwador, Tajlandia, czy Paragwaj.
W jaki sposób pracują inżynierowie w polskim zespole Bolta? Postawiliście na organizację zdalną czy też może inny sposób, który pomaga trzymać projekty w ryzach?
Pracujemy w małych, 3-8 osobowych zespołach, odpowiedzialnych za konkretną domenę, na przykład tożsamość użytkownika, czy też kanały komunikacji z użytkownikami. Każdy zespół ma przypisanych Engineering Managera oraz Product Managera. W większych zespołach tworzymy też rolę Technical Leada. Dbamy o to, by każdy inżynier mógł poczuć się właścicielem jakiegoś fragmentu danej domeny, stać się ekspertem, do którego inni mogą zwrócić się o pomoc. To podejście charakteryzuje całą naszą organizację i pomaga nam w szybkiej i sprawnej pracy.
Jeśli chodzi o pracę zdalną, latem 2020 przeprowadziliśmy badanie wśród 1000 pracowników Bolt. Wykazało ono, że prawie 80% z nas chciałoby pracować z domu co najmniej połowę tygodnia. Analiza obecności w centrali Bolt w Tallinie dodatkowo wskazała, że najwięcej osób przychodzi do biura, by uczestniczyć w spotkaniach firmowych oraz w piątki, by wziąć udział w spotkaniach towarzyskich. To pokazuje, że interakcje z zespołem są najważniejsze. Dlatego zdecydowaliśmy się w Polsce wdrożyć model hybrydowy – tylko 20% zespołu ma stałe miejsca w biurze.
Zespoły bywają rozproszone w wielu miastach, czy nawet krajach – pozostałe huby inżynierskie znajdują się w Estonii oraz Rumunii. Staramy się nie tworzyć sztucznych barier dla formowania zespołów i bardziej zwracamy uwagę na predyspozycje programistów i ich wcześniejsze doświadczenie niż na konkretną lokalizację, gdzie się znajdują – o ile mieszkają w jednym z trzech krajów, gdzie działają nasze huby.
Stawiamy na metodyki zwinne i krótkie iteracje. Zależy nam na jak najszybszej weryfikacji nowych pomysłów, szczególnie jeśli pełna implementacja wymaga współpracy wielu zespołów przez parę miesięcy czy lat. Do weryfikacji naszych hipotez wykorzystujemy testy AB.
Jak wygląda strategia rozwoju na najbliższe miesiące? Domyślam się, że przy tak szybko rosnącej organizacji nie jest łatwo. Financial Times dwa razy z rzędu wymieniał Bolta w pierwszej trójce najszybciej rozwijających się platform w Europie. Planujecie utrzymać takie samo tempo?
Z mojej perspektywy mogę powiedzieć, że plany na rok 2022 są nie mniej ambitne niż wcześniej, szczególnie jeśli chodzi o organizację inżynierską. Hub w Warszawie jest najmłodszy spośród trzech hubów inżynierskich w Bolcie, a to znaczy, że mamy największe pole do popisu, jeśli chodzi o wykorzystanie lokalnych talentów. Planujemy przenosić do Polski utrzymanie i rozwój domen zarówno tzw. platformowych (współdzielonych przez całą firmę), jak i związanych z konkretną aplikacją, czy linią biznesową. Nieustannie tworzymy też nowe domeny-zespoły, co odzwierciedla szybki rozwój całej firmy.
W najbliższym czasie chcielibyśmy zmienić nieco charakter naszych zespołów w Polsce na bardziej interdyscyplinarny. W tym celu m.in. formujemy właśnie lokalną grupę programistów mobilnych (Android, iOS, React Native), co pozwoli naszym zespołom na posiadanie w swych szeregach pełnego mixu: backend, frontend, mobile. Liczymy, że pozytywnie wpłynie to na szybkość prototypowania, a także zminimalizuje zależności od innych zespołów.
Jak wygląda ścieżka rozwoju programisty w zespole? Na co może on liczyć, niezależnie od swojego doświadczenia. Mam wrażenie, że Bolt mocno stawia na transparentność?
Każdy programista może u nas liczyć na sporo wyzwań i dużą dozę samodzielności, niezależnie od poziomu. Żeby zwiększyć transparentność oczekiwań na poszczególnych poziomach wprowadziliśmy parę lat temu macierz kompetencji – opisuje ona, co konkretnie w poszczególnych obszarach osoba na danym poziomie powinna robić, jak bardzo być samodzielna i jakiego rodzaju inicjatywy podejmować. To właśnie zapał do pracy, weryfikacja z macierzą kompetencji i historia dostarczonych funkcji systemu są podstawą do rozmowy o awansie na wyższe stanowisko, a nie historia zatrudnienia z poprzednich firm. Dzięki tej przejrzystości każdy może sam, lub ze swoim managerem, zweryfikować nad czym w najbliższym czasie popracować, albo w jakiego rodzaju inicjatywach wziąć udział.
Jeśli chodzi o same poziomy, wydaje się, że są one spójne ze standardami w branży: Junior, Mid, Senior, Staff, Senior Staff, Principal. Począwszy od stanowiska Senior programiści mogą spróbować swoich sił w roli Technical Leada, a jeśli zarządzanie ludźmi jest czymś, co ich interesuje – Engineering Managera. Tym samym mogą wkroczyć na niezależną ścieżkę menedżerską, dla której przygotowane są inne wyzwania i oczekiwania.
Jakich cech poszukujecie u programistów? Czym można się wyróżnić na rozmowie?
Szukamy utalentowanych inżynierów, którym niestraszne jest poznawanie nowych technologii, czy praca z dużą skalą ruchu. Cechy, na które zwracamy uwagę, to np. zorientowanie na klienta końcowego, myślenie produktowe, inicjatywa, ale też chęć podejmowania odpowiedzialności za swój komponent, serwis, czy domenę.
Niemniej ważne są oczywiście umiejętności techniczne. W przypadku backendu, przydaje się wcześniejsze doświadczenie z systemami rozproszonymi, a przynajmniej z teorią za nimi stojącą. Nie wymagamy doświadczenia z konkretnym językiem programowania, czy używanymi przez nas bazami danych. Szukamy osób, które dzięki swojemu błyskotliwemu umysłowi i wsparciu innych koleżanek i kolegów z zespołu, będą w stanie wgryźć się w każdy problem i znaleźć rozwiązanie.
W przypadku programistów frontendowych liczymy również na znajomość przynajmniej jednego ze współczesnych frameworków frontendowych (np. React), a w przypadku programistów mobilnych – znajomości danej platformy (iOS, Android, czy React Native).
Zawsze też trzeba mieć w pamięci to, jaką organizacją jest Bolt – doświadczenie zawodowe jest ważne, ale tak naprawdę szukamy wewnętrznej motywacji, inteligencji i uczciwości. Innymi słowy, ludzi, którzy szybko się uczą i troszczą się o otoczenie. Skupiamy się na tym, kim może się stać dana osoba, a nie tylko na tym, co zrobiła w przeszłości.
Jak wygląda Twój typowy dzień w pracy?
Zanim o nim opowiem, chcę zaznaczyć, że mój typowy dzień w pracy absolutnie nie odzwierciedla typowego dnia programisty w Bolcie. Każda rola ma swoją specyfikę i w moim przypadku nie jest inaczej.
Zaczynam od porannego bloku na tzw. focus time. To zwykle 1,5 godz. gdy mogę nieprzerwanie popracować nad jednym lub dwoma tematami z mojego backlogu. Zwykle dotyczą one zmian wprowadzanych w mojej organizacji, planowania rozwoju zespołów, planowania sukcesji, śledzenia budżetu, czy wspomagania naszych rekruterów w sourcingu dobrych kandydatów.
Po tym spędzam zwykle 30 minut na sprawdzeniu Slacka i odpisaniu na najbardziej pilne tematy. Następnie zaczynam blok spotkań 1:1 – zazwyczaj są to – jedna osoba dziennie z mojego bezpośredniego zespołu managerów, jeden Product Manager z zaprzyjaźnionych organizacji, 1-2 spotkania z programistami (odbywają się dla nich co parę tygodni, a raz w tygodniu z ich bezpośrednim managerem), czasem jedno spotkanie z partnerami z organizacji wspierających – People Partnerem czy administracją biura.
Aby złapać chwilę oddechu kolejne pół godziny spędzam na lunchu – często w biurowej kuchni, bo wtedy mam świetną okazję na nieformalne rozmowy zarówno z inżynierami, jak i pracownikami innych działów. Po lunchu zwykle sprawdzam newsy z branży, czy zerkam na aktualny status naszych rekrutacji. Tuż po – pół godziny do godziny na odpowiedzenie na pytania i palące problemy na Slacku.
Następnie w zależności od dnia, albo biorę udział w cotygodniowym spotkaniu jednej z grup tematycznych, do których należę (zespoły platformowe, rekrutacja, polskie biuro), albo znów mam chwilę skupienia na zadaniach z mojego backlogu.
Gdzieś na końcu dnia spędzam 1,5 godziny na przeprowadzeniu rozmowy kwalifikacyjnej z ostatniej rundy rozmów, kiedy to testuję umiejętności projektowania systemów (tzw. system design), ale też rozmawiam o ciekawych sytuacjach, z którymi zmierzyli się nasi kandydaci u poprzednich pracodawców.
Ostatni rzut oka na Slacka, przygotowanie listy zadań na kolejny dzień i mogę z satysfakcją zamknąć komputer.
Gdzie polski zespół Bolta chciałby być za dwa lata od dnia dzisiejszego?
Chcielibyśmy urosnąć 2-3 razy w stosunku do obecnego rozmiaru (30 osób) i móc zaoferować stanowiska z pełnego spektrum naszej organizacji: od SRE, administratorów baz danych, przez backend, frontend, inżynierów danych, inżynierów ML, data science, po programistów mobilnych i designerów. Pozwoli to naszym inżynierom rozwijać się bez ograniczeń, jak i zmieniać zespoły w zależności od zainteresowań czy chęci sprawdzenia się w nowej roli. Liczę również na to, że mocno związana z inżynierią organizacja produktowa rozwinie swoje skrzydła w Polsce.
Jak Twoje doświadczenie związane z zarządzaniem architekturą pomaga w pracy w startupie?
Bolt jest startupem już chyba tylko z nazwy, globalnie zatrudniamy ponad 300 inżynierów w ponad 50 różnych zespołach i jest to skala, która wymusza myślenie o globalnej architekturze wszystkich naszych usług. Wcześniejsze doświadczenie z chmurami, znajomość dostępnych rozwiązań, dobrych praktyk, wzorców i metod optymalizacji kosztowych pozwala mi służyć dobrą radą zespołom w mojej grupie. Ułatwia mi to też dialog z zespołami infrastrukturalnymi (np SRE), gdy posiadanie tego technicznego kontekstu pomaga odpowiednio zrozumieć i priorytetyzować problemy.
Ostatnie pytanie może być nieco niewygodne, ale pozwolę je sobie zadać. Jak Bolt podchodzi do kwestii długu technologicznego i w jaki sposób firma rozwiązuje tego typu problem?
Dług technologiczny to realny problem w startupach, ale myślę, że mamy go pod całkiem niezłą kontrolą. Każdy zespół inżynierski w Bolcie co kwartał bierze udział w globalnym planowaniu, gdzie dyskutowane są zależności pomiędzy zespołami, priorytety wyznaczone przez rozwój produktu, ale też i projekty inżynierskie, np. aby rozwiązać problemy ze skalowaniem, lub właśnie spłacić dług technologiczny. Ten ostatni śledzimy jako odpowiednio oznaczone zadania w backlogu. Zazwyczaj stosujemy podział czasu na 80% nowych funkcjonalności oraz 20% stabilizacji, czyli naprawianie błędów, spłacanie długu technologicznego, czy refaktoring. Jest to jednak wyłącznie domyślna zasada – zespoły na starcie nowego produktu czy prototypujące nowe rozwiązania mogą przeznaczyć na nie większą część czasu, jednocześnie godząc się na dedykowanie więcej czasu na stabilizację w kolejnych kwartałach. Nawet gdy budujemy MVP dla nowych linii biznesowych, robimy to w sposób umożliwiający ich naturalne rozszerzanie w przyszłości – nigdy nie są to projekty do wyrzucenia.
Dzięki za odpowiedzi na pytania i poświęcony czas! 🙂