To jest 267. odcinek podcastu Porozmawiajmy o IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT w SolidJobs, który mam przyjemność współtworzyć, dyskutujemy o tematach związanych z byciem liderem i zarządzaniem zespołem IT.

Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania.

Odpalamy!

 

Cześć, Łukasz!

 

Cześć, Krzysztof!

 

Spotykamy się po raz kolejny w ramach specjalnego cyklu podcastu Porozmawiajmy o IT. Jest to cykl dedykowany liderom i managerom IT. Dzisiaj dotkniemy niezwykle istotnego tematu, o którym pewnie dałoby się nagrać wiele odcinków, ale spróbujemy wyciągnąć dzisiaj jego kwintesencję – będziemy mówić o budowaniu zespołów IT oraz o zwinnym zarządzaniu tymi zespołami, bo jakby nie było, pracujemy w branży IT właśnie w zespołach i ta atmosfera, która panuje w zespole, przekłada się jednoznacznie na to, jakie są wyniki naszej pracy, jak szybko, jak sprawnie i z jaką jakością dowozimy tematy, więc temat jest właśnie niejako miękki, ale przekłada się de facto niezwykle istotnie na nasz technologiczny output i rezultat naszych działań.

Spojrzymy sobie więc na różnego rodzaju taktyki, podejścia, i myślę, że warto byłoby rozpocząć od zastanowienia się, kim ta osoba, która buduje, rozwija zespół i nim zarządza, jest. Nazwijmy ją sobie ogólnie liderem. Możemy się oczywiście kłócić, czy lepszym określeniem jest manager, być może są to wręcz dwie różne role, ale jestem ciekawy Twojego spojrzenia, Łukasz, kim dla Ciebie jest lider.

 

Dla mnie lider w zespole to taka osoba, do której można przyjść ze swoim problemem, i ona pomoże Ci go rozwiązać. Niekoniecznie rozwiąże go za Ciebie, bo może to nie jest akurat ten rodzaj pomocy, ale na pewno popchnie Cię w dobrym kierunku. Jest też ekspertem w domenie. Np. jeśli robimy, załóżmy, oprogramowanie medyczne, to wie o tych receptach co nieco i będzie umiał wskazać oczywiste błędy. Po prostu zna bardzo dobrze domenę i sam system, jego architekturę i jest w stanie spojrzeć na wszystko z lotu ptaka, a nie tylko z tej jednej, konkretnej zmiany, którą teraz robimy. I potrafi myśleć też o konsekwencjach podejmowanych decyzji, a więc nie tylko tu i teraz, ale bardziej umysł strategiczny. Mamy jakąś decyzję do podjęcia i to nie jest tak, że się zastanawiamy tylko w tej naszej małej domenie, małym wycinku problemu, tylko patrzy na konsekwencje dla całego systemu.

 

Oczywiście zgadzam się z tym, co powiedziałeś, natomiast wg mnie jest to tylko pewien rodzaj lidershipu, tzw. lidership techniczny, który często jest połączony, tak jak wskazałeś, z mentoringiem. Że traktujemy taką osobę jako mentora, do którego możemy przyjść po jakąś poradę, która być może wyznaczy kierunki rozwoju technicznego właśnie projektu, ale są też pewnie osoby w zespołach, które niekoniecznie muszą być takimi technicznymi ekspertami, ale są to osoby, które w jakiś sposób pociągają inne do tego, żeby dokonywać pewnych zmian, żeby robić jakieś eksperymenty, podejmować, być może, pewien dodatkowy trud.

Czyli to są takie osoby, które potrafią zarazić inne do tego, żeby poszły za nim, potrafią przekonać, być może nawet wpłynąć na te osoby. I tutaj możemy rozgraniczyć taki lidership formalny, z nadania, że ktoś po prostu zostaje np. CTO, team liderem, managerem, jest w tym drzewku organizacyjnym w takiej roli i po prostu do niego raportujemy. Idealnie by było, jeśli taka osoba będąca managerem jest też liderem. Czyli nie tylko daje nam zgodę na urlop, ale również potrafi przyciągnąć do swojej idei innych członków zespołu.

Ale nie zawsze oczywiście tak jest. I wtedy różne problemy i tragedie w zespołach się dzieją.

 

Tak, jeszcze patrząc na to inaczej, to lider może być formalny lub może to być osoba, która nie ma formalnego nadania, ale ma autorytet w zespole, i na którą inni członkowie zespołu patrzą i starają się mu dorównać.

Też bardzo ciekawy przykład był w serialu Ostatni taniec o Chicago Bulls, czyli przykład Michaela Jordana, gdzie była to osoba, która gdzieś tam po treningu jeszcze zostawała i trenowała rzuty za trzy, a potem było tak, że już cały zespół zostawał razem z nim. On nie miał złych nałogów i inni patrzyli na niego i chcieli być tacy jak on i sobie przed tym meczem nie walnęli tej gorzałki czy czegoś, a wcześniej różnie bywało.

 

Właśnie, ten nieformalny lider, tak jak powiedziałeś, z autorytetem zdobywa ten autorytet w boju najczęściej. To jest po prostu ktoś, kto w jakiś sposób się zasłużył, pokazał, że jest w czymś dobry, że można z niego brać przykład. I tutaj takie formalne nadanie, czyli ktoś, kto pojawia się nagle, ale nie ma tych zasług, może rodzić jakieś zgrzyty. Tymczasem jeśli ramię w ramię pracujemy z takim nieformalnym liderem, to łatwiej jest nam później zaufać, podążyć za tą osobą, ponieważ wiemy, co sobą reprezentuje.

Więc myślę sobie, że lider w ogólności powinien dawać przykład, być taką pierwszą osobą, która dokonuje jakichś zmian, jeśli chcemy je wprowadzić w zespole, jest swego rodzaju przykładem.

I tutaj z kolei ja może podeprę się jakąś książką czy przykładem, bo bardzo fajnie jest to pokazane w książce Extreme ownership Jocko Willinka, osoby, która jest oczywiście związana z wojskiem, ale jednoznacznie to, co próbuje w tej książce pokazać, to żeby ta rola lidera to była rola osoby, która jest w boju, która również sobie brudzi te ręce pracą, a nie tylko wskazuje kierunki gdzieś tam z wysokiego stołka.

Myślę, że to jest niezwykle istotne. W ten sposób zdobywa też autorytet i buduje sobie kapitał, który być może ta osoba będzie musiała później wydać. Raz zarabia ten kapitał, np. przysługując się w jakiś sposób komuś lub całemu zespołowi, będąc swojego rodzaju tarczą, filtrem, jeśli chodzi o zewnętrzny świat, ale czasami będą pewnie takie sytuacje, że będzie musiała jakąś osobę z tego zespołu poprosić np. o dodatkową pracę, o jakąś dodatkową rzecz, wydając ten kapitał. Natomiast zawsze oczywiście warto jest mieć tego kapitału więcej w zanadrzu.

 

Myślę, że tutaj możemy jakoś sprawnie przejść do kolejnego punktu, czyli do budowania zespołu i do roli lidera w budowaniu tego zespołu. Myślę, że to jest trochę tak, że ten zespół otacza lidera i lider jest osobą, która ma jakieś kompetencje i się nimi dzieli z członkami zespołu i to sprawia, że zespół w którąś stronę podąża, staje się cały ekspertem w którymś tam kierunku. To jest jedna sprawa.

Druga sprawa to jest to, żeby też nie było tak, że polegamy zawsze na tej jednej osobie. Żeby te kompetencje w zespole jednak rozkładały się i żebyśmy umieli budować tak zespół, żeby ta odpowiedzialność leżała na całym zespole, a nie na pojedynczych osobach.

Druga sprawa to jest to, żeby też nie było tak, że polegamy zawsze na tej jednej osobie. Żeby te kompetencje w zespole jednak rozkładały się i żebyśmy umieli budować tak zespół, żeby ta odpowiedzialność leżała na całym zespole, a nie na pojedynczych osobach.

 

To jest, myślę sobie, też jakiś kolejny etap zaawansowania czy też rozwoju lidera, czyli delegowanie zadań. Czyli takie też odpuszczenie i pozwolenie sobie na to, żeby to inni wykonali coś, co wcześniej wykonywał ten lider. 

Na początku to może być trudne, niewygodne, może się na początku okazać, że spada trochę wydajność, bo wiadomo, ze osoby z zespołu muszą się pewnych rzeczy nauczyć, zanim zaczną to robić na takim samym poziomie, jaki wcześniej reprezentował lider, ale w większości przypadków oczywiście okazuje się, że po jakimś tam czasie zespół nie tylko dościga, ale i prześciga to, co wcześniej wnosił ten lider, ale pod warunkiem, że ten lider da taką możliwość, żeby zespół brał tę odpowiedzialność.

Więc znowu wrócę do tej książki Extreme ownership, żeby brał odpowiedzialność, żeby cała organizacja dawała taką możliwość, i do tego z kolei niezbędne jest oprócz przyzwolenia lidera, organizacji zbudowanie pewnego zaufania wewnątrz zespołu do tego, że po pierwsze nie jest wielkim problemem, jeśli zespół popełnia jakieś błędy, pod warunkiem że się czegoś nauczy, że coś z tego wyciągnie. Czyli taka kultura przyzwolenia na popełnianie błędów.

I jeszcze jedna rzecz, o której tutaj może nie wspomnieliśmy, a która jest wg mnie w ogóle takim pierwszym elementem niezbędnym do tego, żeby jakikolwiek zespół mógł powstać, tj. budowanie relacji. Nie tylko w ramach osób, które na co dzień pracują w zespole, ale też budowanie tej relacji ze strony lidera. 

Czyli poleganie na tym, jakiego typu relacje są zbudowane, poleganie na tym, w jaki sposób razem coś realizujemy i jakiego typu doświadczenia wyciągnęliśmy z tej współpracy, bo to zaufanie właśnie rodzi się z tego, że relacje są wcześniej zbudowane. A tym bardziej, jeżeli jesteśmy na pozycji takiego nieformalnego lidera.

Czyli przekładając na zespół IT: mamy jakiś pomysł na zmiany, chcielibyśmy np. wprowadzić jakąś nową bibliotekę, być może jakieś nowe podejście architektoniczne, ale nie jesteśmy CTO, nie jesteśmy team liderem, wypadałoby przekonać innych do naszego pomysłu. I właśnie na bazie wcześniej zbudowanych relacji, na bazie zbudowanego wcześniej zaufania jesteśmy w stanie przekonać innych, zdobyć ich akceptację do tego pomysłu. Natomiast jeżeli  absolutnie nie będziemy o te relacje dbać i nie będziemy w żaden sposób pomagać innym, bo to też jest element budowania relacji, to kiedy  będziemy chcieli te osoby do czegoś przekonać, to oczywiście będzie to niezwykle trudne.

Więc ja bym powiedział, że lider to jest też taka osoba w zespole, która cały czas o te relacje dba, cały czas pielęgnuje ten ogródek i cały czas stara się, żeby zaistniało zdrowe podejście do tych relacji w zespole.

 

Tak, myślę, że kluczowym elementem dla zespołu to po pierwsze poczucie sprawczości, a po drugie rzeczywista sprawczość, czyli żeby mogli podejmować te decyzje. Więc musi być zaufanie do zespołu, i musi być ktoś, kto stoi za tym zespołem i go wspiera, i pozwala też czasami na jakieś błędy, ale musi to być tak, ze jeśli mamy jakiś fajny pomysł, to musimy mieć możliwość jego realizacji. Wiadomo, nie każdy pomysł jest możliwy do realizacji albo sensowny, ale żeby dało się chociaż przegadać tego typu inicjatywę, nie możemy dusić inicjatywy członków zespołu, tylko musimy dawać tę możliwość rozwoju i brania odpowiedzialności.

A jak myślisz, bo mówiłeś o budowaniu tych relacji, czy to jest trudniejsze albo w ogóle możliwe w zespołach pełni zdalnych?

Tak, myślę, że kluczowym elementem dla zespołu to po pierwsze poczucie sprawczości, a po drugie rzeczywista sprawczość, czyli żeby mogli podejmować te decyzje. Więc musi być zaufanie do zespołu, i musi być ktoś, kto stoi za tym zespołem i go wspiera, i pozwala też czasami na jakieś błędy, ale musi to być tak, ze jeśli mamy jakiś fajny pomysł, to musimy mieć możliwość jego realizacji.

 

Z pewnością są dodatkowe wyzwania, na szczęście można się w tym wspomóc, korzystając z narzędzi online, albo to, co często jest robione przez firmy, które zatrudniają osoby w modelu zdalnym, czyli co jakiś czas organizujemy jakieś zjazdy, różnego typu spotkania, okazje, żeby jednak raz na jakiś czas te osoby mogły się spotkać.

Ja już od wielu lat pracuję zdalnie i muszę przyznać, że wchodząc do jakiegoś nowego projektu, jeśli mam możliwość odwiedzić tę główną siedzibę firmy i przynajmniej dzień, dwa zobaczyć się z tymi ludźmi, to jednak później pracuje mi się z nimi łatwiej, nie są tacy anonimowi, tylko są jacyś i przywołują obraz konkretnej osoby, jeśli nawet piszę z tą osobą na Slacku i jej nie widzę.

Myślę, że to jest istotne dla nas jako ludzi, żeby gdzieś tę więź utrzymywać. Ale to jest jak gdyby tylko jeden aspekt tego wszystkiego, Drugi aspekt budowania tych relacji, niezależnie od tego, czy to jest praca zdalna, czy stacjonarna, czy hybrydowa, jest to, żebyśmy faktycznie też angażowali się w pomoc innym. Żebyśmy próbowali pomóc w realizacji celów innych osób. Wtedy powstaje jakaś taka więź i chęć do pomocy zwrotnej.

To jest oczywiście niełatwe, wiadomo, zawsze jest tej pracy więcej, niż by się dało przerobić, mamy swoje projekty, cele i taski do dowiezienia, a gdzie tu jeszcze angażować się w pomoc innym, ale myślę sobie, że w dłuższej perspektywie to popłaca i prędzej czy później się spłaci. Więc nawet jeśli pracujemy zdalnie, to możemy w jakiś sposób wspierać innych swoją wiedzą, być może jakąś swoją pomocą w zbadaniu problemu, cokolwiek, to też jest rodzaj budowania więzi.

Inną jeszcze techniką budowania więzi jest na przykład to, żeby publicznie te osoby w jakiś sposób pochwalić, żeby podziękować publicznie za coś. To jest bardzo prosta rzecz, która jednak buduje tę wdzięczność zwrotną, nawet pracując zdalnie na jakimś Slacku czy innym komunikatorze, często są takie kanały przeznaczone do podziękowania komuś za coś. Wykorzystujmy to, ponieważ to też jest realna technika na to, żeby umocnić tę więź.

 

Okej, jeśli mówimy o zwinności, to mi się to kojarzy z tym, żeby ten zespół był w stanie szybko reagować na jakieś zmiany i żeby był elastyczny. I przejdźmy może do naszej perspektywy na wielkość zespołu. Ja chciałem zadać Ci pytanie, czy uważasz, że to jest możliwe, żeby duży zespół był efektywny? 

Bo moje spojrzenie na to jest takie, że jeśli mamy mały zespół, to po pierwsze jest brak rozmycia odpowiedzialności i jest też ta odpowiedzialność po prostu większa, większe poczucie sprawczości, a inna sprawa jest taka, że każdy z każdym jest w stanie pogadać w małym zespole, każdy z każdym jest w stanie się znać. Jak mamy zespół 14-20 osób, to o niektórych osobach wiemy tylko, jak się nazywają i czym mniej więcej się zajmują, a jak mamy mały zespół, 6-, 7-osobowy, to te relacje są bardziej personalne i jesteśmy w stanie dzięki temu też robić lepsze produkty, znamy swoje wady, zalety, mocne strony.

 

Tak, bez dwóch zdań. Tzn. oczywiście ten zespół powinien być odpowiedni i nie większy, zależy to trochę od tego, w jakim modelu pracujemy. To, co ja obserwuję, i co się dosyć fajnie sprawdza, to jest to, jeśli mamy pewną redundancję ról w tym naszym zespole.

Czyli, weźmy na to, mamy jakiś produkt, który ma backend, dwie aplikacje mobilne, stronę WWW i jeszcze jakiś tam obszar Data. To jeśli weźmiemy sobie po jednym inżynierze z każdego tego obszaru technologicznego, QA jeszcze itd., to już będzie pewnie kilka tych osób. Natomiast może się okazać, że taki zespół, który ma po dwóch inżynierów z każdej tej specjalizacji, czyli jeśli jesteśmy w stanie mieć tego kogoś do pomocy, do zrobienia code review, żeby się nie prosić osób z innych teamów, to może być pomocne.

Co prawda wówczas sumarycznie może się okazać, że mamy 10-12 osób w zespole, ale ten zespół działa mimo wszystko dobrze. Więc to trochę zależy, ale zdecydowanie, jeśli będziemy szli w tym kierunku, że dokładamy sobie tych programistów, oczekując, że kod będzie powstawał szybciej, funkcjonalności będą wypychane szybciej, to się to oczywiście nie wydarzy, bo jednak ta dynamika wewnątrz zespołu, to, jak się ludzie ze sobą dogadują, to, jaki jest narzut na komunikację, to bardzo mocno to wpływa. 

Tak samo dla managera, który zarządza takim zespołem, konieczność bycia na bieżąco, konieczność spotkań, to też jest ogromny narzut. Może się okazać, że w tej biurokracji nam ten manager zupełnie gdzieś zginie, więc jak najmniej, ale pod warunkiem, że to nie dotyka szybkości, sprawności działania zespołu.

 

Innymi słowy, jeśli powiększymy zespół dwukrotnie, to nie możemy oczekiwać, że projekt zostanie dwa razy szybciej dostarczony. Jeśli chcemy skalować, to opcją jest też po prostu wydzielanie osobnych zespołów z jakimiś obszarami kompetencji. W taki sposób zachowujemy mniejszą skalę, ale rzeczywiście robimy więcej, każdy musi się wypowiedzieć np. na daily. Jak mamy 2 zespoły po 7 osób po 2 minuty, to wyjdzie 15 minut, jak mamy 15-osobowe zespoły, to już może wyjść pół godziny takiego daily. Już tutaj widać, że zyskujemy na takich codziennych, drobnych rzeczach.

I tutaj ten słynny przykład zespołu, którego rozmiar określają dwie pizze , idea, która pochodzi z Amazona.

 

Właśnie, ta wielkość zespołu ma znaczenie, ale w długiej perspektywie nie możemy zapomnieć, że jako lider, jako manager zarządzający zespołem nasza odpowiedzialność musi być sfokusowana na rozwijaniu tego zespołu. Po to, żeby on wewnętrznie budował te relacje, ale też, żeby się doskonalił po to, żeby te osoby, które są członkami zespołu, czuły, ze ten rozwój następuje, po to też, żeby się nie wypalały, żeby te kompetencje się gdzieś tam wewnętrznie coraz bardziej doskonaliły. Więc może porozmawiajmy chwilkę o rozwijaniu zespołu. Na co tutaj zwrócić uwagę?

 

Z jednej strony zespół dotarty to zespół efektywny. Czyli powinniśmy starać się zbudować zgrany zespół. Natomiast z drugiej strony, jeśli będziemy w jednym zespole cały czas, to będziemy się jednak kisić w tych samych szufladkach myślowych. Więc musimy też zadbać o to, żeby między tymi zespołami był jakiś przepływ ludzi raz po raz, a co z tym się wiąże, także przepływ wiedzy i pomysłów.

Więc dbajmy oczywiście o retencję, o to, żeby pracownicy od nas nie odchodzili. To jest w ogóle taka moja teza, że jeśli mamy dużą retencję pracowników w firmie, to nie jesteśmy w stanie robić fajnych produktów. Żeby robić dobre produkty, trzeba znać dobrze ten produkt, który się robi, a na to trzeba czasu po prostu. Rotacje między zespołami są fajne w jakimś tam stopniu, natomiast starajmy się dbać o to, żeby ludzie byli zadowoleni i żeby robili to, co chcą robić, żeby korzystali z technologii, z którymi czują się komfortowo, i też to, co jest ważny, to taki zespół powinien mieć określone jakieś swoje cele, jakieś mierniki, metryki, nie powinno to być ukryte w managemencie, tylko powinna być pełna transparentność tego, za co jesteśmy rozliczani, i powinniśmy umieć powiedzieć w każdej chwili, czy dowozimy, czy może jednak jet to poniżej oczekiwań, a może powyżej.

 

Właśnie, ten feedback jest istotny, bo tutaj mówimy o tym, żeby dawać tę swobodę, tę możliwość do wybierania tego, w jaki sposób zespół realizuje np. te zadania, za pomocą jakich narzędzi, czy też wręcz możliwość eksperymentowania, to jest istotne, ale jeśli zostawimy ten zespół samemu sobie i powiemy: róbcie, jak chcecie, co chcecie, to na koniec dnia pewnie zbyt dobrze nie wyjdzie.

 

Tak, w agile nie chodzi o to, że nie ma żadnych planów, żadnego pomysłu i robimy reaktywnie. Nie, musi być plan i pomysł, tylko po prostu bądźmy z tym wszystkim elastyczni i nie pozwólmy jakiemuś oryginalnemu zamysłowi wpływać na to, że jest tak i nie można nic zmienić. To jest agile. Bądźmy elastyczni, a nie nie miejmy planu i reagujmy tylko na to, co się dzieje.

 

Jasne, ja tutaj może przywołam książkę Kim Scott, Radical Candor. To jest bardzo fajna pozycja m.in. o tym, w jaki sposób dawać feedback. I tam jest właśnie mowa o tym koncepcie, żeby dawać ten feedback, mówić, co nam przeszkadza, albo jakiego typu luki widzimy, ale żeby robić to w taki grzeczny, przystępny, nieobrażający sposób.

Czyli jeśli widzimy, ze ktoś nie dowozi, że jego działania źle wpływają na zespół, to nie ociągajmy się jako lider, manager, ale też myślę, że jako szeregowy członek tego zespołu z tym, żeby taką osobę poinstruować albo powiedzieć, co nam przeszkadza. Oczywiście nie publicznie, nie wystawiając na pośmiewisko taką osobę, ale jeden na jeden, ale nie strońmy od tego.

Natomiast dając ten feedback, nie powinniśmy tego robić w sposób obrażający, że my tutaj jesteśmy managerem, mamy stanowisko z nadania i my teraz powiemy, jak żyć, tylko zróbmy to w taki sposób, żeby ta osoba coś z tego wyniosła, żeby wiedziała, na czym nam zależy jako osobie dającej feedback, jakie mamy oczekiwania, co powinna poprawić, ale też, żeby nie była na tyle urażona czy zdołowana, że nie będzie chciała już podejmować żadnych czynności naprawczych.

Więc taki jednoznaczny, ale jednocześnie grzeczny feedback jest bardzo istotny w tym budowaniu relacji, o którym wcześniej mówiliśmy.

 

To przechodząc jeszcze tu do jednego wątku, który pominęliśmy, albo odnosząc się do tego, co wcześniej mówiłeś, to myślę, że jeszcze problem, który może wyniknąć z dania zespołowi sprawczości, to jakieś niezdecydowanie i to, że każdy ma jakiś pomysł i nie wiadomo, który wybrać, brakuje tej decyzyjności. Albo w druga stronę, jest wręcz jakiś konflikt i ścierające się opinie i teraz musi być jakiś mechanizm w takim zespole odgórnie narzucony, który mówi, co robimy w takiej sytuacji patowej. I tutaj ten lider jest osobą, która powinna mieć autorytet i coś zdecydować.

 

Tak, czyli nie jest taki rozlazły, tylko faktycznie jeśli trzeba, to podejmuje konkretne decyzje, tak jak tutaj na tym polu walki, o którym mówiliśmy wcześniej, że wiemy, na kim polegać, kto podejmuje decyzje.

 

Natomiast chciałbym podać jeszcze jakiś przykład dla sytuacji z niezdecydowaniem. Otóż fajnym takim pomysłem jest, żeby eksperymentować po prostu. I wtedy, jeśli są różne pomysły, to nie wchodźmy w jeden albo drugi na 100%, tylko zróbmy jakieś 10% jakiegoś proof of concept, coś, co jesteśmy w stanie zrobić na gotowych komponentach, gotowych narzędziach, zobaczmy jedną sytuację, drugą sytuację, i wtedy możemy podjąć decyzję, a nie teoretyzujmy na siłę. Ja lubię w ogóle coś lubić i nie lubię niezdecydowania i tego, że za dużo nad czymś myślimy. Są dwie koncepcje, to spróbujmy jakieś minimum i jednej, i drugiej zobaczyć w boju.

 

Dokładnie. Rozmawiamy dzisiaj nie tylko o budowaniu zespołów, ale również o ich rozwijaniu, więc nie zapomnijmy, że jako manager mamy właśnie taką odpowiedzialność, żeby o to nasze stadko w jakiś sposób dbać, wysyłając na szkolenia, proponując różnego typu konferencje, może jakieś książki, zachęcając osoby, które wiemy, że w naszym zespole posiadają wiedzę, do tego, żeby się tą wiedzą dzieliły z innymi. 

Więc to też jest istotny aspekt, bo taki zespół czy poszczególne osoby, które czują, że są zadbane również pod względem rozwoju kompetencji, po prostu zdecydowanie lepiej się czują na co dzień i zdecydowanie rzadziej te odejścia następują, więc tu też jest nasza odpowiedzialność jako managerów.

 

Tak, ale takie odejścia raz po raz z różnych, naturalnych powodów też występują. Tak że trzeba dbać jednak o to, żeby te konkretne kompetencje nie były u jednej osoby i te okresowe szkolenia, może nawet takie wewnątrzzespołowe. My takie robimy okresowe szkolenia na przykład i każdy czymś się dzieli, w czym jest dobry. Wiadomo, że to nie będzie tak od razu, że wszyscy będą specjalistami od baz danych, ale może trochę o tych indeksach posłuchamy i coś tam nam się więcej ułoży w głowie, bo kolega od baz danych nam opowie dzisiaj o swoim poletku. W innym dniu kolega od testów, tester automatyczny, nam opowie trochę więcej, co on tam robi, i też będziemy w stanie na przykład, jak pojedzie na urlop, pociągnąć jego część, a nie będzie coś czekało 2 tygodnie, aż ktoś wróci.

 

Otóż to. Jeśli chodzi natomiast o taką codzienną pracę, to nie musimy chyba mówić, że micro management to jest kompletny antypattern i tutaj nie ma co się rozwodzić, natomiast myślę, że warto wspomnieć też, że będąc managerem, będziemy chcieli wiedzieć, co tam słychać u tych naszych developerów, jak radzą sobie z zadaniami, jaki postęp osiągnęli itd.

Wszystko to może prowadzić do tego, że będziemy chcieli tworzyć więcej spotkań, niż to jest potrzebne, a wiemy, że nic tak nie rozprasza, nie odciąga od kreatywnej i rzetelnej pracy, jak właśnie kolejne spotkanie, które mamy w kalendarzu, więc zwróćmy an to uwagę, że spotkanie, które może być mailem, niech będzie tym mailem.

To Łukasz, może podsumujmy nasze dzisiejsze spotkanie, jakie główne wątki związane z budowaniem zespołu i rozwijaniem możemy wskazać.

 

Najpierw rozmawialiśmy o tym, kim jest lider i jaka jest jego rola w zespole. Tutaj moje spojrzenie jest takie, że jest autorytetem w zespole i kimś, kto zna pewne aspekty projektu lepiej niż inni. Jest osobą, do której można przyjść po prostu ze swoimi problemami.

Następnie rozmawialiśmy o tym, jak budować zespół i jakie cechy powinien mieć ten zespół. Przede wszystkim musi być odpowiedzialność i poczucie sprawczości w tym zespole. Wspomnieliśmy też, że małe zespoły są naszym zdaniem bardziej efektywne i bardziej są w stanie wziąć na siebie tę odpowiedzialność i się z niej rozliczyć.

Potem rozmawialiśmy o rozwijaniu zespołu. Tutaj najważniejsze punkty to, żeby dbać jednak o ten zespół, żeby ludzie chcieli w nim pracować, nie chcieli odchodzić i żebyśmy dzielili kompetencje między członków zespołu, żeby nie było tak, że tylko jedna osoba ma pewne kompetencje. Czyli żebyśmy dbali o rozwój wszystkich członków zespołu i żeby ta wiedza przez taką osmozę się rozprzestrzeniała.

 

Myślę, ze to tyle. Nie zapomnijmy na koniec dnia, że oprócz tego, że jesteśmy oficjalnym liderem z nadania, to jesteśmy też człowiekiem. Może się okazać, że będąc w roli developera w zespole, za jakiś czas będziemy jakimś team liderem, więc dbajmy o te relacje, myślę, że to taki najistotniejszy przekaz.

Nie pozostaje nam nic innego, jak podziękować za dzisiejsze spotkanie, zaprosić do kolejnych odcinków podcastu w tej serii dedykowanej liderowi, managerowi IT. A wszystkich tych, którzy szukają pracy w branży IT albo chcą wystawić ogłoszenie związane z taką pracą, zapraszamy na SolidJobs, gdzie zawsze mnóstwo ofert z widełkami wynagrodzeń znajdziecie.

A na dzisiaj Łukasz, bardzo Ci dziękuję.

 

Warto dodać, że obecnie jesteśmy jedynym portalem na polskim rynku, który posiada 100% ofert z widełkami wynagrodzeń, i tak zostanie, tak że zapraszamy. I do zobaczenia.

 

Do zobaczenia, cześć!