Nikodem: Patrz na mnie! Z głowy, nie musisz tworzyć zespołu i później zwalasz na tego, co tworzy zespół.
Seweryn: Dokładnie. Idziesz i mówisz “Przecież ja tego nie złożyłem. Ktoś inny to zrobił”.
Patrzcie na tego bicka.
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 TL-a.
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. Zaczynałem jako programista, głównie koncentrowałem się na C++, przetwarzaniu obrazów, image processing, tak, to było wszystko, to gdzie się to zaczęło, później branża telekomunikacyjna, pracowałem też jako product owner, później stało się, tak się wszystko poukładało, że zostałem engineering menadżerem i w tej roli zostałem przez dłuższy okres i teraz w tym momencie w Grass Valley jestem senior engineering menadżerem i jestem też side leadem naszego biura tutaj w Krakowie. Pracujemy w branży broadcast media, więc produkujemy sprzęt dla stacji telewizyjnych, największych stacji telewizyjnych na świecie, na całym świecie generalnie, więc jesteśmy jednym z liderów, jeśli chodzi o tę branżę. Produkujemy sprzęt między nimi taki, jak tutaj masz na na stole: kamery, switche, routery, różnego rodzaju konwertery do przetwarzania audio i video, audiomiksery, także jest tego bardzo, bardzo dużo. Jest to wykorzystywane podczas eventów live typu koncerty, wydarzenia sportowe, Mistrzostwa Świata, olimpiada, teraz nadchodzące mistrzostwa w Katarze, również tam nasz sprzęt będzie wykorzystywany. I to jest cały świat jakby hardware’owy, którym się zajmujemy, natomiast również jesteśmy, tworzymy naszą nową platformę cloudową AMP – Agile Media Processing Platform, która jest takim powiedzmy software’owym odzwierciedleniem wszystkiego, co było do tej pory hardware’owe z wykorzystaniem wirtualizacji, nowych technologii, coś, co pozwala na elastyczność, remote production, czyli pozbycie się tego elementu, że jakby w studiu nagraniowym jakby nie musimy mieć skoncentrowanych wszystkich ludzi, natomiast możemy mieć rozproszoną produkcję, czyli dyrektor produkcji może sobie siedzieć w Europie, operator audio mixera może sobie siedzieć w Waszyngtonie, ktoś inny jeszcze może siedzieć gdzieś w innym państwie i tak dalej.
Za co jesteś odpowiedzialny w pracy?
Wow, jeśli chodzi o tę firmę to tak naprawdę cała historia zaczęła się blisko 18 miesięcy temu mniej więcej w Krakowie, kiedy powstało, kiedy zaczęło powstawać to biuro, 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ę, budowanie zespołu R&D tutaj w Krakowie co wydaje mi się, że może po części pomoże mi podzieleniem się podczas tego podcastu jakby 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, 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, 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 menadżera, czy tam product menadżera 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ęca również na rzeczy praktyczne, czyli też uczestniczy tam czy to w testowaniu, czy wytwarzaniu programu.
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 szczegółu, który 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 tak to określił.
W jaki sposób przejawiała się u ciebie taka rola?
Każdy leader może zrobić 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ć. Uważa, ż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, żeby były transparentne i zrozumiałe dla zespołu i myślę, że to pozwala scalać zespół.
Opowiadasz tutaj bardzo tak ogólne definicje tego, jak to wygląda. Czy mógłbyś to oprzeć na jakimś przykładzie?
Myślę, że dobrym dobrym przykładem jest chociażby to, że pracując powiedzmy przez lata z różnymi zespołami developmentowymi, czy scrumowymi to prawda jest taka, że zespół tworzą ludzie. Każdy w tym zespole może mieć różną osobowość i różne cechy charakteru i kiedy mówimy o scalaniu to oczywiście możemy mówić o takich twardych umiejętnościach, ale koniec końców, jeśli chodzi o scalanie ludzi to też musimy musimy coś powiedzieć na temat tych miękkich umiejętności i myślę, że w każdym zespole, to znaczy najfajniejsze są takie zespoły, gdzie mamy różnorodność osobowości i cech charakteru, że nie ma takiej monotonii, marazmu, która się może wkraść do zespołu, gdzie mamy na przykład, nie wiem, 5-8 osób, które mają bardzo podobny typ charakteru czy typ osobowości. Albo też znowu z drugiej strony, jeśli mielibyśmy nie wiem, ośmiu ekstrawertyków w zespole, to można się domyślić do czego by to mogło doprowadzić. Mogłoby być dużo fanów, natomiast niekoniecznie mogłoby to się przekładać na jakąś tam 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, 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ć 2, 3, 4 zespoły, 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, bo tak jak właśnie możesz popatrzeć na te charaktery, czy 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 dołączyłeś do zespołu, w którym ludzie już są i musisz teraz sobie z nimi poradzić?
Jasne, 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. To zależy kto ma jaki charakter i kto ma jaką osobowość. Ja bym powiedział, że możesz wejść w 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 kątach 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ę. Ludzie między sobą w zespole niekoniecznie muszą się znać na wylot pod kątem zachowania, cech charakteru, osobowości, ale wydaje mi się, że ty jako lider, to właśnie jest to, co zbuduje twoją zaletę i twój autorytet i twoją przewagę. Znaczy przewagę, przewagę taką, że znasz tych ludzi, wiesz, w jaki sposób, w jakich sytuacjach na kim możesz polegać. Ludzie mają różne że tak powiem zestawy umiejętności. Jedna osoba może być bardzo dobra w jednym, inna w drugim i ty jako lider tego zespołu jesteś od tego, żeby rozumieć takie potrzeby i przykładowo, jeśli masz potrzebę, żeby wysłać kogoś do zrobienia demo z klientem wiesz, kogo chcesz wysłać na to spotkanie, bo wiesz, że ta osoba zrobi super robotę, a niekoniecznie wybierzesz kogoś innego, kto się nie czuje w tej sytuacji całkowicie komfortowo. Nie dość, że będzie się stresować, nie będzie z tego zadowolona, w ogóle zysk będzie zero i dla ciebie, i dla tej osoby, i dla całego zespołu, więc to jest dobry przykład. I takich przykładów jak ten bardzo wiele miałem w przeszłości dotyczących czy to na przykład jakiegoś code review, czy spotkania z innym z zespołem, czy spotkania z architektem, czy z klientem, gdzieś tak powiedzmy jakiegoś nagłego przypadku, który wyszedł powiedzmy z jakimś błędem z produkcji. 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ą korzystne dla całego 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 dewelokujesz 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?
Okej, 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 skoncentrowałbym się bardziej na tym aspekcie technicznym. Dlaczego tak uważam? Mówiliśmy o budowaniu autorytetu wśród zespołów. No i na przykład ja uważam, że wchodząc do nowego zespołu, w którym masz być liderem, 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 ja myślę, że z doświadczenia mojego, że to będzie trudne. Znaczy na pewno będzie to zdecydowanie trudniejsze, a mam też wiele przykładów z pracy, gdzie osoby, z 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 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.
Zgadzam się z tobą tutaj w 100%, bo też z perspektywy programisty widzę, że jest jeden, który rozumie dany temat, rozumie wszystkie zagadnienia, dużo łatwiej się rozmawia. Czasami pojawia się jakiś problem i w momencie, w którym każda ze stron rozumie, gdzie problem leży, łatwiej jest później ustalić jakieś kroki, podjąć odpowiednie decyzje.
Myślę, że bardzo często dochodzimy do sytuacji, kiedy tak naprawdę unikamy wielu, jakby to powiedzieć, dyskusji i pułapek, bo inaczej sytuacja wygląda, kiedy idziesz do swojego leada i mówisz mu o tym, że słuchaj, stary, jest problem z tym i z tym, bo na przykład nie wiem, w testach, czy w weryfikacji, czy w implementacji mamy problemy nie wiem, z legacy kodem, czy z czymś i nie jesteśmy w stanie tego zrobić tak jak zakładaliśmy na środę, tylko potrzebujemy jeszcze tygodnia i do gościa, do 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, w tym momencie zaczyna się. Zaczynają się pytania.
To co, nie możecie usunąć i wstawić na nowo? Jaki jest problem, o co chodzi?
Dokładnie, i tutaj znowu dochodzimy do momentu, kiedy przechodzimy w kwestie zaufania, do 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łów.
Masz na myśli do 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ć, żeby ta współpraca była bardzo efektywna, jest zaufanie wśród zespołu. 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świadczonymi, nie, to doświadczenie powinno być pomiędzy każdym węzłem że tak powiem w tej układance. I co to daje? Daje to bardzo dużo, bo całkowicie inaczej pracuje się z osobami, do których masz pełne zaufanie i jeśli pójdziesz do tej osoby i powiesz jej “Słuchaj, potrzebujemy zrobić to, to, i potrzebujemy to na piątek”, a jest na przykład środa, jesteście w trudnej sytuacji, ale sprawdziłeś się, że tak powiem z tą osobą już kilka razy i wiesz o tym, że sobie poradzicie. W tej samej sytuacji, gdybyś miał do dyspozycji osobę po drugiej stronie, z którą się znasz powiedzmy raptem tydzień, czy dwa, nie wiesz kto to jest, jesteś postawiony w sytuacji, 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 maleje, poziom stresu idzie w kosmos, bo ty w ogóle nie jesteś pewien, czy ta osoba będzie w stanie ci pomóc z czymkolwiek, więc zaufanie jest mega ważne według mnie.
Zgadza się. 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, 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, czyli idziesz do niej mówisz, że jest jakiś problem i zaczynają się pytania “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 się taka sytuacja wydarzy raz na jakiś czas, to pewnie nie jest to jakoś bardzo, nie wpływa to na morale zespołu, czy na motywację, ale jeśli to się powtarza tam powiedzmy co sprint czy co tydzień, czy nawet codziennie, bo są też takie przypadki, znam takie przypadki z życia niestety, że takie sytuacje się powtarzają na początku dziennym, 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 jakby wydaje mi się, że jak możesz być dobrym leaderem, 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 myślę, że jest bardzo ważne. Myślę, że dobry leader 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, w sensie nie wiem, czy spotkałem się ze scenariuszem, kiedy była ona aż taka istotna, mógłbyś jakiś podać 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 dajmy 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ć w to zaangażowane 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 i nagle tworzy się jakaś niesamowita historia wokół tego i może być oczywiście naturalną rzeczą, presja się tworzy, osoba, która rozmawia z klientem może być też zdenerwowana, może rosnąć presja i ciśnienie, może w to być zaangażowany jeszcze ktoś powiedzmy z technical supportu, nagle może być jeszcze ktoś zaangażowany z, że tak powiem, z działu sprzedaży, czy od klienta account menadżer i robi się z tego burza. Myślę, że w takiej sytuacji ważne jest to, żeby zachować zimną krew do końca i leader powinien bazować na faktach. Nie na tym, co usłyszał czy przeczytał w mailu, który był napisany dużą czcionką i drukowanymi literami z wykrzyknikami, co uważam, że jest słabe, tak czy inaczej, albo to, że pięć osób krzyczy na telefonie do niego i jakby próbują rzucić winę na jedną osobę, ale tak naprawdę jeszcze nie wiadomo co się wydarzyło i tak naprawdę nie wiadomo jeszcze do kogo i z czym pójść, więc o tym mówię, mówiąc o tym, żeby zachować obiektywność, czyli bazujemy na faktach. 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 leader 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 albo opcjonalnie gdzie 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, jakby no niestety miałem gdzieś tam przyjemność w przeszłości pracować albo obserwować takie sytuacje, że niestety osoba, która była na takim stanowisku, niekoniecznie dobrze sobie radziła z zespołem. Wynikało to z, mam kilka takich przypadków. Jeden przypadek to był taki gdzie chłopak, który był liderem zespołu, miał bardzo dobrą wiedzę techniczną, praktycznie gdzieś tam powiedzmy, że na poziomie architekta nawet, więc totalnie wszystko rozkminiał co się dzieje. W zasadzie znał odpowiedź na każde pytanie, miał ułożoną wizję w głowie wszystkiego tylko co – problemem głównym było to, że nie potrafił sprzedać tej wizji ludziom, którzy z nim pracowali. To było tak trudne dla tych ludzi, którzy z nim pracowali, bo widziałem, że ci ludzie byli bardzo oddani pracy i byli bardzo zmotywowani i wkładali w to dużo serca, natomiast on swoją osobą to wszystko psuł. To, co on chciał zrobić to on tylko miał w swojej głowie i on nie potrafił tego przełożyć do ludzi i powiedzieć im co mają zrobić, jak mają zrobić. On uważał, że wszystko robi najlepiej i uważał, że to wszystko, co on myśli, wszyscy, każdy powinien to rozumieć, przecież rozmawiamy o tym już tak długo, że już dwa czy trzy tygodnie, ten projekt trwa dwa miesiące, wszyscy powinni to wiedzieć, a on generalnie zmieniał swoje założenia, co tydzień miał jakieś inne założenia w swojej głowie, które on tylko znał i jakby dużo rozmów mieliśmy na ten temat, że musi zmienić swoje nastawienie i musi bardziej dbać o to, że to nie chodzi o to, że on musi zrobić wszystko od początku do końca tylko chodzi o to, żeby on współpracował z nimi. Oni muszą zrozumieć koncepcję, muszą zrozumieć to, jaki jest cel, co chcą osiągnąć, bo tylko wtedy to może działać. 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 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że się być dobrym team leadem i też powiedziałbym, że team lead to nie jest osoba, która musi być świetnym programistą, czyli 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 mi 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ż bycie team leadem polega też na byciu tech leadem. Wydaje mi się, że trochę schodzimy do takiego, 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. Bo w końcu jednak skądś się tutaj wzięli, jeśli ty budowałeś ten zespół to nie przyszli tutaj jakby z przypadku, tylko zdecydowałeś, że oni tu przyjdą, jeśli nawet ktoś inny o tym decydował to okej, decydował, więc rozmawiajmy o tym albo rozliczajmy ludzi z tego, co robią, albo co powinni robić, a nie z tego, co ty uważasz, albo co tobie się wydaje. Nawet jeśli jesteś team leadem no 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, mieliśmy taką sytuację, że team lead zaproponował zrobienie pewnego feature’a, który miał pewne fajne rzeczy robić. Generalnie idea była super, bo była 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 czy może myślał, że rozumie jakby górę, wierzchołek góry lodowej, i że to wystarczy, i generalnie stwierdził, że no ma tutaj feature, na który potrzeba tam dwóch, trzech osób, maksymalnie na 4, 6 sprintów i temat będzie załatwiony. Oczywiście już przy pierwszym takim spotkaniu wiadomo, że dobra, okej, usiądźmy, zobaczmy, co jest do zrobienia, więc zrobiliśmy krótką analizę tego, co jest, no i okazało się niestety, że to są problemy jakby z legacy kodem, który nie pozwala na wprowadzenie tego w taki prosty sposób, tylko że będzie się to wiązało, dotykało bazy danych, konfiguracji i tam była mowa o tysiącach parametrów, które tam były do zmiany. Masa rzeczy, które wpływały na kolejne tysiące rzeczy, więc jakby daliśmy mu do zrozumienia, że stary, nie da się tego zrobić. 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ć, 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 15 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 i 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 dwie, trzy zespoły, takiej mały ficzerek do zrobienia na 4, 6 sprintów. Taki był finał. Jaki jest tego wniosek? No wniosek jest z tego taki, że dobry team lead też powinien słuchać tego, ale to wracamy do kwestii zaufania. Jednak jeśli pracuje 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, 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 tej 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, ten gość sam sobie podburza autorytet przed zespołem, bo następnym razem przyjdzie i co, dalej chce zrobić w podobny sposób?
Czy masz jakiś taki przykład, kiedy ty byłeś w roli TL-a i spotkało cię jakieś takie duże wyzwanie?
Nie no, na pewno bym skłamał, gdybym powiedział, że nie było trudniejszych sytuacji, z jakimi bym się musiał zmierzyć. Wynikały często z różnych rzeczy. Zaczynając nawet do najprostszych, że dajmy na to, współpracujesz z zespołem no i masz powiedzmy jakiś tam zakres kompetencji, które 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. 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. 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 i bycie transparentnym z zespołem, żeby zespół wiedział, do czego, o co gramy i co chcemy osiągnąć 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ś, na 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, 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. Wiadomo, że nie zrobimy tego tak, jakbyśmy byli ekspertami w danej dziedzinie i co jest okej, 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 zdecydowanie wykazać się jeszcze bardziej proaktywnie niż w zwykłej sytuacji powiedzmy tradycyjnej, żeby też utrzymać jakoś powiedzmy tę motywację i cel, do którego zmierza zespół.
Co najmniej lubisz w swojej roli?
Trudne pytanie, co najmniej lubię?
Bo ja łatwych nie zadaję.
Same trudne dzisiaj. Czego nie lubię w mojej roli? Wiem czego nie lubię. Jest mi bliżej tego podziału, że osoba jedna która jest liderem to powinna być osoba, która jednak trzyma kontakt jakby z rzeczywistością, czyli z produktem, z tym, co robimy, w jaki sposób robimy, 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, czyli tego, 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 jakąś administracją i z pracą z ludźmi, i nie tylko też zespołem jakby bo to czasami też wychodzi poza też zespół, jeśli chodzi o stake holderów i tak dalej, to tego nie lubię. A no to wiadomo, że to jakby różnie bywa, czasami to jest zależne od sytuacji gdzie jesteśmy w projekcie, ale to ja osobiście tego nie lubię. Lubię jednak cały czas jakiś tam powiedzmy kontakt z tym trzymać, żeby rozumieć, o czym rozmawiamy i dyskutujemy, bo jeśli tego brakuje to czuję się trochę taki niepotrzebny.
To teraz odwrotne pytanie, jaka jest twoja ulubiona rzecz w pracy?
W swojej pracy co lubię w swojej roli? Myślę, że wszystko lubię. Generalnie to, znaczy to jest ciekawe, bo lubię jak jest dużo wyzwań, lubię jak się dużo dzieje, jak się coś zmienia, nie lubię takiego marazmu, monotonii. A w zasadzie w naszej pracy jak w pracy w IT to chyba nie wiem, rzadko kto może narzekać chyba na taki marazm, monotonię, zazwyczaj się dużo dzieje, dużo się zmienia, bo robimy rzeczy cały czas inne.
Projekt się zamyka. Albo nie ma projektu przez jakiś czas i to jest nudne, zgodzę się.
Start projektu wiadomo, zawsze trochę zamieszania, trochę chaosu, staramy się zrozumieć co, kto i gdzie powinien zrobić, i kiedy. 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 przeszedł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 technik, 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. Nie wyobrażam sobie sytuacji takiej, że wiesz, przykładowo pracujesz w zespole, gdzie masz jakiegoś lidera i lider do ciebie przychodzi i ci mówi, że teraz od dzisiaj ty będziesz liderem. To jest sytuacja jakby kuriozalna, coś takiego 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 twoją 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 ja to, co chcę powiedzieć, to to, że tobie się wydaje jako leadowi, jeśli ty uważasz, że ktoś się do tego nadaje to jeszcze nie jest warunek, 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 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, nie ma w tym nic złego myślę.
Mając takie doświadczenie, jakie masz teraz, jakie byś dał sobie wskazówki na samym początku swojej kariery TL’a?
Na pewno to, co się zmieniło przez te lata kiedy pracuję w IT, to kiedy zaczynałem miałem na pewno dużo bardziej nastawienie pro twarde umiejętności, techniczne umiejętności tylko i wyłącznie, taki stuprocentowy focus, że będąc przekonany, że, jak to wiesz, młody programista, że jak będę technicznie wszystko zamiatał, wymiatał i bez względu na wszystko, to się wszystko ułoży, że jakby to wszystko będzie działać. No i niestety myślę, że doświadczenie mnie zweryfikowało i lata mnie zweryfikowały, że tak nie jest, że wchodzi ten aspekt jednak miękki relacji z ludźmi, który jest bardzo istotny, jeśli chodzi o umiejętności liderskie, bycie liderem, więc to by była chyba taka moja główna rada dla osób, które chcą. Pierwsza, to tak, znaczy inaczej może, pierwsza to byłaby taka, to, co powiedziałem wcześniej, że na pewno musisz tego chcieć i musisz dążyć do tego, w sensie świadomie, to nie ma w tym nic złego, żebyśmy robili w życiu to, co chcemy robić i pokazywać, że mnie na przykład to interesuje i na przykład wiesz, chcę to, znaczy pytanie, kto to zrobi, no to ja to zrobię, bo chcę to robić, bo mnie to interesuje, to, że się na tym jeszcze nie znam to okej, jak ktoś zaczyna coś nowego to nikt się na tym nie zna, każdy kiedyś zaczynał, to jest jedna rzecz, a druga rzecz to jest to, żeby nie ulegać według mnie takiej iluzji, że pracując w IT, wszystko tylko i wyłącznie kręci się wokół umiejętności twardych. Oczywiście one są bardzo ważne i uważam, że bez nich jest bardzo trudno, ale na pewno nie zapominać o aspekcie umiejętności miękkich interpersonalnych i inwestować w to. Czytając książki czy nie wiem, jakieś meetupy czy podcasty, tego typu rzeczy, to dużo daje.
Bardzo fajnie, poruszyłeś teraz temat, o który chciałem cię zapytać, a mianowicie w jaki sposób się doszkalasz na tym stanowisku?
Znaczy na początku wydaje mi się, że fajnie udać się na różne szkolenia, natomiast w pewnym momencie też wydaje mi się, że jeśli nabierzesz już pewnego doświadczenia, czy to ze szkoleń, czy potem z czytania książek, czy jakiejś powiedzmy, czy artykułów i tak dalej, to potem jakby czytając kolejną to wydaje mi się, że wszystko polega na tym, że ty weryfikujesz wszystko to, co przeczytałeś, łącznie z tym, co masz w głowie i jakby to jest takie coś, co się cały czas dodaje do siebie i czytając kolejną znowu próbujesz zweryfikować, że okej, dobra, to przeczytałem coś, a gdzieś było napisane co innego i starasz się gdzieś tam kalibrować to swoje, w sensie co ty myślisz finalnie i tak jakoś to leci do przodu, i jeszcze dodatkowo dodając do tego doświadczenie z pracy, z dnia codziennego, to jest kolejny element, który też zmienia to wszystko, bo wiadomo że możesz chodzić na szkolenia, możesz czytać książki, możesz przeczytać cały Internet, a koniec końców praktyka jest praktyką. A praktyka według mnie wygląda całkowicie inaczej i tak samo, jeśli ktoś nie ma żadnego doświadczenia technicznego a próbuje pracować z zespołem technicznym to też będzie trudno, bo teoria to jedno, a praktyka to drugie.
Dzięki Seweryn, bardzo fajna rozmowa, cieszę się, że zgodziłeś się do nas wpaść i opowiedzieć o roli TL’a. Ja też się wiele nauczyłem z tego, bo poznałem taką twoją perspektywę, także dziękujemy.
Dziękuję również za zaproszenie, bardzo fajnie było pogadać.
Dziękuję również naszym widzom oraz słuchaczom. Mam nadzieję, że odcinek wam się podobał, zachęcamy do zostawiania subskrypcji, lajków oraz komentarzy i widzimy się za dwa tygodnie, cześć!
________________________________________________________
Podcast DEVision to polski podcast IT dla programistów, którzy chcą rozwijać swoją wiedzę, posłuchać o ciekawych projektach oraz zainspirować się innymi. A to wszystko w przyjemnej formie rozmowy, której możesz słuchać w tramwaju, na siłowni, a nawet w pracy 😉
💌 Zapisz się do naszego newslettera: https://bit.ly/37TTNCK
🌏 Więcej o nas przeczytasz na stronie: https://bit.ly/3Pttiox
Obserwuj nas na social media: 🚀
LinkedIn: https://bit.ly/3PxlHFQ
🎧 Spotify: https://spoti.fi/39xU0fm
🎧 iTunes: https://apple.co/3PsjhrQ
Jeśli Ci się temat spodobał, subskrybuj nasz kanał, bo dopiero się rozkręcamy z gorącymi tematami! 🙂
