W najlepszych firmach dobra komunikacja nie jest opcjonalna. Wywiad z Adamem Dubielem

Adam Dubiel przez 10 lat pracował w Allegro, w którym to przeszedł drogę od Senior Software Engineera po Technology Directora. Obecnie pracuje w XTB jako Chief Product & Technology Officer. Jak przez te lata kształtowało się jego podejście do wytwarzania oprogramowania? Tego dowiecie się z tej rozmowy.

Po dziesięciu latach zdecydowałeś się opuścić Allegro. Jak napisałeś na LinkedIn, ludzie, których spotkałeś ukształtowali Cię jako inżyniera i lidera. Co Cię ukształtowało? Jakieś konkretne sytuacje, wydarzenia czy projekty?

Dołączyłem do Allegro w 2013 roku. To był bardzo ciekawy moment rozwoju firmy – zarówno technologicznie, jak i biznesowo. Technologicznie właśnie dopiero co firma przestawiła się na pracę Agile, a już zaczynała się wielka zmiana:

• rozbijanie monolitu na mikrousługi w duchu Domain Driven Design,
• adopcja Javy jako wiodącego języka programowania,
• wdrażaliśmy także nowe rozwiązania OpenSource – Kafka (chyba jeszcze w wersji 0.7), Cassandra, Mongo.

Z obecnej perspektywy wszystko działo się w szalonym tempie, kilka rozwiązań nie przetrwało próby czasu, ale ogólny zamysł i kształt rozwinął się w dzisiejszą architekturę Allegro.

Jakie korzyści przynosi praca w takim tempie?

Kiedy tak wiele dzieje się w firmie, jest też dużo miejsca na rozwój. Chyba pojedynczym najważniejszym dla mnie wydarzeniem była anegdotyczna “rozmowa przy windzie” w 2014 z ówczesnym kierownikiem mojego działu Piotrem Orłowskim. Zaproponował zostanie liderem zespołu budującego narzędzia wewnętrznego do łatwiejszego tworzenia mikrousług. Przy windzie, bo w biurze w Warszawie brakowało salek, ale jeden z szybów windowych był mało uczęszczany i tam robiło się krótkie spotkania.

Zaczęło się od startera w Spring Boot i kilku pluginów Gradle, potem dołączyła allegrowa szyna danych Hermes (do znalezienia jako projekt Open Source), Service Mesh i kilka innych rozwiązań.

Dużo ważniejsze od samych produktów był sam fakt, że zdecydowałem się zejść ze ścieżki programistycznej na managerską i zacząłem budować samoświadomość i głębsze zrozumienie ludzi oraz organizacji. To była długa droga, ale szczęśliwie miałem dookoła świetnych managerów, z których mogłem brać przykład.

Przeszedłeś drogę od inżyniera solisty do dyrektora zarządzającego 400-osobowym zespołem. W którym miejscu, na którym etapie poczułeś siłę pracy zespołowej?

Rzeczywiście na początku mojej kariery czułem się solistą, mimo że zawsze pracowałem w zespołach. Wkładałem dużo energii w to, żeby podtrzymać wizerunek eksperta. Zanim się odezwałem musiałem mieć pewność, że moja opinia ma poparcie w faktach. To akurat zostało mi do dziś.

Siłę zespołu poznałem w pełni wtedy, kiedy sam stałem się odpowiedzialny za zespół. Nie zdarzyło się to z dnia na dzień. Potrzebowałem dużo czasu, zanim w pełni zrozumiałem teoretyczne podstawy efektywnego i dobrego zarządzania i wdrożyłem je w praktyce. Delegowanie, transparentna komunikacja, umawianie się na efekty zamiast mikrozarządzania. To było pewnie w 2015 roku. Wtedy też zacząłem budować sieć kontaktów w firmie, współpracować z dużą większą liczbą ludzi w kilku inicjatywach organizacyjnych – proces rekrutacji, budowanie kultury dobrego, jakościowego kodu. I zacząłem obserwować, jak odpowiednia komunikacja czy struktura organizacji wpływa na zachowania ludzi.

Pokażmy może różnice w sposobie myślenia solisty a dyrektora. Jak obie te postacie podchodzą do jednego zadania?

Dobre pytanie. W moim przypadku solista, a do tego jeszcze perfekcjonista, zrobi wszystko sam od A do Z, przyjdzie z efektem pracy i jeszcze będzie oczekiwał pochwał i szacunku od zespołu. Pamiętam, że poświęciłem kiedyś kilkanaście godzin po pracy na przepisanie frontendu jednej z aplikacji. Zrobiłem to kompletnie sam, bez wiedzy zespołu – a potem pokazałem efekty pracy na demo i wrzuciłem w code review. Uważałem, że to zadanie, na które szkoda czasu całego zespołu, zrobię szybko sam. Do tego programowanie naprawdę jest moją pasją i po prostu sprawiało mi to przyjemność. Oczywiście zespół nie był zachwycony taką postawą, nawet jeśli merytorycznie moja praca się obroniła.

Jako dyrektor wskazuję kierunek, daję ramy, wizję i proszę zespół, żeby zbudował konkretne rozwiązania. Dużo rozmawiam, szukam słabych i silnych stron wizji, obserwuję reakcje, czytam między wierszami i koryguję działania. Moją rolą jest budowanie dobrego środowiska do pracy z jasnym celem i wymaganiem efektów, a nie wykonywaniem wszystkiego samodzielnie. Jest cienka granica między wskazywaniem kierunku, a zrzucaniem całej pracy i odpowiedzialności na zespół i trzeba na to bardzo uważać. Chcę pozostać liderem, który daje dużo od siebie, a nie “dyrektorkiem”, który wyręcza się ludźmi.

Z jakimi wyzwaniami mierzy się na co dzień inżynier, a z jakimi dyrektor zarządzający zespołem inżynierów?

Nie wiem czy jeszcze potrafię tak bardzo wczuć się w rolę inżyniera. Koduję tylko po godzinach, i to też coraz mniej. Natomiast na pewnym poziomie abstrakcji te wyzwania są podobne – przede wszystkim komunikacja i współpraca. Tylko w przypadku inżyniera/ki to praca na poziomie zespołu, wypracowywanie konsensusu, a potem szukanie jak wejść w stan “flow”. Bycie inżynierem to dla mnie przede wszystkim budowanie.

Jako dyrektor też buduję, ale trochę inne rzeczy. Skupiam się na budowaniu dobrej organizacji, przepływu wiedzy i wizji tak, żeby ludzie mogli wykorzystywać swój potencjał. Wyzwań jest bardzo dużo, ale wspólnym mianownikiem do ich rozwiązania jest czas. Zadań i ludzi, z którymi powinienem rozmawiać jest zawsze o wiele więcej niż czasu. Dlatego trzeba wypracowywać metodę zarządzania czasem, która maksymalizuje efekty. Jednocześnie nie można zapomnieć o ludziach, o kontakcie z nimi, na końcu jakbym nie był efektywny, bez mojego zespołu nic nie osiągnę.

W jaki sposób radziliście sobie z zarządzaniem dwoma tysiącami mikrousług? To nie lada wyzwanie, nawet jak na 2000-osobowy zespół. Jak do tematu zarządzania mikroserwisami podchodziłeś w swoim 400-osobowym zespole?

Inwestycja w mikrousługi to duży wysiłek. Niby wszystko wygląda na proste – każdy zespół ma teraz wolność tworzenia, pozbywamy się zależności w kodzie, a zyskujemy jasną odpowiedzialność za elementy składowe systemu. Złożoność jednak nie znika i przenosi się w tak zwane “środowisko uruchomieniowe”. Mówiąc wprost – jeśli nie mamy dobrych procesów i dobrych, doświadczonych ludzi w zespołach, którzy umieją myśleć przez pryzmat Domain Driven Design, najpewniej ugrzęźniemy na powolnym wydawaniu kodu na produkcji, a z czasem połączenia między mikrousługami zamienią się w spaghetti nie do ogarnięcia. Utrzymamy wszystkie wady monolitu, a niewiele skorzystamy na mikrousługach.

O tych ryzykach mówi się od ponad 10ciu lat, a i tak firmy popełniają te same błędy. Panaceum na część problemów w mojej opinii jest inwestycja w zespoły platformowe (Platform Teams). W tej koncepcji w uproszczeniu w firmie powstają dwa rodzaje zespołów:

• zespoły produktowe, skupiające się na rozwijaniu mikrousług i budowaniu końcowego produktu, podzielone na domeny produktowe,
• zespoły platformowe, których rolą jest budowanie procesów i środowiska uruchomieniowego oraz nadzór nad ogólną architekturą techniczną, żeby praca zespołów produktowych była produktywna.

Oprócz zmiany struktury organizacji, potrzebna jest też zmiana sposobu myślenia. Zespoły platformowe to nie tylko inaczej nazwana dawna infrastruktura. To zespoły, które muszą zacząć myśleć o środowisku uruchomieniowym, jak o swoim produkcie. Skoro jest produkt, musi być wizja. Skoro jest Klient, to trzeba z nim rozmawiać, słuchać go i reagować na jego potrzeby. To zupełnie nowe podejście do infrastruktury i moim zdaniem to jest najtrudniejszy element w tej układance.

Trudno się łudzić, że każda firma zacznie pracować w ten sposób. Na jakim etapie rozwoju zdecydowanie trzeba zacząć tak podchodzić do infrastruktury?

Nie zgadzam się z tym stwierdzeniem. Jeśli spojrzymy na działy IT w różnych firmach, współdzielimy jako branża pewne wzorce pracy, budowy struktury. Z mojej perspektywy taki wzorzec jest do zastosowania wtedy, kiedy zaczynasz pracować z mikorusługami. W małej firmie to niekoniecznie będzie wydzielony dział, ale przy kilkuset pracownikach budowałbym jasno nazwany zespół platformy.

Przed naszą rozmową zapytałem Cię o to, o czym Twoim zdaniem za mało mówi się w kontekście pracy w IT. Odpisałeś: “o tym jak ważna jest umiejętność pisania – w celu przekazywania swoich racji i dokumentowania decyzji”. Rozumiem, że chodzi o umiejętne przekazywanie swoich pomysłów, propozycji?

Jestem programistycznym samoukiem, do tego zafascynowany ruchem Open Source. Ucząc się, bardzo dużo korzystałem z dokumentacji projektów. I często widziałem, że dokumentacja pisana jest z perspektywy twórcy kodu, który zna kontekst i wszystkie założenia, więc ich nie tłumaczy. Dla samouka oznaczało to wiele wiele godzin mozolnych prób i błędów, bo to, co “oczywiste” (np. przyjęte konwencje) dla mnie było czarną magią.

Od fascynacji dobrą dokumentacją, wraz ze zmianą mojej roli przeszedłem do myślenia o opisywaniu decyzji, ścieżki myślenia. Mówienie jest bardzo ulotne, dociera tylko do ludzi zgromadzonych na danym spotkaniu, gubi się kontekst. Po spotkaniu każdy mógł zrozumieć lub zapamiętać coś innego. Do tego każdy może wpaść na spotkanie i zacząć mówić – mówienie jest bardzo proste. Inaczej przekazuje się wiedzę w postaci dokumentu tekstowego.

Jaka to różnica?

Spisanie swoich myśli wymaga włożenia wysiłku w uporządkowanie myśli i opisanie kontekstu. Dobrze napisany dokument pozostawia ślad i może trafić do bardzo dużej liczby ludzi na przełomie wielu lat. Czasem ze zdziwieniem odkrywałem, że ktoś powołuje się na decyzje z dokumentu, który spisywałem 5-6 lat temu, które dalej były w mocy. Ponadto w dokumencie od razu można wyłapać potencjalne luki w myśleniu, skomentować, rozpocząć dyskusję.

Pisanie jest też bardzo ważne przy obecnej strukturze pracy. Pracujemy zdalnie lub hybrydowo. Musimy zachować kontakt z zespołem, a jednocześnie na wagę złota są okresy nieprzerwanej pracy, kiedy można wejść w stan wysokiego skupienia, tzw. “flow”. Rozwiązaniem jest praca asynchroniczna. Zamiast spotykać się ”synchronicznie”, spisujemy swoje myśli i potem dyskutujemy przez komentarze dokumencie, a tylko najważniejsze otwarte kwestie na spotkaniu. Spotkaniu, które jest bardzo efektywne, bo wszyscy znają dokument, są przygotowani i nie ma potrzeby wprowadzania w temat.

W Allegro nauczyłem się praktyki prowadzenia spotkań rodem z Amazona, czyli tak zwane “silent reading” (ciche czytanie). Na początku spotkania wszyscy w ciszy czytają przygotowany dokument, zostawiając komentarze. Dopiero po tej części przechodzimy do dyskusji. Dzięki takiemu podejściu każdy ma czas na zapoznanie się z treścią dokumentu, ma wszystkie szczegóły na świeżo, cały kontekst dyskusji zawarty jest w czasie spotkania. Nie ma problemu, że ktoś nie przeczytał, ktoś przeczytał 2 dni temu i już nie pamięta.. to dla mnie część budowania efektywności i maksymalnego wykorzystania czasu. Na początku ta praktyka wydaje się być niecodzienna, ale plusy szybko przeważają i ja już nie wyobrażam sobie innej pracy.

Sam wymagam pracy na dokumentach, właśnie po to, żeby szybko docierać do sedna sprawy i zobaczyć ciąg myślowy, a potem móc się odwołać do konkretnych ustaleń. Przy liczbie zagadnień jaką zarządzam, trudno byłoby mi inaczej budować bazę wiedzy i ślad decyzji.

Tę umiejętność pisania, pisemnego przekazywania myśli, zaliczyłbyś do umiejętności miękkiej? W jaki sposób zdobyć wiedzę o tym, jak pisać, jak przekazywać swoje myśli, propozycje czy oczekiwania?

Rozumiem, że posługujemy się tutaj rozróżnieniem na kompetencje “twarde“ – czyli np. znajomość języka programowania oraz umiejętności “miękkie” – czyli np. komunikacja. Takie rozróżnienie ma sens, ale pokutuje jeszcze myślenie, że te “miękkie” to może trochę mniej ważne, w końcu zgodnie z sucharem: “nie po to zostawałem programistą, żeby rozmawiać z ludźmi”. Realia są zupełnie inne. Rozmowa i współpraca to podstawa efektywnego działania w zespole.

Pisanie zaliczyłbym do umiejętności komunikacyjnych, więc w tej kategoryzacji “miękkich”. Jednocześnie podkreślam, że w najlepszych firmach dobra komunikacja nie jest opcjonalna, a wręcz jest częścią wymagań, badanych także w czasie rekrutacji. O ile nie mówimy o zaawansowanej algorytmice, a budowie produktu, zgrany i dobrze komunikujący się zespół może osiągnąć dużo więcej niż nawet najlepsza jednostka.

Kluczem jest dla mnie równomierne rozwijanie tych dwóch typów umiejętności. W zasadzie taką drogę sam przeszedłem, od merytorycznego eksperta po CPTO, który bazuje głównie na umiejętnościach miękkich.

---

Adam Dubiel. Chief Product & Technology Officer w XTB. Swoją przygodę w IT zaczął od pracy w software housie. Przez ponad 3,5 roku pełnił rolę Technical Trainera. 10,5 roku pracował w Allegro, gdzie przebył ścieżkę od Software Engineera do Technology Directora zarządzającego ponad 400-osobowym zespołem.