Używamy Miro do budowania Miro. Wywiad z Marcinem Pająkiem

Marcin Pająk od ponad trzech lat pracuje w Miro, m.in. w zespole odpowiedzialnym za accessibility. Zapytaliśmy go o to, jak wygląda praca w tak dużej organizacji, ale też o to, co zaważyło na tym, że wybrano właśnie jego kandydaturę.

Kiedy aplikował do Miro, firma była w czasie hiperwzrostu. Mimo to bardzo przykładała się do procesu rekrutacji, który składał się aż z siedmiu etapów. Marcin wypadł szczególnie dobrze na jednym z nich – product interview. – Miał on za zadanie potwierdzić, że wiem jak moja praca rozwiązuje konkretne problemy użytkowników i jak to wpływa na biznes, jak mierzyć sukces moich projektów i jak efektywnie współpracować z product managerem – powiedział Marcin Pająk, Staff Software Engineer w Miro.

Jeśli chciałbyś dowiedzieć się, jak z jego perspektywy wygląda praca w Miro – zachęcam do przeczytania tej rozmowy.

Jakbyś opisał kulturę pracy w Miro?

Miro to firma, która przeszła kilka etapów rozwoju w bardzo krótkim odstępie czasu. Od startupu z 250 pracownikami jeszcze na początku 2020 roku, do potężnego scale-upu z prawie 2000 osobami na pokładzie i ponad 70 milionami użytkowników. Tak wielkie zmiany wymusiły też szybką ewolucję kultury, którą mogłem obserwować od grudnia 2020 roku, kiedy zacząłem pracę w Miro.

Kultura to dla mnie bardzo ważny aspekt pracy, ale też dość wielowymiarowy temat. Możemy przecież rozmawiać o kulturze w kontekście pracy w zespole, pomiędzy zespołami, a nawet o kulturze pracy związanej z kodem, code review, dokumentacją i jakością. Kultura to tak naprawdę to, co firma robi, a nie mówi. Niemniej, w dużych organizacjach, takich jak Miro, niezbędne jest jej aktywne formowanie i propagowanie do wszystkich zespołów. Jednym ze sposobów takiego modelowania jest zdefiniowanie ogólnych wartości i wzorców zachowań oraz uwzględnianie ich w procesach, takich jak performance review, celach firmowych i osobistych oraz komunikacji przez leadership.

Jedną z naszych czterech głównych wartości jest “Play as a team to win the world”. Pomaga ona zrozumieć wszystkim pracownikom, że jako zespół osiągamy zawsze lepsze wyniki niż “grając” samemu. Budujemy produkt wspomagający pracę innych, i żeby móc to robić, sami najpierw musieliśmy nauczyć się dobrze współpracować ze sobą.

Mamy kilka głównych hubów, część zespołów (w tym moje) jest rozproszona po Europie, a po kilku przejęciach innych firm teraz również po Stanach, więc coraz większą rolę odgrywa praca w formie asynchronicznej. Osobiście bardzo mi ten model odpowiada i oczywiście wewnętrznie nasze narzędzie również nam w tym pomaga. Można powiedzieć, że używamy Miro do budowania Miro 🙂

Kolejną ważną wartością jest „Practice empathy to gain insight”. Chodzi tu zarówno o empatię do użytkowników, jak i między pracownikami. Jedną z pierwszych rzeczy, którą zauważyłem po przeprowadzce do Amsterdamu, była większa różnorodność niż w biurze w Krakowie. W każdej firmie, w której pracowałem w Holandii, większość osób w zespole pochodziła z innego kraju, a często też z innej kultury. Myślę, że praca w takiej konfiguracji bardzo pomaga stworzyć produkt, który radzi sobie dobrze w różnych środowiskach, kulturach pracy i rodzajach firm. Miro jest używane przez osoby prywatne, uniwersytety, firmy konsultingowe, ale także przez ogromne korporacje, w tym przez 99% firm z Fortune 100, i jest to moim zdaniem możliwe dzięki kulturze wewnątrz Miro.

Ostatnie dwie wartości to “Focus on impact and make it happen” oraz “Learn, grow, and drive change”, które pomagają Miro osiągnąć tę skalę wzrostu, którą wspomniałem na początku. Pojedyncza osoba może mieć ogromny wpływ na całą organizację, co jest praktycznie niemożliwe w korporacjach. Sam skorzystałem z okazji, żeby samemu zdefiniować swoje stanowisko poprzez pomoc przy jednym ze strategicznych programów, jakim było Accessibility.

Oferty pracy z

W jaki sposób uczyłeś się tej kultury? Zastanawiam się, czy doświadczenia z poprzednich firm pomagały pracować w stylu Miro?

Miro ewaluuje kandydatów pod względem zgodności z wartościami firmy już podczas rozmów kwalifikacyjnych. Dzięki temu osoby, które pozytywnie przechodzą etap rekrutacji rzadko okazują się niedopasowane pod względem kultury.

Zaczynałem pracę w momencie, gdy każdego miesiąca dołączało do Miro od kilkunastu do kilkudziesięciu osób. Wszyscy przywiązywali mocną wagę do utrzymania kultury i szczególnie kilka kwestii grało tu kluczową rolę.

Przede wszystkim cała grupa przechodziła “trening kultury”. Był to szereg spotkań (głównie warsztatów) trwający pierwsze dwa tygodnie, na których poznawaliśmy filozofię i wartości firmy. Całość kończyła się nieformalną sesją z naszym CEO, gdzie mogliśmy zadawać pytania na dowolne tematy.

Drugą kwestią były przygotowane kursy i materiały do samodzielnego przerobienia / zapoznania się. Wszystko było zebrane na dedykowanej dla mnie planszy Miro, która była centralnym źródłem informacji i bazą z odnośnikami do innych narzędzi. Było to świetne rozwiązanie, do którego zaglądałem często i mogłem je dowolnie rozszerzać notatkami, nowymi linkami, to-do listami itp.

Miałem też przypisanego onboarding leada (zwykle Twój manager) oraz technical buddy (zwykle senior engineer z Twojego zespołu), którzy pomagali mi przez cały okres próbny.

Jeżeli chodzi o doświadczenia z poprzednich firm, to przede wszystkim sprawdziły się uniwersalne zasady z pracy programisty w firmach produktowych typu SaaS, jak skupienie się na jakości czy rozumienie szerszego kontekstu biznesowego i konkretnego problemu użytkownika nad którym pracujemy.

Co przekonało zespół Miro do Twojej kandydatury?

Zatrudniałem się do Miro podczas pierwszego roku pandemii Covid, w 2020 roku. Był to czas hiperwzrostu dla firmy, ale cały proces rekrutacji był dość skomplikowany i składał się z 7 etapów.

Pierwszy etap był z rekruterką, czyli rozmowa o stanowisku, potwierdzenie kwalifikacji, ustalenie oczekiwań finansowych i wytłumaczenie całego procesu. Następnie dwa etapy techniczne, sprawdzające hard skills – live coding i system design. Kolejne trzy etapy to rozmowy tematyczne badające soft skills – team interview, product interview i hiring manager interview. Ostatnim etapem było sprawdzenie referencji, gdzie rekruterka dzwoniła do jednego z moich byłych managerów i jednego współpracownika. Musiałem podać po dwie osoby z każdej grupy, czyli cztery kontakty. Na koniec już tylko kwestia oferty i podpisania umowy. Byłem już wtedy w Amsterdamie, więc nie potrzebowałem pomocy w relokacji, znalezieniu mieszkania, etc.

W tym okresie Miro zatrudniało programistów tylko na stanowiska seniorskie, z preferencją do znajdowania tak zwanych “bar raisers”, czyli osób, które wnosiły nowe umiejętności i doświadczenie do zespołu. Bardzo pomagała więc jakaś konkretna, niszowa wiedza. W moim przypadku było to doświadczenie z accessibility i testami e2e w środowisku frontendowym (Cypress). Mile widziane było też moje doświadczenie z poprzedniej firmy (Dott), gdzie pracowałem przy aplikacji z obsługą danych w czasie rzeczywistym (a raczej zbliżonym do rzeczywistego), pod tym względem podobnej do Miro.

Dość unikalnym etapem, na którym wypadłem wyjątkowo dobrze dzięki doświadczeniu z poprzednich firm, był product interview, który przechodziłem już wcześniej podczas rekrutacji do Dotta. Miał on za zadanie potwierdzić, że wiem, jak moja praca rozwiązuje konkretne problemy użytkowników i jak to wpływa na biznes, jak mierzyć sukces moich projektów i jak efektywnie współpracować z product managerem. Zadaniem programisty w wielu firmach produktowych jest pomoc w upewnieniu się, że budujemy właściwą rzecz we właściwym czasie. Podczas tak ogromnego wzrostu Miro w czasie pandemii miało to ogromne znaczenie, stąd taka rozmowa w całym procesie.

Miro zatrudniało wtedy wielu programistów do wielu działów i zespołów, więc nie było też problemu typu “mamy dwóch dobrych kandydatów, ale możemy zatrudnić tylko jednego”. W takim przypadku najczęściej po prostu zatrudniali obu, więc rekrutacja była dla mnie łatwiejsza niż byłaby teraz. Pod tym względem były to zupełnie inne czasy.

Co przekonało Cię do tego, by po okresie próbnym zostać w Miro?

Zaczęcie pracy w firmie przechodzącej przez etap hiperwzrostu to spore wyzwanie, ale też ocean możliwości. Podobało mi się, że mimo tego wielkiego chaosu i ciągłych zmian udawało się cały czas rozwijać produkt we właściwym kierunku. Przychodziło wtedy do firmy wiele osób z ogromnym doświadczeniem, które szanowałem za ich profesjonalizm i od których naprawdę dużo się uczyłem.

Pierwszy raz pracowałem w firmie, gdzie liczba frontendowców przyćmiewa liczbę backendowców, a większość osób na wyższych stanowiskach miała większe doświadczenie z frontendem niż backendem. Była to dla mnie nowość i na pewno dodatkowy argument za pozostaniem, ponieważ sam pracuję głównie na frontendzie.

Od początku byłem odpowiedzialny za duże projekty nakierowane na sektor Enterprise, więc podobała mi się praca sama w sobie i widziałem się tam na dłużej. Pod koniec okresu próbnego był dość rozbudowany proces podobny do performance review, gdzie dostałem feedback od wszystkich członków zespołu wraz z oceną czy spełniam wymagania na danym stanowisku. Było to bardzo pomocne dla obu stron w podjęciu decyzji o kontynuacji pracy po okresie próbnym, ponieważ dawało mi łatwy wgląd czy jestem w stanie odnieść tam sukces pracując w taki sposób, jak dotychczas.

Jak rynek holenderski i Miro zareagowało na falę zwolnień z poprzedniego roku?

Miro jest prywatną firmą nie notowaną na giełdzie, ale nawet nas nie ominęły zwolnienia. Musieliśmy ograniczyć dział sprzedaży i rekrutacji, żeby dostosować się do warunków panujących globalnie i naszych planów na przyszłość. Sporo osób z tych działów przeniosła się wewnętrznie na inne stanowiska.

Podobnie było w innych firmach w Amsterdamie i całych Niderlandach. Zwolnienia dotknęły pracowników dużych firm, jak Uber czy Booking, ale i wielu mniejszych startupach. Na szczęście prawa pracowników są tu na wysokim poziomie, więc cały proces jest dużo bardziej cywilizowany niż ten w Stanach, który widzieliśmy w wielu firmach takich jak Google czy Meta.

Co w Miro zmieniło się od tego czasu?

Przede wszystkim zaczęliśmy dużo bardziej restrykcyjnie podchodzić do kwestii zatrudniania nowych osób, które w zespołach produkcyjnych ograniczyliśmy do minimum. Jestem teraz odpowiedzialny w Miro za dwa zespoły i żeby otworzyć nowe stanowisko potrzebuję bardzo solidny business case, który zatwierdzają ludzie z najwyższego szczebla po bardzo szczegółowej analizie.

Dla porównania, jako osoba przeprowadzająca etap rekrutacji System Design z aplikantami, w okresie hiperwzrostu miałem zawsze 3 rozmowy rekrutacyjne tygodniowo. W poprzednim roku ta ilość spadła do średnio 1 rozmowy na miesiąc.

Trudno o tej całej sytuacji pisać z dobrej perspektywy, ale przez dłuższy czas nie mogliśmy znaleźć inżyniera QA do mojego zespołu od accessibility. W końcu udało nam się zatrudnić świetnego specjalistę, który został dotknięty masowymi zwolnieniami w Twitterze. Gdyby nie fakt, że cały jego zespół przestał istnieć praktycznie z dnia na dzień, pewnie nie byłby dostępny na rynku. Było to więc koniec końców szczęśliwe zakończenie dla obu stron, ponieważ pracuje już u nas od ponad roku i jest bardzo zadowolony.

Uważasz, że przez falę zwolnień trudniej o awans, o rozwój swojej ścieżki kariery?

Dość ciężko odpowiedzieć mi na to pytanie jednoznacznie, ale zaryzykuję stwierdzeniem, że statystycznie tak faktycznie jest.

Trudniej o awans poprzez zmianę pracy, czyli rekrutację na wyższy level niż obecny. Liczba ofert pracy w topowych firmach spadła, a poprzez falę zwolnień firmy mogą znaleźć kandydata, który pracował już na podobnym stanowisku wcześniej. Jest to zawsze mniejsze ryzyko dla pracodawcy, kiedy ktoś ma udokumentowane sukcesy w podobnym zakresie obowiązków do naszego otwartego stanowiska. Trudniej też o awans na stanowiska powyżej senior inżyniera i managera.

Wiele firm, w tym Miro, ograniczyła wzrost, więc i zapotrzebowanie biznesowe na tego rodzaju stanowiska jest mniejsza. Mamy wielu utalentowanych seniorów w firmie, ale przecież nie każdy z nich może zostać staff inżynierem czy też dyrektorem.

Dalej jednak pozostaje opcja rozwoju nowych umiejętności, poszerzania umiejętności, czy transferów wewnętrznych. Wszystkie te opcje przygotują nas lepiej albo na moment, kiedy rynek ruszy do przodu, albo na zasłużony bonus czy podwyżkę.

Porozmawiajmy o podejściu do accessibility, bo to bardzo interesujący wątek. Jak podejść do poprawny naszego produktu, którego twórcy wcześniej nie poświęcali czasu na accessibility?

Jest to temat rzeka, ale już w samym pytaniu podkreśliłeś największy i prawdopodobnie najczęstszy błąd. Odkładanie accessibility na później. Jest to najdroższa i najtrudniejsza droga. Parafrazując powiedzenie o sadzeniu drzewa, najlepszym czasem na uwzględnienie accessibility był początek projektu, drugim najlepszym czasem jest teraz.

W przypadku, kiedy zabieramy się za accessibility po jakimś czasie, mamy w produkcie “dług accessibility” do spłacenia. Żeby odnieść sukces, musimy wziąć pod uwagę kilka aspektów i zadbać o fundamenty nie tylko techniczne, ale też te po stronie wiedzy i procesów.

Powodów, żeby zadbać o accessibility jest wiele, ale przede wszystkim nie dość, że usprawni to cały produkt (dla wszystkich), to jest to po prostu słuszne moralnie. Dodatkowo, uchroni nas przed pozwami (szczególnie w Stanach), przygotuje na European Accessibility Act (który wymaga pełnej dostępności dla nowych produktów już od 2025), oraz otworzy nas na kontrakty z największymi firmami (które o accessibility pytają i wymagają). Jest spora szansa, że w większych organizacjach, to właśnie ten ostatni punkt przyciągnie uwagę leadershipu najmocniej. W biznesie za wszystko trzeba zapłacić i moim zdaniem koszty accessibility najczęściej pokrywa sektor Enterprise. A mając poparcie z samej góry i ustalając możliwie globalny Key Result czy metrykę odnośnie accessibility, pomagamy je priorytetyzować w firmie.

Uważam, że accessibility jest podstawową umiejętnością wszystkich designerów i inżynierów, ale niestety w rzeczywistości często jest to wciąż wiedza niszowa. Musimy więc zadbać o szkolenie i zdefiniowanie wymagań dla różnych ról. W Miro każda nowa osoba samodzielnie przechodzi przygotowany przez nas wewnętrzny onboarding na ten temat, a obecnie wprowadzamy program ambasadorów accessibility, którzy pomogą nam we wszystkich cyklach pracy nad nowymi funkcjami naszego narzędzia.

Po stronie technicznej musimy sprawić, aby dodawanie nowego kodu było prostsze, kiedy nie ma on problemów z accessibility oraz nie wprowadza regresji. Nie da się całkowicie zautomatyzować testowania accessibility, ala już sprawdzanie podstawowych błędów w semantyce, kontraście, a także głównych scenariuszy nawigacji za pomocą klawiatury i przy użyciu czytników ekranu przed każdym releasem będzie niezwykle pomocne.

Jeżeli używamy Design Systemu, to upewnienie się że komponenty nie mają błędów accessibility oraz, że są używane w prawidłowy sposób, będzie wielką pomocą w propagowaniu dobrych wzorców horyzontalnie w całym produkcie. Powinno to być jednym z pierwszych zadań.

Zadbajmy też dodanie accessibility jako niefunkcjonalnego wymagania do wszystkich nowych części produktu, nad którymi pracujemy. Unikniemy dzięki temu takiego samego problemu w przyszłości. Produkty ewoluują i są rozwijane przez cały czas i accessibility musi być częścią procesu, a nie czymś o czym myślimy na końcu.
Wiele firm zamawia też zewnętrzny audyt accessibility, który następnie pomaga zespołom przygotować poprawki w różnych częściach produktu.

Ten krok jest sporym ułatwieniem, pod warunkiem, że nie zapomnimy o faktycznym celu jakim jest zwiększenie użyteczności naszego produktu dla osób korzystających z wszelkiego rodzaju technologii pomocniczych. Poza weryfikowaniem poprawek z audytu w izolacji odnośnie zgodności ze standardami (jak na przykład WCAG 2.2), powinniśmy też testować nasz produkt podczas prawdziwego użycia w prawdziwych use-case’ach. W końcu wszystko to robimy dla naszych użytkowników i nie możemy przejść tego procesu bez nich.

---

Marcin Pająk. Staff Software Engineer w Miro. Firma, w której pracuje odpowiada za narzędzie wspomagające pracę zespołów, gdzie jest odpowiedzialny za accessiblity i lokalizację. Posiada ponad 15 lat doświadczenia w branży zdobywanego w Polsce i za granicą, a od 10 lat związany jest z produktami SaaS. Prywatnie mąż i tata, miłośnik podróży, fotograf amator i fan książek sci-fi.