To jest 269. 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ść, Krzysztofie!

 

Jeśli dobrze liczę, to jest to nasze trzecie spotkanie i bynajmniej nie w ramach audycji Porozmawiajmy o IT, ale w ramach naszego cyklu podcastów dla lidera i managera IT. Czas leci i mamy też kolejne ciekawe tematy i za nami i przed nami, więc tych, którzy trafiają po raz pierwszy na tę serię, zapraszamy oczywiście do wcześniejszych odcinków, a dzisiaj będziemy mówić o temacie, który pewnie jest często poruszany przy tym przysłowiowym ekspresie do kawy w firmie albo na różnych grupach Facebookowych o problemach polskiej branży IT, mianowicie o antywzorcach w zarządzaniu zespołem IT.

Bo tak to już jest, że awansując z pozycji technicznej na bardziej managerską, zarządczą musimy pamiętać, że kompetencje techniczne, które mieliśmy wcześniej, niestety nieraz nijak się mają do nowego zestawu kompetencji związanego z zarządzaniem, który musimy mieć, i przy tym możemy popełnić mnóstwo różnych błędów, więc dzisiaj o tej tranzycji słów kilka będzie i przejdziemy sobie też przez taką listę grzeszków managera IT, którą sobie razem z Łukaszem zebraliśmy i postaramy się do tego jakoś odnieść.

Dobrze, to może weźmiemy sobie na początek ten case osoby, która awansuje z roli technicznej do roli managera, lidera, i jak dobrze wiemy, wiele tam może pójść nie tak. Chciałbyś zacząć wymieniać te rzeczy, które mogą się nie udać?

 

Może najpierw, zanim przejdziemy do konkretów, to zacznijmy od tego, że są różne poziomy problemów i z różnych przyczyn mogą one wynikać. Jedną taką grupą nazwałbym problemy socjalne. Czyli byliśmy kiedyś członkiem watahy, a teraz jesteśmy kimś, kto ma podgryzać. Nie jesteśmy już częścią tej grupy, tylko stajemy się kimś, kto jest obok, kto powinien umieć zwrócić uwagę, gdy dzieje się coś nie tak, jest robione nie tak, jak powinno, i z tego mogą wyniknąć różne niesnaski czy problemy.

Więc tutaj w tej samej pewnie kategorii umieściłbym problem braku autorytetu czy też budowania tego autorytetu. Pytanie, kto tym liderem się stał. Czy rzeczywiście to było tak, jak mówiliśmy w poprzednim odcinku, zostałeś nim naturalnie, czy też zostałeś mianowany z potrzeby chwili i to jest tak, że Ty masz jakieś zdanie, a np. w zespole jest ktoś, kto jest lepszym specjalistą od baz danych i teraz musisz mu powiedzieć, że on tymi bazami danych ma jakoś inaczej zarządzać, a Ty masz tę wiedzę mniejszą, nie jesteś autorytetem w tym obszarze, i co wtedy? Jak rozwiązać tego typu problem odwrócenia hierarchii?

 

Właśnie. Wcześniej chodziliśmy sobie razem na piwo czy herbatę, a tu nagle okazuje się, że musimy teraz tym osobom mówić bezpośrednio, żeby inaczej zajmowały się swoją pracą, inaczej podchodziły do pewnych problemów, przy czym ta narzucona hierarchia jest o tyle istotna, że teraz stoimy w roli, która zarządza, która ma swoich podwładnych, i siłą rzeczy te relacje nie mogą już być takie same.

Ja myślę, że to jest konsekwencja, bo można się zastanowić, czy da się to zmienić, czy da się być nadal na takich równoprawnych, koleżeńskich układach z tą grupą, z którą się wcześniej gdzieś tam zjadło zęby na kodzie, i myślę, że nie, że to nie jest do końca zdrowe i niestety źle wpływa na tę osobę zarządzającą, na managera. Bo nie ma wtedy takiego obiektywnego spojrzenia na to, jak ten zespół działa.

Każdy, kto ma dzieci, doskonale wie, że dzieci bardzo szybko wyłapują słabości rodziców i potrafią je bardzo dobrze wykorzystać, tak samo byłoby w przypadku tych programistów czy innych specjalistów IT, którzy jeśli nie czuliby tego respektu do swojego managera, to też pewnie zachowywaliby się inaczej. Więc z tego mogłyby płynąć różnego typu antywzorce, o których będzie jeszcze dzisiaj mowa.

 

Tak, i kolejna grupa, to problemy wynikające z tego, że jest to dla nas nowa rola, czujemy się niepewnie, odczuwamy jakiś strach, niepokój, może też występować syndrom oszusta, może nawet mamy jakąś wiedzę, umiejętności, umiemy organizować prace zespołu, bo robiliśmy to wcześniej, ale teraz, po tym, jak oficjalnie zostaliśmy szefem zespołu, to nagle mamy wątpliwości, czy to, co robimy, jest okej. 

Może też czasami wydajemy polecenia w sposób, który sprawia wrażenie, że to nie są polecenia, ale prośby, i ktoś to zinterpretuje w ten sposób, że on to powiedział, ale zdecydowałem, że tego nie trzeba robić, a nie taki był zamysł. Zamysł był taki, że ja Ciebie grzecznie proszę, ale chcę, żeby to było wykonane, i to nie jest do dyskusji. A nawet gdyby było do dyskusji, to przedyskutuj to ze mną, a nie sam sobie podjąłeś decyzję, że czegoś nie zrobisz, co tutaj zasugerował ten lider.

 

Tak, nie chcemy zniechęcać ludzi, żeby mimo wszystko swoją ścieżkę kariery rozwijali w kierunku bycia liderem, natomiast prawda jest też taka, że pracując jako osoba techniczna, mamy jakąś specjalizację, jesteśmy w czymś dobrzy, widzimy jakąś wartość, wpływ tego, co robimy, na rozwój projektu, na to, jak być może klienci z tego korzystają itd., a nagle w roli lidera zaczynamy dużo mniej dowozić technicznych rzeczy. Być może jeszcze trochę, ale najczęściej w ogóle, więc ta nasza praca polega już na czymś innym. Już nie jest realizacją kodu czy jakichś feature’ów, ale jest pomaganiem zespołowi i rozwijaniem zespołu, ustalaniem tego, co ma być wykonane itd. 

Plus trzeba się pogodzić z tym, że nie będziemy już najlepszym specjalistą w dziedzinie, że inni będą od nas dużo lepsi, ponieważ będą się w tych kierunkach technicznych rozwijali. Musimy się nauczyć delegowania zadań albo polegania na tym, że zespół to po prostu zrealizuje, bo wie, jak to zrealizować. To wszystko zwłaszcza na początku tej tranzycji jest dosyć problematyczne, ciężko się do tego przyzwyczaić, i pewnie w tej początkowej fazie nadal jeszcze działamy na podstawie tych wyuczonych schematów z wcześniejszych ról, co właśnie może prowadzić do różnych wypaczeń i problemów w zarządzaniu zespołem.

 

Tak, i tutaj może być np. taki problem, jeśli jednak byliśmy tym ekspertem, tą osobą od danej części systemu czy danej operacji, czy baz danych i teraz mamy je migrować i musimy nagle oddać tę rzecz, którą się opiekowaliśmy, która była naszym oczkiem w głowie, wszyscy zawsze przychodzili z jakimkolwiek problemem do nas, a nagle jest taki moment, że chciałbyś, żeby te dzieci dorosły i żeby same sobie poradziły.

Oczywiście, też jakąś częścią drogi lidera jest to, żeby jednak pomóc, jak gdzieś się problem pojawi, i wrócić tutaj do tej roli na chwilę, wejść, założyć czapkę tego specjalisty, ale to nie jest to clue, i to może być ciężkie, żeby pozwolić komuś robić to samemu, bez Twojego wkładu.

 

Tak, to spójrzmy może na te grzeszki, braki, błędy managera IT, które może popełniać.

 

To może ja zadam Ci, Krzysztof, takie pierwsze pytanie: jak myślisz, co jest gorsze w tej roli lidera, czy to, jeśli nie ma on odpowiedniej wiedzy, umiejętności do zarządzania zespołem, czy może brak wiedzy domenowej, czy też technicznej?

 

Myślę, że brak wiedzy o zarządzaniu ma większy impakt, bo w pewnym stopniu możemy polegać na ekspertach domenowych zewnętrznych, na tym, że członkowie zespołu posiadają część tej wiedzy domenowej. 

Nie zrozum mnie źle, braki jednego i drugiego są doskwierające, ale mimo wszystko, jeśli ten manager nie sprawuje swojej podstawowej roli, czyli właśnie zarządzania, bo po prostu nie ma wiedzy, jak to robić poprawnie, to chociaż byłby super ekspertem z tej domeny, to i tak zespół będzie miał problemy, nie będzie działał wydajnie, ludzie będą odchodzić, będą zrażeni i to się pewnie gorzej przełoży na działanie całego zespołu. Co Ty o tym myślisz?

 

Ciekawe spostrzeżenia, w dużej mierze się zgadzam, natomiast dla mnie jest też ważna ta wiedza domenowa i osobiście wielokrotnie doświadczyłem tego, że problemy w zespole czy w projekcie wynikały z tego, że brakowało tej wiedzy i ona była tylko u jednej osoby albo trzeba było wykonać jakąś pracę, żeby pozyskać tę wiedzę, i to się nie działo i mogły z tego wynikać takie problemy, że trzeba było przepisać jakąś całą funkcję i np. tydzień czy 2 tygodnie pracy idzie do kosza, bo źle zrozumieliśmy założenia na samym początku.

 

Myślę, że jako członek zespołu technicznego, jeśli masz w roli managera osobę, która jest w jakiś sposób autorytetem dla Ciebie, właśnie pod względem chociażby wiedzy technicznej, domenowej itd., to jakoś tak spokojniej, lepiej Ci się działa i wiesz, że zarządza Tobą i zespołem osoba kompetentna. Ale nie myliłbym tego, i to jest z kolei wg mnie antywzorzec, z podejściem autorytarnym, gdzie masz po drugiej stronie takiego szefa z lat 90., który rządzi mocną ręką i nie daje się tak naprawdę rozwinąć zespołowi, nie daje tej inicjatywy, bo on wie najlepiej, jak coś ma być zrobione, to jest wg mnie kompletnie antywzorzec.

Chyba jakieś tam wyważenie jest potrzebne, ale jestem też ciekawy, jakie jest Twoje doświadczenie.

 

Moje doświadczenie jest takie, że to zależy, i trzeba dostosować podejście do ludzi, z którymi się aktualnie pracuje. I to nie ma tak, że jest jedno idealne rozwiązanie, tylko w dużej mierze są ludzie, którzy preferują i chcą więcej swobody, ale z drugiej strony też miałem kiedyś sytuację, że do mnie podszedł podwładny, kolega, który mi wręcz powiedział, że chciałby, żeby więcej na niego zwracać uwagę, bo jeśli jest zostawiony samemu sobie, to gdzieś tam odpływa i nie wykonuje tego tak efektywnie, jak by to mogło być, i chciałby czuć na karku oddech managementu. Oczywiście trochę przejaskrawiam, ale też tak bywa. Tak że trzeba zawsze dostosować przekaz do odbiorcy.

Moje doświadczenie jest takie, że to zależy, i trzeba dostosować podejście do ludzi, z którymi się aktualnie pracuje. I to nie ma tak, że jest jedno idealne rozwiązanie, tylko w dużej mierze są ludzie, którzy preferują i chcą więcej swobody, ale z drugiej strony też miałem kiedyś sytuację, że do mnie podszedł podwładny, kolega, który mi wręcz powiedział, że chciałby, żeby więcej na niego zwracać uwagę, bo jeśli jest zostawiony samemu sobie, to gdzieś tam odpływa i nie wykonuje tego tak efektywnie, jak by to mogło być, i chciałby czuć na karku oddech managementu.

 

Słusznie, musimy brać pod uwagę, że różnie osoby działają, i niektóre są takie wewnątrz sterowne, że potrafią doskonale sami sobie organizować czas, motywować się itd., a inni potrzebują tej motywacji czy sterowności z zewnątrz.

Ale chciałem tylko jeszcze dodać, myślę, że dobrze się do tego odnosi książka Jocko’a Willinka Extreme ownership, gdzie co prawda to jest domena jednostek specjalnych, może niekoniecznie super się to odnosi do IT, aczkolwiek gra analogii na pewno jest, i on jest zdania, że taki styl przywódczy, gdzie dajesz mimo wszystko rozwinąć się tym swoim podwładnym i pokazać możliwości ma sens, ale w sytuacji krytycznej jednak wszyscy zwracają się w kierunku tego lidera, który wtedy przewodzi mimo wszystko autorytarnie, w sensie wydaje konkretne polecenia i konkretnie wymaga ich realizacji.

Więc raz, że mamy różne upodobania osób, a dwa, że różne sytuacje wymagają różnych sposobów zarządzania, liderowania i to też trzeba wziąć pod uwagę, bo nawet w IT się tak może zdarzyć, że kiedy produkcja płonie, to nie możemy sobie być może pozwolić na swobodne podejście, musimy mieć kogoś, kto będzie to wszystko trzymał i jasno wydawał polecenia.

 

To wracając do naszej listy błędów, które można popełnić, to myślę, że sztuką jest też dawanie odpowiedniego feedbacku i w ogóle rozmowa z członkami zespołu. Tu są różne błędy, które można popełnić, trzeba np. wiedzieć, czy dana rozmowa powinna się odbyć w przestrzeni publicznej, czy prywatnie z kimś i w ogóle czy ma to być rozmowa, czy może inna forma komunikacji jest bardziej adekwatna do danego przewinienia czy sytuacji.

Albo w drugą stronę, brak feedbacku zaadresować i ile tego feedbacku powinno być, żeby to nie zostało odebrano jako jakiś micro management, micro zarządzanie, ale żeby też nie było tak, że zostawiasz ludzi samych sobie.

 

To jest sztuka i na pewno wymaga sporo doświadczenia. Tu bym polecił książkę Radical Candor o sztuce dawania feedbacku, która jasno mówi, że chwalić powinno się publicznie, żeby ta osoba odczuła w jakiś sposób satysfakcję, jakieś zadowolenie, że coś jej się udało osiągnąć, ale ten taki feedback krytyczny to jednak jest domena rozmowy 1:1 i publiczne krytykowanie kogoś to jest wg mnie kompletny antywzorzec.

Tak jak powiedziałeś, brak feedbacku to jest kolejny antywzorzec, bo jak taka osoba ma się rozwijać, ma wiedzieć, co zrobiła dobrze, co źle, skoro nie dostaje tej informacji od swojego managera, więc nie możemy absolutnie doprowadzić do takiej sytuacji jako manager.

 

Myślę, że taki negatywny feedback to jest taki, który nie jest konstruktywny. Dostajesz informację, że coś było zrobione źle, ale nie masz informacji, co konkretnie było nie tak albo z czego to wynika, co można poprawić. Pozytywny feedback to taki, który pozwoli być lepszym człowiekiem, lepszym specjalistą, a negatywny w takim rozumieniu, że nic nie wnosi do dyskusji poza tym, że zaognia sytuację albo jest grą na obwinianie się nawzajem.

 

Kolejna rzecz, którą można wymienić, to jest to, że lider z samego znaczenia tego słowa jest odpowiedzialny za to, żeby prowadzić zespół, więc jeśli nie jest w stanie określić tego wspólnego celu zespołu, idei, pomysłu, czegokolwiek, co ten zespół jednoczy, to będziemy mieli tylko ileś tam osób, które spotykają się na 8 godzin, żeby coś robić, ale to nie będzie nigdy zespół. Więc tutaj jest ta odpowiedzialność lidera, żeby ten cel ciągle pokazywać, przypominać, mówić o nim, kreować go.

Natomiast jeśli to jest zbyt daleko idące, że wyznaczamy cel, który jest wręcz nierealistyczny, to też nie będzie działało dobrze. To musi być wyważone coś, co jest w gestii osiągnięcia tego zespołu, ale co go nie przeraża i nie miażdży, że tak powiem.

 

Tak, ale też słyszałem ostatnio taki cytat, nie jestem pewien, czy nie pomylę, ale był to bodajże Michał Anioł, że problemem nie jest to, że te cele sobie stawiamy za wysoko i ich nie osiągamy, ale problemem jest to, że stawiamy je za nisko i je osiągamy.

 

Coś w tym na pewno jest. Wspomniałeś o micro managemencie. Tego chyba nie trzeba tłumaczyć, że jest to antywzorzec, to, że ktoś próbuje bardzo w detalach kontrolować, nadzorować, cały czas dopytywać, jak idzie z tym taskiem, a za godzinę, czy udało się już albo gdzie my z tym jesteśmy itd. To oczywiście budzi dużą frustrację i nie pomaga.

 

Tak, ale też tutaj ważne jest podejście lidera. Jeśli jest to ważne zadanie i takie, które ma jakiś deadline, jest z jakiegoś powodu pilne, to nie powinno być pytania, na kiedy będzie, jak z tym stoisz, tylko jak Ci mogę pomóc, co możemy zrobić, żeby to wspólnie przyspieszyć, czy potrzebujesz jakiegoś wsparcia, testera przypadków testowych może, tego typu pytania.

 

Tak, tak, to jest to, o czym mówiliśmy na początku, że rolą lidera albo tą inną pracą, którą teraz wykonuje, jest właśnie pomaganie zespołowi, usuwanie tych kłód spod nóg, żeby zespół był w stanie szybciej, sprawniej realizować te swoje zadania.

 

Tak, i tutaj mówiłeś o micro managemencie, a ja jeszcze tutaj odwrócę sytuację. Co, jeśli ten lider czuje się niepewnie i ucieka w tego specjalistę, próbuje robić te rzeczy, którymi się zajmował wcześniej, po to, żeby nawet nieświadomie te zadania zarządcze od siebie odciągnąć i żeby wyglądało, że rzeczywiście on coś robi i nie ma czasu na to zarządzanie, a zamiast tego zostaje mianowanym specjalistą.

 

Czyli taka nieobecność lidera.

 

Tak, czyli antypattern o nazwie brak lidera w zespole.

 

Właśnie, jednak trzeba po raz kolejny jasno powiedzieć, że tą odpowiedzialnością lidera jest zespół jako taki, a nie praca techniczna, którą zespół wykonuje. I idąc w tym kierunku, czyli myśląc o zespole jako o najważniejszej rzeczy, którą rozwijamy, którą staramy się popychać do przodu, nie możemy doprowadzić do sytuacji, w której w naszym teamie robią się tzw. silosy.

Czyli 1-3 osoby, które posiadają całą wiedzę z jakiegoś obszaru, które w jakiś sposób tę wiedzę zawłaszczają dla siebie i de facto w tym naszym zespole robią się jeszcze mniejsze zespoliki, które ze sobą nie współpracują optymalnie.

Musimy pamiętać, że na liderze też spoczywa jakaś odpowiedzialność za wymianę wiedzy i być może też za to, żeby dobierać osoby realizujące zadania w taki sposób, aby te silosy nie miały okazji się stworzyć.

Właśnie, jednak trzeba po raz kolejny jasno powiedzieć, że tą odpowiedzialnością lidera jest zespół jako taki, a nie praca techniczna, którą zespół wykonuje. I idąc w tym kierunku, czyli myśląc o zespole jako o najważniejszej rzeczy, którą rozwijamy, którą staramy się popychać do przodu, nie możemy doprowadzić do sytuacji, w której w naszym teamie robią się tzw. silosy.

 

Tak, ja zawsze będę powtarzał, żeby ta wiedza o zadaniach była w całym zespole, a nie u jednej osoby. Czasami jest tak, że zadanie jest niewdzięczne i nikt się nie chce nim zająć, a jest np. jedna osoba, która już to robi i jest w jakiś sposób na to skazana. Natomiast też z drugiej strony, jako liderzy nie powinniśmy na to pozwalać, powinniśmy się starać, żeby te zadania był w stanie zrobić ktokolwiek w zespole albo chociaż ktoś inny, nawet jeśli nie miałoby to być aż tak dobrze zrobione.

Natomiast ja się kiedyś spotkałem też z taką sytuacją, że ktoś powiedział, że będzie coś robił i nie będzie się tym dzielić, bo to jest taki jego lewar na podwyżkę, na to, żeby być w tym zespole kimś, i on się nie będzie dzielił tą wiedzą. Też tacy ludzie występują w przyrodzie.

 

Na pewno, ale to też jest rola lidera, żeby w jakiś sposób sobie z tym problemem poradzić. To, o czym powiedzieliśmy, czyli dzielenie się wiedzą wewnętrzną, to jest oczywiście element rozwoju pracowników, i ta rola też spoczywa na liderze, rozwijanie pracowników.

 

Tak, i to jest właśnie coś, co jest bardzo zaniedbywane przez liderów, bo jesteśmy skupieni na tu i teraz, na tym zadaniu, które mamy do dowiezienia, na deadline’ach, tych wszystkich sopotkaniach, a nie ma casu na to, żeby zadbać o to, by tę wiedzę przekazać, by ci pracownicy się trochę doszkolili w jakiejś działce. Na to też trzeba zaplanować czas.

 

Dokładnie, czyli rozwijać te kompetencje pracowników. Ale z drugiej strony musimy też pamiętać, że jako lider, jako manager jesteśmy pewnego rodzaju przykładem dla innych członków zespołu, jesteśmy bacznie obserwowani, więc to, żeby być autentycznym, żeby jednak wzbudzać zaufanie u innych, jest kluczowe do tego, żeby zespół nam zaufał, żeby w tych sytuacjach problematycznych, trudnych, które na pewno się gdzieś tam pojawią, żeby z tego zaufania sie dało wówczas korzystać, żeby zespół widział w nas osobę, na której może polegać.

A w związku z tym jako lider nie możemy doprowadzić do sytuacji, w której faworyzujemy 1-3 pracowników, bo po prostu lepiej się z tą osobą dogadujemy, może lepiej nam odpowiada charakter itd. Bo to też zostanie zauważone. Trzeba pamiętać o tym, żeby traktować wsystkie osobyb równo i niestety to jest taki antypattern, który często widzę, że lider wybiera sobie 1-2 osoby, takich powierników, osoby, które może zawsze przyklaskują…

 

Osoby, które może też zawsze robią trochę więcej w tym zespole.

 

Albo się na wszystko godzą, bo to też może być różny powód. I te osoby są lepiej traktowane, mają więcej przywilejów itd. Tak oczywiście nie może być.

 

No nie może tak być. Ale jednak przyznasz, że jeżeli ktoś tutaj wykonuje dobrą pracę i daje z siebie więcej niż inni, to jakoś chciałbyś mu podświadomie podziękować.

 

To się nie wyklucza.

 

Tak, ale mówię, że to jest trudne, żeby tak spojrzeć na wszystkich po równo, i też nie wiem, czy to jest uczciwe w sumie.

 

Nie, znaczy oczywiście, tu nie chodzi o to, żebyśmy wszystkich traktowali w ten sam sposób, bo jedni mają  określoną rolę albo seniority, inni mniejsze, więc oczywiście ten wkład pracy i odpowiedzialność jest inna.

 

Jasne, nie możemy tą samą miarą juniora z seniorem mierzyć.

 

Dokładnie.

 

Natomiast też chodzi o to zaangażowanie, o to, czy ktoś rzeczywiście się stara, chce robić coś fajnego, produkt, który da i radość jemu z tego procesu wytwórczego, i tym końcowym klientom.

 

Tak, myślę, że taki kolejny antywzorzec, który może w jakiejś perspektywie doprowadzić wręcz do wypalenia u lidera, to jest to, kiedy jednak ma pewne obawy przed delegowaniem obowiązków. Albo ma takie spostrzeżenie, że nikt tego nie zrobi tak dobrze jak ja, więc ja to muszę pociągnąć, bo jeśli to przekażę, to oni na pewno to zepsują i na pewno nie zrobią tego wystarczająco dobrze.

To jest oczywiście po pierwsze brak zaufania do zespołu, co jest kolejnym antywzorcem, ale z drugiej strony też powoduje, że ten manager ma zbyt dużo i nie jest w stanie się zajmować tym, czym powinien.

 

Tak, ale też musimy uważać tutaj na drugą pułapkę: ufaj, ale sprawdzaj. Bo jednak czasami to może być nawet problem komunikacyjny, i to, co zostało dowiezione, to nie jest to, czego oczekiwałeś, więc mimo że delegujesz i masz zaufanie, to wydaje mi się, że warto mieć takie jakieś nawyki, żeby dało się zweryfikować wykonaną pracę. I może nie tyle dało się, ile, żeby to było takim nawykiem czy procesem, że jednak sprawdzamy, czy się udało coś.

 

Tak, coś, co jest dla mnie wielką sztuką i jednocześnie olbrzymim antywzorcem w przypadku zarządzania zespołami IT, to jest zarządzanie konfliktem. Konflikty będą się pojawiać, różne są osobowości, podejścia, jeśli złożymy sobie zespół z samych seniorów, to to w ogóle wybuchnie, więc ten konflikt na pewno się pojawi i umiejętne zarządzanie tym konfliktem jako manager to jest olbrzymia sztuka i wymaga z pewnością dużo doświadczenia. Dużo tam można zrobić źle, jeśli chcemy zbyt autorytarnie albo jeśli w jakiś sposób niesprawiedliwie do tego podejdziemy, to pewnie się to przełoży w pewien sposób na jeszcze większe niesnaski i problemy w zespole, więc myślę, że taka umiejętność zarządzania konfliktem jest bardzo potrzebna każdemu managerowi.

 

Nic dodać, nic ująć. Okej, katalog problemów omówiliśmy.

 

Jeszcze jedna myśl mi się pojawiła, bo faktycznie pewnie dałoby się ten katalog jeszcze rozszerzyć, ale myślę, że to są najistotniejsze grzeszki, błędy managera IT, ale trzeba też pamiętać, że taki manager nie funkcjonuje w próżni, on działa w jakiejś tam organizacji z określoną kulturą, pewnie też jest zarządzany przez kogoś jeszcze wyżej, i wszytko to w jakiś sposób na tę osobę wpływa, czy to środowisko, w jakim manager funkcjonuje, również przekłada się dalej, w jakie sposób ta osoba zarządza zespołem, więc na to też trzeba zwracać uwagę.

 

Tutaj może przejdę płynnie do takiego zjawiska, o którym ostatnio dużo się słyszy, czyli toksyczna pozytywność. Polega to na tym, że jeśli coś jest nie tak, to nie krytykujemy tego z obawy przed tym, że zostaniemy zwolnieni, będziemy źle postrzegani, w szczególności w dużych korporacjach taka sytuacja ostatnio ma miejsce i różne problemy wynikają z tego, że ludzie boją się powiedzieć, że coś jest nie tak, a ci, którzy mówią, że tak, tak, wszystko jest okej, są nagradzani np. awansami, a potem ten produkt zostaje wypuszczony na rynek i się okazuje katastrofą, albo nikt nie mówił w trakcie, że coś jest nie tak, z jakiegoś strachu czy toksycznie pozytywnej kultury organizacyjnej, czy też, jeśli mówił, że coś jest nie tak, to już tam nie pracuje. Takie historie słyszałem ostatnio.

I wydaje mi się, że to jest też duży temat, na który warto zwrócić uwagę.

Tutaj może przejdę płynnie do takiego zjawiska, o którym ostatnio dużo się słyszy, czyli toksyczna pozytywność. Polega to na tym, że jeśli coś jest nie tak, to nie krytykujemy tego z obawy przed tym, że zostaniemy zwolnieni, będziemy źle postrzegani, w szczególności w dużych korporacjach taka sytuacja ostatnio ma miejsce i różne problemy wynikają z tego, że ludzie boją się powiedzieć, że coś jest nie tak, a ci, którzy mówią, że tak, tak, wszystko jest okej, są nagradzani np. awansami, a potem ten produkt zostaje wypuszczony na rynek i się okazuje katastrofą, albo nikt nie mówił w trakcie, że coś jest nie tak, z jakiegoś strachu czy toksycznie pozytywnej kultury organizacyjnej, czy też, jeśli mówił, że coś jest nie tak, to już tam nie pracuje. 

 

Byś świadomym przynajmniej. Właśnie, z kolei z mojej strony, jak mówimy o płynnych przejściach, to powoli zmierzając ku końcowi, pojawiła mi się taka wskazówka do managerów IT, dosyć oczywista, ale w tym codziennym zabieganiu możemy nie mieć czasu, żeby się zatrzymać i na taki prosty pomysł wpaść, mianowicie spróbujmy się zastanowić, czy pracując wcześniej na tych technicznych stanowiskach, chcielibyśmy mieć takiego managera, jakim jesteśmy. Albo ew. co by mi przeszkadzało na tych stanowiskach technicznych, gdyby zarządzał mną taki, a nie inny człowiek. Bo wtedy takie postawienie się z boku ukaże nam jakąś nową perspektywę.

To co, Łukasz? Parę punktów podsumowania na koniec?

 

Jeszcze jedna myśl mi wpadła. Wydaje mi się, że dużym problemem jest też nadmiar formalizmu i procedur czy spotkań. Wiadomo, nie można też przegiąć w drugą stronę, anarchii i chaosu, ale starajmy się też, żeby nie zblokowały nas takie formalne procedury i żebyśmy jednak umieli sprawnie iść do przodu.

 

Tak, t jest ważne, żeby zespół czuł jednak trochę powietrza i swobody, a nie był przygnieciony biurokracją.

 

No dobra, czyli co? Podsumowujemy. Trudno tu pewnie będzie znaleźć tradycyjnie 3 punkty.

 

Zebrało się trochę tego, tak.

 

Bardzo szeroko do tego podeszliśmy. Na pewno też zachęcamy do tego, żeby ktoś zamieścił komentarz, jakie grzechy pominęliśmy w tej tranzycji managera IT.

I podsumowując, po pierwsze zwróćmy uwagę na komunikację, dostosujmy ją do naszych odbiorców, nie starajmy się si ę zawsze tak samo rozwiązywać danego problemu, aczkolwiek fajnie mieć zawsze takie pozytywne wzorce, natomiast wzorzec, który będzie użyty zawsze i do wszystkiego, staje się tym antywzorcem, którego staramy się unikać.

 

Jasne. Ja bym tutaj postawił jednak na ten feedback i jego dawanie lub nie w odpowiednich ilościach. Myślę, że często lubimy przesadzać w jedną lub w drugą stronę, zarządzając zespołem, albo przechodzi to w micro management, gdzie to też nie jest dobre, albo wręcz w to znikanie lidera, bo preferuje on zajmowanie się kwestiami technicznymi albo jakimiś innymi, które wydaje się, że wnoszą wartość do projektu, więc musimy wyważyć zaangażowanie w pracę zespołu i jednocześnie w dawanie feedbacku, bo ten balans jest niezwykle potrzebny.

 

Okej, i taki trzeci obszar to tranzycja. Już nie jesteśmy specjalistą, stajemy się liderem, więc musimy odpuścić, pozwolić czasami, żeby coś było wykonane trochę gorzej, niż wiemy, że my byśmy zrobili, ale delegujmy zadania, dajmy innym się wykazać, rozwijać.

 

Dokładnie tak. I to był trzeci odcinek z serii dla lidera i managera IT. Mówiliśmy o antywzorcach w zarządzaniu zespołem IT.

Łukasz, bardzo Ci dziękuję za dzisiejsze spotkanie.

 

Dzięki, Krzysztof.

 

Dziękujemy naszym słuchaczom. Zapraszamy do wcześniejszych odcinków i serii kierowanych bardziej do programistów, do osób technicznych, ale myślę, że tam jest też sporo wartościowej wiedzy. A wszystkich zapraszamy oczywiście na SolidJobs, gdzie możecie znaleźć oferty pracy zawsze z widełkami wynagrodzeń, możecie też wystawić ogłoszenie, jeśli jesteście w roli managera, lidera i poszukujecie kogoś do zespołu. Tak że po raz kolejny zapraszamy Was na SolidJobs, a my słyszymy się już niedługo w kolejnym odcinku.

Dzięki, Łukasz, i cześć!

 

Dzięki, do zobaczenia!