#15 Team Lead w IT. Jak być dobrym liderem zespołu programistów? Seweryn Łach.

Patrz na mnie. Nie musisz tworzyć zespołu i później zwalasz na tego, co tworzył zespół. Dokładnie. Idziesz i mówisz... Przecież ja tego nie złożyłem. Ktoś inny to zrobił. Patrzcie na tego Bika. Cześć, jestem Nikodem. Witam w kolejnym odcinku podcastu DEVision. Dzisiaj w studio jest ze mną Seweryn Łach, z którym będę rozmawiał o roli Tiela. Zgadza się. Jak to jest w naszym zwyczaju, najpierw chciałbym cię poprosić o kilka słów o sobie. Pewnie, więc jakby wszystko zaczęło się oczywiście co związanego z pracą w IT 12 lat temu.

Więc od zera w zasadzie budowaliśmy to biuro. W tym momencie mamy około 100 osób w biurze w Krakowie, więc jakby zeszły rok był bardzo intensywny. Intensywnie inwestowaliśmy w rekrutację, w budowanie Zespół R&D tutaj w Krakowie, co wydaje mi się, że może po części pomoże mi podzieleniem się podczas tego podcastu doświadczeniem jakie zebrałem w budowaniu zespołów i tego wszystkiego co się u nas działo, więc myślę, że to może być bardzo ciekawe. Kim jest i czym zajmuje się Team Lead? Myślę, że odpowiedź nie jest taka prosta, bo to zależy od tego, w jakiej firmie się pracuje. Myślę, że jeśli rozmawiamy o stanowiskach na przykład dewelopera czy testera, no to powiedzmy, że jesteśmy jakoś w stanie tak bardziej precyzyjnie skonkretyzować, czym ta osoba ma się zajmować.

Jeśli mówimy o stanowisku, dajmy na to Team Leada, czy też na przykład później Managera, czy tam Product Managera, No to wydaje mi się, że to też zależy dużo od tego, w jaki sposób firma dana zdefiniuje sobie taką rolę, czym taka osoba ma się zajmować. Więc w jednej firmie może to być osoba, która zajmuje się tylko i wyłącznie, powiedzmy, takim zarządzaniem ludźmi, a w innym zespole może to być, czy tam w innej firmie może to być osoba, która na przykład, nie wiem, 50% swojego czasu poświęca na zarządzanie ludźmi, a 50% swojego czasu poświęcana również na rzeczy praktyczne, nie? Czyli też uczestniczy tam, czy to w testowaniu, czy w wytwarzaniu programu, nie? Dobrze, a z twojego doświadczenia? Jak to wynika? Z mojego doświadczenia? W branży, w której jesteśmy, uważam, że każda osoba, jeśli chce należeć, powiedzmy, do działu R&D, to powinna być osoba, która ma pojęcie i styczność z tym, co robi, albo co robią inni ludzie, bo, znaczy mówię to na podstawie doświadczenia.

Przez lata, które przepracowałem, wydaje mi się, że z tymi ludźmi, których spotkałem i tak dalej, w jakich firmach i jak to wyglądało, zawsze było dużo łatwiej i płynniej się dogadać, jeśli siedzimy przy stole i wszyscy rozumiemy mniej więcej, o czym mówimy. Znaczy mówię mniej więcej, bo wiadomo, że jeśli ktoś jest team leadem, oczywiście nie musi znać każdego z szczegółów, które dana osoba robi, bo to bardziej mówimy o kimś, kto kreuje wizję dla zespołu, czyli kierunek, w jakim dany zespół ma podążać i osoba, która scala ten zespół. Ja bym tak to określił. W jaki sposób przejawiała się u Ciebie taka rola? Każdy lider może to robić na swój sposób i na pewno byłbym chyba jedną z ostatnich osób, która by stwierdziła, że przykładowo jeśli ty to robisz w taki sposób, jak ty uważasz, że to jest złe, bo każdy może mieć swój styl swojego leadershipu.

Jaki jest mój sposób? Więc myślę, że z mojego punktu widzenia ważnym elementem scalania zespołu jest to, żeby w zespole był duży alignment pod kątem tego, co chcemy zrobić i co chcemy osiągnąć. I też żeby dawać ludziom autonomię tego, co mogą robić. I uważam, że to są dwie główne rzeczy. Może dodałbym do tego jeszcze transparencję. Żeby to, co się dzieje w zespole, czy rzeczy, które dotyczą zespołu, były transparentne i zrozumiałe dla zespołu. I myślę, że to pozwala scalać zespół. Opowiadasz nam tutaj bardzo ogólne definicje tego, jak to wygląda. Czy mógłbyś to oprzeć na jakimś przykładzie? Myślę, że dobrym przykładem jest chociażby to, że pracując powiedzmy przecież przez lata z różnymi zespołami developmentowymi czy Scrumowymi, no to prawda jest taka, że zespół tworzą ludzie.

Mogło być dużo fanów, ale niekoniecznie mogłoby to się przekładać na efektywność pracy tego zespołu. Natomiast jeśli chodzi o scalanie, dobór ludzi na pewno ma znaczenie, dobór osobowości do tego zespołu. To jeśli zadałeś pytanie o praktykę, więc myślę, że ja na to zwracam największą uwagę. W sensie, jakie osoby będą tworzyć ten zespół. Wiadomo, że nigdy nie jesteś w stanie jakby... Pytanie, czy mówimy o ludziach, których znasz, bo na przykład z nimi pracowałeś i próbujesz na przykład z tego złożyć dwa, trzy, cztery zespoły, czy... Czy na przykład mówimy o sytuacji, kiedy próbujesz zbudować nowy zespół? Bo to są całkowicie, wydaje mi się, dwa różne wyzwania bazując na doświadczeniu. Zgadzam się i wydaje mi się, że taka sytuacja, kiedy to ty masz wpływ na to, jak będzie wyglądał twój zespół i budujesz go powiedzmy od początku, wydaje się takim dosyć łatwym scenariuszem, no bo tak jak właśnie możesz popatrzeć na te charaktery, czy to będzie pasował, czy nie będzie pasował do zespołu, a jestem bardzo zainteresowany, co w sytuacji, albo czy miałeś okazję pracować z zespołem, gdzie no..

Dołączyłeś do zespołu, w którym ludzie już są i musisz teraz sobie z nimi poradzić. Jasne. No, miałem taką sytuację i oczywiście to, co mówisz, jak najbardziej się zdarza i zgodzę się z tym, że z jednej strony budowanie nowego zespołu jest trudne, z drugiej strony jest łatwe, bo też masz udział w tym, tak naprawdę kogo będziesz miał w tym zespole i możesz sobie dobierać. Oczywiście pewnie zawsze gdzieś tam jest jakaś granica. Z zespołami takimi, które są istniejące i wchodzenie w nowy zespół, to się wiąże z kilkoma rzeczami. Myślę, że po pierwsze musisz sobie zbudować autorytet wśród takiej grupy ludzi, w którą wchodzisz. Jak to każdy buduje, no to znowu myślę, że to zależy. Zależy kto ma jaki charakter i kto ma jaką osobowość. Ja bym powiedział, że możesz wejść z zespół

...na trzy sposoby. Albo możesz wejść, że tak powiem, z hukiem otworzyć drzwi i starać się zrobić porządek w jeden dzień. Albo możesz wejść po cichutku jak mysz i się rozglądać przez następny rok czasu co się będzie działo. Albo możesz przyjąć nastawienie takie powiedzmy pośrodku. Niekoniecznie musisz wejść z hukiem, z drzwiami. Niekoniecznie musisz się chować po kontach i próbować zrozumieć co się dzieje czy co się nie dzieje. Tylko podejść do tego w sposób fair do ludzi. Zacząć nawiązywać jakiś kontakt. Po pierwsze, wydaje mi się, że ważne jest to, żeby zrozumieć kogo masz w takim zespole. Poświęcić każdemu czas na to, żeby poznać taką osobę. No bo to jest w zasadzie, ty jeśli jesteś liderem, to ty musisz dobrze znać swój zespół. To jest podstawa. I ty musisz być osobą, która według mnie najlepiej zna ten zespół, każdą osobę.

Nie dość, że będzie się stresować, nie będzie z tego zadowolona, w ogóle uzysk będzie zero. I dla Ciebie, i dla tej osoby, i dla całego zespołu. Więc to jest dobry przykład. I na przykład takich przykładów jak ten bardzo wiele miałem w przeszłości. Dotyczących np. jakiegoś code review, czy spotkania z innym zespołem, czy spotkania z architektem, czy z klientem, gdzieś powiedzmy jakiegoś nagłego przypadku, który wyszedł powiedzmy z jakimś błędem z produkcji. To są dokładnie te To są dokładnie te sytuacje, kiedy ty jako lider, znając swój zespół, jesteś w stanie podejmować właściwe decyzje, które w efekcie będą korzystać z zespołu i też w jakiś sposób będą budować twój autorytet. Na samym początku wspominałeś o czymś takim, że jako team lead starasz się też być zaangażowany w pewien sposób w produkt, żeby wiedzieć, co się dzieje.

No i nie jesteśmy w stanie tego zrobić tak, jak zakładaliśmy na środę, tylko potrzebujemy jeszcze tygodnia. I do gościa, którego idziesz i on rozumie aspekty techniczne, no to pewnie zrozumie to chwilę, załapie i jakby koniec dyskusji. On to rozumie i wie, że nie jesteś w stanie tego przeskoczyć. Osoba, która nie jest techniczna, no w tym momencie zaczyna się, nie? Zaczynają się pytania. Co nie możecie usunąć i wstawić na nowo? Jaki jest problem? O co chodzi? Dokładnie. Bo zaczyna się... No i tutaj znowu dochodzimy do momentu, kiedy przechodzimy w kwestię zaufania. To budowania zaufania w zespole. Ważnym aspektem budowania zespołów, czy zespołu, scalania tak samo, to też jest budowanie, to jest tak samo budowanie zaufania wśród zespołu. Masz na myśli poszczególnych osób między sobą, czy masz na myśli tą relację TL i zespół? Nie, myślę, że wszystkich. W zespole jest, myślę, że jedną z kluczowych rzeczy, żeby ludzie mogli ze sobą fajnie współpracować i żeby ta współpraca była bardzo efektywna, jest zaufanie wśród zespołu.

Myślę, że jest bardzo ważne. Myślę, że dobry lider to jest osoba, która nie podejmuje decyzji pod wpływem impulsu czy też emocji. To ciekawe, co mówisz z tą trzecią cechą. Nie wiem, czy się kiedyś spotkałem. Nie wiem, czy spotkałem się z scenariuszem, kiedy była ona aż taka istotna. Mógłbyś podać jakiś scenariusz? Tak, myślę, że takich przykładów bardzo dużo można wyciągnąć. Pewnie to są takie przykłady, które mocno dotykają takiej pracy codziennej. Może byśmy poszli w szczegóły, ale na pewno da mnie na to sytuacja, kiedy coś dzieje się niedobrego na produkcji. I nagle powiedzmy jest jakaś eskalacja i pojawiają się nerwy wśród zespołu. I nie wiem, może być to zaangażowany nawet nie jeden zespół, może być nawet kilka zespołów. Powiedzmy, że osoba, która była odpowiedzialna za jakiś fragment tego feature'a, który tam został powiedzmy poturbowany.

Bo w końcu jednak skąd się tutaj wzięli? Jeśli ty budowałeś ten zespół, no to nie przyszli tutaj jakby z przypadku, tylko zdecydowałeś, że oni tu przyjdą. Jeśli nawet ktoś inny o tym decydował, no to okej, decydało, więc rozmawiajmy o tym albo rozliczajmy ludzi z tego, co robią i co powinni robić, a nie z tego, co ty uważasz, Albo co tobie się wydaje? Nawet jeśli jesteś team leadem, to wydaje mi się, że wtedy nic dobrego z tego nie wyjdzie. Inny przykład, który przychodzi mi do głowy, to jest taki, kiedy mieliśmy taką sytuację, że team lead Zaproponował zrobienie pewnego tam feature'a, który miał pewne fajne rzeczy robić. Znaczy generalnie idea była super, bo naprawdę wartościowa i potrzebna. Tyle, że problem był taki, że nie wiem, czy wynikało to z tego, że presja była na niego położona ze strony product managementu, że chce to prowadzić, czy po prostu to było jego takie wyobrażenie.

Wpłynęło to na motywację ludzi, na morale, na stres. No i finalnie okazało się, że projekt po dekompozycji był kontynuowany przez następne dwa lata przez cały zespół. To, co miało początkowo być zrobione przez 2-3 zespoły, taki mały featurek do zrobienia na 4-6 sprintów. Taki był finał. Jaki jest tego wniosek? Wniosek jest taki, że dobry team lead też powinien słuchać tego, ale to wracamy do kwestii zaufania. Jednak jeśli pracuję z tym zespołem, to powinien ufać tym ludziom, że jeśli Przychodzisz do kogoś i mówisz, że no mam tu zadanie na 4 sprinty, a ktoś ci mówi, nie, nie, nie, to będzie 40 sprintów, to nie mówisz nie, gadasz głupoty, tylko na zasadzie, że może jednak trzeba poświęcić jeszcze tydzień czasu i zrozumieć, czy aby na pewno tydzień czasu może świata jakby nie zbawi, ale może pokaże jakieś inne dno.

A w tym sytuacji co wyszło? Wyszło to, że on przyszedł, wymusił na zespole coś, czego zespół nie chciał, wyszło na to, że zespół miał rację i w jakimś świetle go postawiło. I wracamy znowu do kwestii budowania autorytetu wśród zespołu. Znaczy ten gość sam sobie podburza autorytet przed zespołem. No bo następnym razem przyjdzie i co? Dalej chce zrobić, podrobić w podobny sposób? Czy masz jakiś taki przykład, kiedy ty byłeś w roli Tiela i spotkało cię jakieś takie duże wyzwanie? Na pewno bym skłamał, gdybym powiedział, że nie było trudniejszych sytuacji, z jakimi bym się musiał zmierzyć, które wynikały często z różnych rzeczy. Zaczynając nawet od najprostszych, że dajmy na to, że współpracujesz z zespołem i masz zakres kompetencji, który ten zespół potrafi robić.

Bardzo dobrze wiemy o tym, że w IT często się spotykamy z sytuacją, kiedy nie masz jakby stuprocentowego fitu dopasowania kompetencji, profilu do tego, co będziesz robił, bo zawsze się znajdzie jakiś element, który jest ekstra, nie? Wszyscy piszą w tym i w tym i w tym, a tutaj się pojawi jeszcze jakiś tam smaczek, który jest dodany. I oczywiście czasami to jest łatwiej, czasami jest trudniej, ale jest to jakieś wyzwanie, nie? Problem jest taki, kiedy to zaczyna przeważać. Nagle się okazuje, że masz kompetencje do połowy rzeczy, a do połowy nie masz. Myślę, że też istotna jest wtedy komunikacja znowu, jest bardzo istotna z zespołem i bycie transparentnym z zespołem, żeby zespół wiedział do czego, jakby o co gramy i co chcemy osiągnąć w tym, dlaczego chcemy to robić, bo wydaje mi się, że jakby podejście jako team lead, jeśli podejdzie do tego w ten sposób, że zwyczajnie do zespołu przyjdziesz i powiesz, no słuchajcie, będziemy teraz robić coś, na czym się kompletnie nie znamy.

Trudne pytanie. Co najmniej lubię. Ja łatwo ich nie zadaję. Same trudne dzisiaj. Czego nie lubię w mojej roli? Wiem, czego nie lubię. Jest mi bliżej tego podziału, że osoba, która jest liderem, to powinna być osoba, która jednak trzyma kontakt z rzeczywistością, czyli z produktem, z tym, co robimy i w jaki sposób robimy. No ale oczywiście jest ten aspekt jeszcze zarządzania, pracy z ludźmi. Ja nie lubię kiedy ten drugi czynnik zaczyna się wymykać spod kontroli i zaczyna przeważać tak mocno, że nie mogę się koncentrować na przykład na rzeczach produktowych, Czego co robimy w projekcie, tylko na przykład, nie wiem powiedzmy 90% swojego czasu pracy poświęcam tylko i wyłącznie na rzeczy związane z jakimś administracją i z pracą z ludźmi i nie tylko też z zespołem jakby, bo to czasami też wychodzi poza też zespół, jeśli chodzi o stakeholderów i tak dalej, to tego nie lubię.

Tylko musisz sam to rozumieć i sam przejść do tego i chcieć tego. Tak mi się wydaje. Tak myślę, że tak jest. Jakby nie wyobrażasz sobie sytuacji takiej, że przykładowo pracujesz w zespole, gdzie masz jakiegoś lidera i lider do ciebie przychodzi i ci mówi, że od dzisiaj ty będziesz liderem. To jest sytuacja jakby kuryzalna, coś takiego to nie może mieć miejsca. Oczywiście ty jako, bo teraz jakby trochę mieszam, ale jakby będąc team leadem i obserwując swój zespół czy swoje zespoły, to jakby częścią twojej pracy jest to, żeby wiedzieć kto potencjalnie z tych ludzi może być dobrym materiałem na to, żeby objąć taką rolę. Bo to mówiliśmy też o tych cechach, które są dobre, a które niekoniecznie.