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

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.

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 jestem w stanie zrozumieć, że tam jakaś część twojej pracy na tym polega, że tam powiedzmy dewelopujesz ten produkt i drugą część poświęcasz na właśnie bycie team leadem. I chciałem, żebyś opisał trochę o tym i trochę o tym, jak to wygląda z twojej perspektywy. Ok. Jeśli chodzi o ten aspekt powiedzmy miękki, tego zarządzania powiedzmy zespołem czy zarządzania współpracą z ludźmi, to myślę, że już trochę powiedzieliśmy na ten temat, więc możemy jeszcze do niego może wrócić, ale może skoncentrowamy się bardziej na tym aspekcie technicznym. Dlaczego tak uważam? Mówiliśmy o budowaniu autorytetu wśród zespołu. No i np. ja uważam, że wchodząc do nowego zespołu, w którym masz być liderem, no ja uważam, że zdecydowanie łatwiej ci będzie zbudować ten autorytet, kiedy ci ludzie będą wiedzieć, że ty wiesz, o czym oni do ciebie mówią.

Bo w odwrotnej sytuacji będzie na... Ja myślę, że z doświadczenia mojego, że to będzie trudne. Na pewno będzie to zdecydowanie trudniejsze, A mam też wiele przykładów z pracy, gdzie osoby, którymi pracowałem w zespołach różnych, bezpośrednio udzielały takiej wiadomości, informacji zwrotnej, że zdecydowanie łatwiej pracuje się, dajmy na to, zdecydowanie łatwiej pracuje się z tobą, bo na przykład w ostatniej pracy osoba, która była liderem, no to była osoba, która na przykład nie była techniczna i trudno nam się było dogadywać na przykład na spotkaniach typu planningi, typu retrospekcje, Bo trzeba było na przykład tłumaczyć dlaczego tak albo nie inaczej i często ludzie się też wypalali przez to, bo mieli wrażenie, że przez pół godziny na przykład kręcimy się wokół jednego wątku, ponieważ jedna osoba, która jest team leadem nie potrafi zrozumieć tak naprawdę o co chodzi.

I tutaj nie rozdzielałbym już tego, że lead, w sensie osoba, która jest team leadem z poszczególnymi osobami, czy nie wiem, z niektórymi, czy z bardziej doświadczeniem, nie. To doświadczenie powinno być pomiędzy Jak być dobrym liderem zespołu programistów? Seweryn Łach.. Jak być dobrym liderem zespołu programistów? Seweryn Łach.. W tym samym sytuacji, gdybyś miał do dyspozycji osobę po drugiej stronie, z którą się znasz powiedzmy raptem tydzień czy dwa i nie wiesz, kto to jest, jesteś postawiony w sytuacji, w której team lead cię postawił w sytuacji, kiedy jest, że tak powiem, nóż na gardle i masz drugą taką osobę, no to poziom twojego stresu i strefa komfortu drastycznie się, znaczy strefa komfortu drastycznie maleje, poziom stresu idzie w kosmos, bo ty w ogóle nie jesteś pewien, czy ta osoba będzie w stanie ci pomóc w czymkolwiek.

Więc zaufanie jest mega ważne według mnie. Zgadza się. No, owszem, miałem czasami takie sytuacje, gdzie właśnie nie wiadomo było, czy dana osoba poradzi sobie z tym zadaniem i faktycznie, jeżeli to był taki kluczowy element, no to nie wiem, kontrolować ją, co dwie godziny pytać, jak ci idzie. Bez sensu. No to trochę wracamy do sytuacji, to co mówiliśmy, że jest osoba, która jest team leadem i nie jest techniczna, nie? Czyli idziesz do niej, mówisz, że jest jakiś problem, I zaczynają się pytania, a dlaczego tak, a dlaczego tak, a dlaczego tak, a dlaczego tego nie zrobiłeś inaczej, a to kiedy czasami odpowiadasz na pytania, które są całkowicie bezsensowne i ty wiesz o tym, że to pytanie jest bezsensowne, ale ktoś je zadaje i ty odpowiadasz, więc oczywiście wiadomo, że pewnie jeśli taka sytuacja się wydarzy raz na jakiś czas, no to pewnie nie wpływa to na morale zespołu czy na motywację, ale jeśli to się powtarza tam powiedzmy

Co sprint, co tydzień, czy nawet codziennie, bo są też takie przypadki, znam takie przypadki z życia niestety, że takie sytuacje się powtarzają na porządku dziennym, no to jest bardzo drenujące dla ludzi. Jestem to w stanie wyobrazić i naprawdę nie życzę nikomu. Jakie twoim zdaniem cechy powinny wyróżniać dobrego team leada? Jeśli chodzi o cechy lidera, na pewno myślę, że komunikatywność, bo wpływa na wiele aspektów tych, o których już rozmawialiśmy. Myślę, że na pewno dostępność, bo wydaje mi się, że jak możesz być dobrym liderem, skoro cię nie ma w tym zespole, albo ludzie nie mogą z tobą porozmawiać o różnych rzeczach, czasami nie tylko projektowych, ale też o innych, jakichś problemach, które dotyczą zespołu. To myślę, że to jest kolejna rzecz. Bycie obiektywnym.

Więc to o tym mówię, mówiąc o tym, żeby zachować obiektywność, nie? Czyli bazujemy na faktach. Jeśli coś Jeśli coś jest założeniem tylko, to jest tylko założeniem. Dopóki się nie stanie faktem, to myślę, że dobry lider to jest osoba, która na takich rzeczach nie bazuje. Bazuje tylko i wyłącznie na faktach. Bo to, że ktoś coś powiedział albo ktoś coś zobaczył w kodzie czy na produkcji, to jest dopiero pierwsza część. Dopiero musimy spojrzeć, jak to wygląda. Dopiero wtedy możemy sugerować, jakie jest rozwiązanie, bo po ocenie nigdzie jest problem. Czym się różni dobry team lead od złego team leada? Jeśli chodzi o dobrego team leada, to trochę już powiedzieliśmy o tym. Jeśli chodzi o słabszego czy tam słabego team leada, no niestety miałem gdzieś tam przyjemność w przeszłości pracować albo obserwować takie sytuacje.

A to nie będzie działać wtedy, kiedy on będzie w epicentrum, on na świeczniku jest najważniejszą osobą, najmądrzejszą i tylko wszyscy mają go słuchać. No i co z tego wychodzi? Nic z tego nie wychodzi. Trwało to długo, bo to trwało Z 10 miesięcy taka sytuacja trwała, naprawdę ci ludzie tam tak się wypalili przy tym chłopaku, że to naprawdę trudno to nawet opisać. I to jest przykład bardzo, wydaje mi się, złego team leada. Bycie dobrym programistą nie świadczy o tym, że możesz się być dobrym team leadem. I też powiedziałbym, że team lead to nie jest osoba, która musi być świetnym programistą. Czyli można być, według mnie można być, powiedzmy dobrym programistą i można być świetnym team leadem. I wcale nie chodzi o to, że ty jako team lead musisz być gwiazdą tego zespołu i ty musisz wszystko wiedzieć najlepiej.

To nie o to chodzi. Tobie chodzi o to, że ty masz mieć gwiazdy w zespole, a ty masz tylko wiedzieć jak tym zespołem zarządzać tak, żeby osiągać sukcesy. I wydaje mi się, że to jest bardzo dobre podsumowanie, jeśli chodzi o przykłady złych team leadów. Bardzo mnie się to łączy z tą cechą, o której ty powiedziałeś, czyli zaufanie. Bo to trzeba mieć już takie zaufanie do zespołu, że jak im powierzę te wszystkie zadania, to faktycznie oni sobie poradzą. Dokładnie, bo to też w byciu team leadem polega też, czy też tech leadem, bo to wydaje mi się, że trochę schodzimy do takiej dyskusji, gdzie możemy to trochę połączyć. Generalnie chodzi o to, że musisz dać ludziom swobodę, żeby mogli się wykazać i zrobić to, co do nich należy i to, co potrafią robić i to, dlaczego są w tym miejscu, nie?

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.

Możemy zrobić tam w dwa miesiące coś, co będzie jakby początkiem do tego, taką powiedzmy nakładką, ale to kompletnie będzie bardzo dalekie od tego, czego ty oczekujesz. A ten projekt, żeby go zdekomponować, to zdecydowanie potrzebujemy z miesiąca analizy, żeby usiąść i zastanowić się, jak w ogóle to zrobić. Kompletnie do niego nie trafiało. Za wszelką cenę mamy to zrobić, bo jakby my opowiadamy bzdury, to na pewno będzie działać i wszystko będzie super. No i jedno spotkanie, drugie, trzecie, piąte. To wszystko wiadomo szło tak jak szło. Po piętnastym spotkaniu w końcu dochodzi do sytuacji, kiedy Team Lead wnioskuje, że no to w sumie nie da się tego tak zrobić w prosty sposób. No i mówimy, no bingo, nie da się tego zrobić i jakby rozmawialiśmy o tym przez długi okres. Na co to wpłynęło?

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.

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.

No i super, zaczynamy od jutra. A jak przyjdziesz do zespołu i powiesz, słuchajcie, będziemy pracować nad czymś, nad czym nie do końca się znamy, ale jest plan na to, żeby zrobić tak i tak, bo przez to osiągniemy coś innego. I to nam otworzy furtkę do czegoś, powiedzmy, dalej. Albo taka jest koncepcja. No to wtedy jest całkowicie inna rozmowa z takimi ludźmi, bo jest dyskusja wtedy jakby merytoryczna, że okej, to już nie dyskutujemy o tym, że ktoś nie chce tego robić, tylko dyskutujemy, dobra, to co możemy zrobić, żeby to zrobić jak najlepiej, nie? Wiadomo, że nie zrobimy tego tak, jakbyśmy byli ekspertami w danej dziedzinie i to jest okej, tak? Ale wykładamy karty na stół i rozmawiamy transparentnie o tym, jakie wyzwanie przed nami stoi, nie tylko jakby przed tobą jako team leadem, tylko generalnie przed całym zespołem i ty jako osoba musisz tutaj Co najmniej lubisz w swojej roli?

Zazwyczaj się dużo dzieje, dużo się zmienia, bo robimy rzeczy cały czas inne. No chyba, że projekt się zamyka i jest takie... A, no tak, tak. Albo nie ma projektu przez jakiś czas, no to jest... Zgodzę się. Start projektu, wiadomo, zawsze trochę zamieszania, trochę chaosu. Staramy się zrozumieć co, kto i gdzie powinien zrobić i kiedy. Ale później, dlatego mówię, ciągle mamy nowe projekty, ciągle nowe wyzwania i często robimy różne rzeczy, więc to jest fajna robota. Z doświadczeń, które tutaj przytoczyłeś, rozumiem, że byłeś kiedyś deweloperem, dopiero z czasem przyszedłeś na rolę TL-a. Jak to się stało w twoim przypadku i co byś doradził osobom, które też chciałyby zacząć pracować jako TL? Jeśli chodzi o bycie liderem generalnie, nieważne czy to jest tech lead, czy team lead, czy jakikolwiek inny lead według mnie, to nie jest coś takiego, że się nim stajesz, tylko po prostu nim jesteś.

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.

Natomiast to, co chcę powiedzieć, to to, że tobie jako leadowi, jeśli ty uważasz, że ktoś się do tego nadaje, to jeszcze warunek nie jest spełniony, bo jeszcze ta druga osoba musi tego chcieć. Więc wracając do pytania, jak zostać team leadem czy tech leadem, Uważam, że w pierwszej kolejności to się musi zacząć od tej osoby, która jest tym zainteresowana. I ta osoba musi wykazywać cechy i w jakiś sposób pokazywać wśród zespołu czy wśród ludzi, z którymi współpracuje, że się do tego nadaje. Albo że może nie tyle, że się nadaje, tylko że chce to robić. I może w to pójść i chce się w tym kierunku rozwijać. Myślę, że to jest najważniejsze. I po prostu bycie, że tak powiem, otwartym i prezentowanie swoich oczekiwań i tego, co chcesz robić do osób, z którymi współpracujesz.