To jest 275. odcinek podcastu Porozmawiajmy o IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT 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! 

 

W kolejnym odcinku dla lidera i managera IT rozmawiamy o temacie, który mam wrażenie dotyczy nie tylko liderów i managerów, ale wszystkich tych, którzy właśnie z managerami czy liderami współpracują, bo będziemy mówić o tym, czy manager zespołu powinien pisać kod, a szerzej myślę, czy powinien zajmować się tematami technicznymi. I jeśli chcielibyśmy ten odcinek zrobić bardzo krótkim, to pewnie moglibyśmy powiedzieć, że to zależy, i wyłączyć mikrofony, ale z racji na to, że ten temat ma nieco więcej odcieni szarości, to postaramy się to naświetlić. 

Łukasz, czy to według Ciebie w ogóle jest dobrze postawione pytanie, czy manager powinien pisać kod?

 

To może jeszcze zacznę od tego, że oczywiście rozpatrujemy taką sytuację, gdzie to jest w ogóle możliwe. Czyli ten manager wcześniej był jakimś członkiem zespołu, programistą, kimś, kto ma tę wiedzę. Oczywiście w innym przypadku te rozważania nie mają tutaj głębszego sensu. Natomiast ja zawsze jestem za tym, że np. jeśli jesteś programistą, to powinieneś być super ekspertem w domenie, w której się obracasz. Czyli jeśli robisz system finansowy, to powinieneś te finanse mieć gdzieś tam w małym paluszku. Jeśli robisz system medyczny, to powinieneś np. znać przepisy dotyczące służby zdrowia.

Analogicznie tutaj idąc, jeśli jesteś managerem takiego zespołu developerów, zespołu technicznego, to Twoją domeną jest ten rozwój oprogramowania, Twoją domeną właśnie jest kod i Ty jako manager, może to źle zabrzmi, ale żeby sobie nie dać wcisnąć jakiegoś kitu, to powinieneś wiedzieć np. czy te wyceny czasowe, które zespół poda, są realne, czy są zaniżone, zawyżone. Powinieneś to czuć. Tak że jakaś wiedza o tej domenie, którą jest właśnie programowanie, moim zdaniem dla managera jest niezbędna.

Natomiast oczywiście nie ma takiego obowiązku, że ten manager musi umieć pisać kod. Natomiast na pewno nie zaszkodzi. No i pewnie pytanie powinno brzmieć, na które dzisiaj sobie odpowiemy, czy powinien musieć ten kod pisać. I tutaj moim zdaniem odpowiedź jest jasna, że nie powinniśmy dopuścić do takiej sytuacji, że ten manager jest zmuszony coś zrobić, bo zespół bez niego sobie nie poradzi. Zespół powinien być samodzielny, powinien dysponować, tutaj brakuje mi dobrego słowa, może mi Krzysztof pomożesz?

 

Interdyscyplinarny albo taki, który po prostu ma wszystkie kompetencje do tego, żeby zrealizować projekt.

 

Tak, samodzielnie powinni być w stanie wszystko zrobić, natomiast ten manager jest tutaj taką osobą, która ma tę wiedzę gdzieś ekspercką i służy też pomocą, trochę jest też takim liderem tego całego zespołu.

Natomiast jeśli dochodzi do takiej sytuacji, że zespół nie jest w stanie czegoś sam zrobić i jest potrzebny manager, żeby te rękawy podciągnął i stał się przez chwilę członkiem zespołu i jakiegoś buga poprawił czy zoptymalizował jakąś część kodu, to jest to sytuacja, do której nie powinniśmy dopuścić.

 

No właśnie, czyli nie chodzi nam tutaj o to, że manager nie powinien znać technologii, tak szerzej to nazwijmy, wyjdźmy poza programowanie, tylko chodzi o to, że nie powinniśmy dopuścić do takiej sytuacji, bo zespół nie powinien być postawiony właśnie przed taką sytuacją, że ten manager musi coś napisać, tak? Że inaczej dany projekt nie idzie do przodu, sprinty nie dowożą wartości i po prostu nic się nie dzieje. To są dwie różne sytuacje.

Zgadzam się z Tobą, że dobrze jest, jeśli manager ma tam jakieś kompetencje techniczne, bo chociażby na one-on-one wie, na co ta druga osoba narzeka, ale taki manager piszący kod, ponieważ nie ma innej możliwości, no tutaj to już jakiś z pewnością jest zapaszek.

 

Tak i to właśnie taki antypater, który gdzieś tam może być, to jest to, że mamy sprint, sprint ma jakiś określony cel, ileś tam tych story pointów do dowiezienia, okazuje się gdzieś tam w ostatnim tygodniu sprintu, że jesteśmy w połowie, i co robi manager? Te rękawy zakasuje i siada i pomaga, i programuje.

I to na pewno to jest właśnie ta sytuacja, która nie powinna mieć miejsca. Natomiast może dojdziemy do tego w trakcie rozmowy, moim zdaniem są takie sytuacje, gdzie to może być z benefitem dla całego zespołu, gdzie ten manager wykonuje tę brudną robotę, nazwijmy to. To też nie musi być stricte kodowanie. Tutaj jakby się na to sfiksowaliśmy, ale to mogą być inne zadania, takie po prostu projektowe, czysto zespołowe, np. właśnie design, gdzie on wchodzi po prostu w kompetencje członka zespołu, to jest to miejsce, gdzie tego być nie powinno.

 

Tak, ja bym tutaj chciał, że tak powiem, trochę kij w mrowisko włożyć, bo mam wrażenie, że można z różnych mądrych książek wyczytać dwa stanowiska przynajmniej w tym temacie.

Z tego obozu militarno-wojskowego, że tak powiem, tutaj myślę głównie o Extreme Ownership i Jocko Willing, prawda, i te osoby, które raczej mówią o tym, że jeśli faktycznie grunt się pali pod nogami, to ten manager bierze te trudne zadania, ten manager jasno wytycza ścieżkę i zajmuje się jednak tą pracą i w ten sposób np. buduje jakieś tam zaufanie albo to, że razem jesteśmy w tej trudnej sytuacji, no to budujemy te więzi i dzięki temu zespół jest mocniejszy.

A z drugiej strony bardzo fajne zdanie jakiś czas temu usłyszałem, że manager staje się lepszym albo staje się coraz bardziej cennym dla zespołu, jeśli właśnie coraz mniej realizuje tych rzeczy związanych z wszelkimi technicznymi albo nawet zarządczymi, że tak powiem, zadaniami, a jest bardziej dla ludzi, czyli bardziej jak gdyby pomaga ludziom albo usuwa te problemy przed ich nóg, a nie zajmuje się dowożeniem niczego sensownego.

Więc mam wrażenie, że są takie dwa tutaj obozy. Trochę jestem skłonny powiedzieć, że i jedna, i druga opcja ma rację.

 

Ja z kolei powiem: jedna i druga opcja się myli. Ja jestem zwolennikiem zdrowego rozsądku i tego, że też każdy jest inny i co w jednym przypadku może działać, to w drugim przypadku niekoniecznie będzie na miejscu. Tak że jedna i druga sytuacja oczywiście może mieć sens i może być odpowiednia. Jedna i druga sytuacja może tutaj nie działać. Też zależy od ludzi, od ludzi w zespole, też od tego managera, jakim on jest człowiekiem, czego on oczekuje, czego on też chce od życia, że się tak wyrażę.

Zdefiniowałbym tutaj, że są właśnie takie dwa archetypy takich managerów. Czyli taki full-time manager, czyli taki, który właśnie, tak jak powiedziałeś, zajmuje się ludźmi, spotkaniami, tabelkami Excela, facylitacją jakichś tutaj wydarzeń, rozmowami z biznesem, i jest ten hands-on manager, który bierze udział w tych sprintach, bierze udział taki jakby aktywny, tak bym się wyraził. Zna kod, wie, gdzie są śrubki, gdzie są np. jakieś długi technologiczne, czyli taki manager, który jest bliżej tego kodu.

Ta smutna prawda to jest pewnie taka, że wszyscy zaczynamy jako hands-on managerzy, a potem w miarę trwania naszej pracy, w miarę, jak życie nam upływa, nagle się budzimy i całe życie spędzamy na spotkaniach. To moim zdaniem też nie jest dobre, żeby się tak obudzić i zobaczyć, kurde, co ja zrobiłem ze swoim życiem. Jestem managerem.

 

Wiesz, taką, mam wrażenie, zdrową strategią jest to, żeby dywersyfikować. I to nie tylko w inwestowaniu, ale też w wielu różnych innych dziedzinach życia. Więc wydawałoby się, że takie podejście, gdzie jako manager, wiesz, będę się w połowie czasu zajmował managerowaniem, a w połowie czasu coś tam sobie napiszę kod trochę, popchnę jakieś low-hanging fruits, taski, jakoś coś podziałam w tym projekcie, może się wydawać, że to jest rozsądne podejście, tak?

 

Kuszące na pewno.

 

Kuszące, tak. Trochę się przysłużę zespołowi, trochę się przysłużę odsłonie technicznej projektowi, no co tu się może nie udać, nie? Ale czy to nie pachnie Ci jakimś antypaternem przypadkiem?

 

Tak, tutaj pewnie jest dużo ryzyk i dużo wad, które zaraz sobie możemy opowiedzieć. Jeszcze chciałem tylko jeden szybki wątek. Jaka jest geneza tego? Geneza też jest taka, że tym managerem zostaje zazwyczaj lider zespołu, jedna z tych osób w zespole, która ma najlepsze kompetencje. Raczej tego juniora tam nie wyciągamy z tego projektu po to, żeby z niego zrobić teraz szefa tutaj wszystkich. Raczej wyciągamy osobę, która gdzieś tam jakiś ten autorytet zdobyła tymi swoimi umiejętnościami zapewne.

I teraz to jest właśnie kuszące i to, że zespół polega na tym, że ta osoba ma tę wiedzę specjalistyczną gdzieś tam w jakimś swoim poletku i tu jest ta geneza, źródło tego problemu.

 

Ciężko się rozstać managerowi z jego techniczną przeszłością, tak?

 

Tak. I jakie mogą być wady czy ryzyka tego? Na pewno pierwsza wada jest taka, że skoro manager nie jest w tym sprincie aktywnym uczestnikiem, to robi to, co robi, gdzieś tam poza procedurami, jest też takie przyzwolenie czy też chęć do tego, żeby robić pewne rzeczy niezgodnie z tym, jak to się normalnie dzieje. Czyli np. commitujemy bezpośrednio gdzieś do jakiegoś brancha, pomijamy pull requesty, deploy na produkcję, nie przejdzie coś np. przez testera, bo nie miał czasu, bo może to zrobić, a np. inni nie mogą, bo mają poblokowane coś, albo po prostu, bo tak. 

Jakość na tym zapewne cierpi, nie mówiąc o morale zespołu, jeśli ktoś jest bardziej uprzywilejowany i może coś zrobić inaczej, to albo inni będą też tak chcieli, albo będą się czuli w jakiś sposób, nie wiem, czy dyskryminowani to jest dobre słowo, ale traktowani inaczej w ogólności.

Kolejne wady tutaj to, że jeśli cały czas nie odcięliśmy tej pępowiny, to zespół się nie usamodzielni, tak jak w poprzednim odcinku mówiliśmy też, że może nowy lider w tym zespole się nie wyłoni, też ludzie nie będą chcieli brać odpowiedzialności za pewne rzeczy ,co naturalnie zazwyczaj się dzieje w sumie. Takie są moje doświadczenia że jeśli ta osoba, która była gdzieś tam liderem w zespole, odchodzi, to zazwyczaj jest tak, że się wyłania taki nowy lider, ktoś tutaj chce coś właśnie zrobić i ktoś przyjmuje jakieś poletko, jakąś część.

Często jest tak, że tymi rzeczami reszta zespołu się dzieli i to nie jest tak, że jedna osoba przyjmuje te wszystkie rzeczy od tej osoby, która odeszła, ale bardzo często jest tak, że właśnie następuje podział tych odpowiedzialności. I tego może zabraknąć, jeśli dalej ten manager będzie traktowany jako część zespołu, a nie właśnie ktoś, kto jest jednak obok i jednak ktoś, kto powinien usuwać te przeszkody, a nie bezpośrednio rozwiązywać problemy.

Na pewno pierwsza wada jest taka, że skoro manager nie jest w tym sprincie aktywnym uczestnikiem, to robi to, co robi, gdzieś tam poza procedurami, jest też takie przyzwolenie czy też chęć do tego, żeby robić pewne rzeczy niezgodnie z tym, jak to się normalnie dzieje. Czyli np. commitujemy bezpośrednio gdzieś do jakiegoś brancha, pomijamy pull requesty, deploy na produkcję, nie przejdzie coś np. przez testera, bo nie miał czasu, bo może to zrobić, a np. inni nie mogą, bo mają poblokowane coś, albo po prostu, bo tak. 

 

Tak, ja bym do tych jeszcze tutaj ryzyk i wad dorzucił coś takiego, że jeśli ten manager poświęca część swojego czasu na zajmowanie się technicznymi rzeczami, to automatycznie nie poświęca tego czasu zespołowi.

Więc ten zespół gdzieś na koniec dnia cierpi, jakby nie było. A z drugiej strony ten manager też się nie rozwija albo nie będzie w stanie dojść do pewnych umiejętności, do pewnych może doświadczeń itd., ponieważ zajmuje się po prostu innymi rzeczami. Automatycznie ten czas jest poświęcany właśnie na inne rzeczy, więc ten rozwój tych kompetencji managerskich też nie idzie w takim stopniu, jakby to mogło wyglądać, gdyby ten czas był jednak kompleksowo tylko na ten aspekt poświęcony, więc niestety można powiedzieć, że wszyscy wówczas tracą na koniec dnia.

 

Tak, więc taki krótki katalog wad mamy za sobą. Na pewno nie był to kompletny katalog. Czy możemy teraz trochę przejść do zalet i może też naszych pomysłów, jak programowanie, tutaj taki mamy, myślę, nacisk na to, żeby pokazywać te różne techniki, różne pomysły też jako coś, co może być narzędziem w rękach, no w tym wypadku managera, tak? I też to, że manager potrafi pisać kod, potrafi, oczywiście my tu mówimy o pisaniu kodu, możecie to sobie też do różnych innych umiejętności przyrównać, to jest przykład, myślę, czy tam z naszego, poletka z naszych doświadczeń tutaj czerpiemy, ale oczywiście możemy równie dobrze mówić, nie wiem, o UX designie na przykład.

Tak że jakie mamy tutaj narzędzia? To, że ja jestem tym managerem i umiem pisać kod, to daje mi np. okazję do tego, że mogę łatwo wymieniać się wiedzą i też rolą managera, myślę, jest to, żeby dbać o to, żeby ci pracownicy w zespole poszerzali swoje kompetencje, i po prostu mogę tę moją wiedzę bezpośrednio sprzedawać innym, a mogę też, skoro wiem, mam tę wiedzę ekspercką o tych różnych obszarach, np. wiem, co to jest czysty kod, czy wiem, co to jest DDD, no to mogę na przykład zadbać o to, żeby odpowiednie szkolenia moi członkowie zespołu przeszli. Czyli mogę ich kierować na odpowiednie książki, odpowiednie materiały, więc wymiana wiedzy.

 

Tak, ja bym jeszcze do tego może tutaj w tym wątku dodał, że mówimy cały czas o tym managerze piszącym kod, czy wytwarzającym w jakiś sposób techniczne artefakty, tak to może nazwijmy, ale jeśli jestem blisko z tą technologią, jestem na bieżąco, jeśli chodzi o te techniczne aspekty projektu, to mogę też działać w roli swego rodzaju mentora, więc nie wytwarzam bezpośrednio może kodu, ale pomagam kształtować, czy mam wpływ na rozwój techniczny projektu, ponieważ wiem, co tam się dzieje i w jakiś sposób rozwijam też ten mój zespół. Nawet, tak jak Ty powiedziałeś, oczywiście może to być poprzez zewnętrzne szkolenia, materiały itd., ale ja też mogę właśnie w tej roli się zespołowi przysłużyć.

 

Tak, ale też mogę krytycznie spojrzeć na jakieś artefakty, które zostały wytworzone, np. na etapie projektowania mogę przejrzeć, dać swój jakiś input, jakieś sugestie nakierować jak najbardziej, a idąc poziom niżej, poziom dalej, to kolejnym narzędziem to jest pair programming i też mogę z kimś usiąść i nie to, że ja programuję, tylko właśnie też jako forma wymiany wiedzy, forma nakierowania, forma też tego pair programingu jako też takiej sesji projektowej. Jeśli robimy coś w ciemno, to poznanie np. jakie są problemy w danym odcinku, w danym module, zdefiniowanie w ogóle problemów, tak bym się wyraził.

 

To jeszcze może tylko, Łukasz, bym dorzucił, że tak, właśnie w tym wątku managera jako żółtej kaczuszki na godziny, to oczywiście odsyłamy do jednego z pierwszych naszych odcinków z pierwszej serii o narzędziach dla programisty, bo to tutaj warto sobie ten temat z pewnością tam rozszerzyć i, no właśnie, manager może nam posłużyć dodatkowo jako taka osoba, z którą zderzamy jakieś tam pomysły, która nas wspomaga poprzez pair programming, jak najbardziej.

 

Nie widzę też powodu, żeby np. taki manager nie mógł też brać częściowo udziału w procesie code review. Też może wtedy dzielić się swoją wiedzą, tak bym się wyraził. Tak że code review jako narzędzie, tu bym znowu przyrównał do zarządzania zespołem, troszkę taki mikro management przez to wprowadzę, ale mimo wszystko bezpośrednio nie wykonuję tej pracy wyrobnika programisty, tylko jednak po prostu daję wskazówki, pokazuję, jak coś powinno moim zdaniem wyglądać. Jest to na pewno do przemyślenia.

Teraz jeszcze bym przedstawił jedno takie narzędzie, co ten manager może tutaj zrobić, i to jest chyba najważniejsze moim zdaniem. Manager nie programuje dlatego, żeby zrobić jakiś feature, żeby pomóc zespołowi jakiś story point przepchnąć dalej, tylko po to, żeby usprawnić ogólnie proces, znaleźć jakieś wąskie gardła w tym procesie, odkryć problemy, zautomatyzować trochę pracę, zobaczyć, jak kto robi, zakładając, że już zdążył zapomnieć albo został do nowego zespołu np. przesunięty, żeby poznać po prostu to, jak zespół pracuje i im usprawnić tę pracę, np. odkryje, że bez sensu zrobić tak często spotkania, tak dużo spotkań, albo właśnie czegoś jest za mało, za dużo jakiejś dokumentacji, może odkryje, że testerzy powinni jakieś artefakty wytwarzać, których nie wytwarzają.

No, różne rzeczy mogą tutaj nie działać albo… Może to jest za duże słowo, że nie działać, ale w różnych miejscach może po prostu odkryć pole do usprawnień.

Manager nie programuje dlatego, żeby zrobić jakiś feature, żeby pomóc zespołowi jakiś story point przepchnąć dalej, tylko po to, żeby usprawnić ogólnie proces, znaleźć jakieś wąskie gardła w tym procesie, odkryć problemy, zautomatyzować trochę pracę, zobaczyć, jak kto robi, zakładając, że już zdążył zapomnieć albo został do nowego zespołu np. przesunięty, żeby poznać po prostu to, jak zespół pracuje i im usprawnić tę pracę, np. odkryje, że bez sensu zrobić tak często spotkania, tak dużo spotkań, albo właśnie czegoś jest za mało, za dużo jakiejś dokumentacji, może odkryje, że testerzy powinni jakieś artefakty wytwarzać, których nie wytwarzają.

 

Właśnie, bo powiedzmy, taki programista, który gdzieś nad tą swoją małą częścią siedzi na co dzień, często może nie mieć takiego całościowego obrazu. I okej, jeśli zajmujemy się tylko, powiedzmy, backendem jakiejś aplikacji, to może tego problemu nie ma, ale jeśli np. nasz produkt składa się z aplikacji mobilnej, jakiejś części jeszcze infrastrukturalnej związanej z AI itd., to tych różnych kropek jest całkiem mnóstwo i taki manager jest w stanie wówczas te różne rzeczy tutaj ze sobą powiązać, zobaczyć, jak ten obraz szerzej wygląda i być może zaproponować pewne usprawnienia, więc to jest z pewnością też zaleta dla całego zespołu.

 

Tak, ale też chodzi o ten mindset. Jak ja jestem programistą, dostaję zadanie, to moim celem jest zrealizowanie tego zadania, dowiezienie feature’a, zapewnienie jakiejś funkcjonalności w systemie.

Natomiast jako manager, kiedy siadam do tego feature’a, to moim celem nie jest zrobienie feature’a, dostarczenie funkcjonalności, tylko moim celem jest to, żeby zobaczyć, jak ten proces wygląda i jak go można usprawnić. Więc zupełnie inne podejście do tego, inny cel w ogóle tego, że ja siadam i już trzymajmy się tej jednej metafory, programuję.

To jeszcze inny przykład z mojego doświadczenia. Jak ja byłem takim managerem, to nasz zespół był mały. Miałem pod sobą jednego programistę, jednego testera, jednego analityka i jedną osobę, która się zajmowała generowaniem contentu, czy też instrukcji użytkownika i tego typu rzeczy.

I teraz w przypadku, kiedy ten mój programista, nie wiem, chciał iść na urlop albo zachorował, zaniemógł, to mogliśmy to tak rozplanować, żebym po prostu wtedy przez ten tydzień był tym programistą, tak jak z góry to wiedzieliśmy, jak to rozplanować, to mogłem wtedy go jednak zastąpić, więc jest tu taka zaleta, że przy tym małym zespole było to możliwe, żeby nie było np. przestojów w pracy, tylko gdzieś tam pewne rzeczy mogły się dziać.

Oczywiście były też inne możliwości. Mogliśmy podkraść programistę z innego zespołu na przykład. Ale jakby tutaj starając się być samowystarczalną taką jednostką, to tego typu operacje były możliwe.

 

Tak, jak najbardziej. Gdy mówiliśmy o ryzykach czy wadach, to powiedzieliśmy, że ten wpływ managera, który sobie tam po cichu pushuje bezpośrednio do mastera i deployuje od razu, ten wpływ na zespół może być raczej taki deprymujący niż rozwijający i to z pewnością jest prawda, ale tutaj jak gdyby wchodząc w ten temat raczej zalet, to można powiedzieć, że manager, który ma ten skill właśnie techniczny, ma taki, można powiedzieć, większy szacun na dzielni wśród programistów, co de facto też może podbudowywać jego pozycję.

I powiedzmy sobie szczerze, pewnie lepiej się z taką osobą współpracuje i dogaduje niż z takim właśnie managerem, który tylko w Excel jest dobry i nie bardzo w te tematy techniczne.

 

No tak, czyli jakby zaleta jest taka, że mówimy tym samym językiem.

 

Powiedzieliśmy już o mentoringu jako też zalecie, która może rozwijać cały zespół pod warunkiem, że ten manager ma tam faktycznie trochę tych doświadczeń, trochę umiejętności. To może nawet niekoniecznie być związane z tym, że on doskonale wie, jak w tym konkretnym projekcie architektura wygląda, jakieś niskopoziomowe rozwiązania, ale ma już wystarczająco doświadczeń, żeby temu zespołowi, który z czymś tam się mierzy, pomóc, czy przynajmniej zasugerować parę rozwiązań.

Zastanawiam się, bo tutaj powiedziałeś, że wiesz, masz takie doświadczenia pracy właśnie jako taki manager z technicznym zapleczem, o tak bym to może nazwał, z małym zespołem, i przyszło mi na myśl, czy to faktycznie nie jest tak, że to trochę zależy od wielkości organizacji, czy od tej mitycznej kultury organizacyjnej, jak do tego tematu podejść, czy np. w mniejszych zespołach może ma to sens, bo wymagane jest w jakiś sposób zastępowanie siebie albo wymagany jest taki trochę techniczny leadership ze strony tego managera, który może jeszcze jakiś czas temu programował, ale już w dużych organizacjach ta specjalizacja musi być dużo większa i np. manager zajmuje się tylko zarządzaniem, bo po prostu nie dałoby rady inaczej ze względu na wielkość zespołu.

 

Zapewne tak, zapewne masz rację, zapewne jest różnica. Natomiast co do zasady, to uważam, że, mimo że ta różnica istnieje, to dalej jest możliwe i tego, i tego typu podejście. Natomiast pewnie kwestia jest taka, że w małym zespole, w małej firmie też jest łatwiej te role gdzieś tam dzielić, bo siłą rzeczy ludzie są odpowiedzialni za więcej i wymaga się trochę szerszego podejścia. Natomiast tak jak powiedziałeś, w dużej firmie pewnie jest większa specjalizacja i pewnie też nie ma takich problemów, na inne problemy się natrafia.

 

Powiedzieliśmy, że manager, który częściowo fokusuje się na swojej pracy stricte managerskiej, a częściowo koduje, de facto nie rozwija się do końca ani w jednej, ani w drugiej specjalizacji i tak ciągle stoi trochę okrakiem, ale tak się zastanawiam, czy jednak bycie trochę na bieżąco z technologią, jednak takie kodowanie albo robienie czegoś technicznego, nieporzucanie tych umiejętności nie jest swego rodzaju polisą ubezpieczeniową dla managera, który w razie gdyby np. ta działka mu się nie spodobała, bo to często tak jest, że my jesteśmy awansowani, próbujemy i niekoniecznie nam się to musi podobać, albo jeśliby się okazało, że musimy gdzieś szukać pracy w innym zespole itd., itd., Czy mimo wszystko jednak pewne pielęgnowanie tych umiejętności technicznych nie jest zwyczajnie taką polisą ubezpieczeniową, która w razie czego może nam dać możliwość pracy w innych niż managerskich rolach?

 

Myślę, że tak, a jeszcze jest drugi tego aspekt, czyli to, że robimy to, co lubimy, robimy to, co znamy, i też czujemy się dzięki temu pewniej i bardziej komfortowo, tak bym powiedział. I pewnie większy taki komfort też prowadzi do tego, że ta praca daje lepsze efekty, tak mi się wydaje. Jeśli jesteśmy zadowoleni z tego, co robimy i wierzymy w to, co robimy, to jakby efekt będzie lepszy niż jeśli robimy coś bez przekonania i gdzieś tam dlatego, że coś trzeba zrobić, niż dlatego, że chcemy to robić.

Myślę, że tak, a jeszcze jest drugi tego aspekt, czyli to, że robimy to, co lubimy, robimy to, co znamy, i też czujemy się dzięki temu pewniej i bardziej komfortowo, tak bym powiedział. I pewnie większy taki komfort też prowadzi do tego, że ta praca daje lepsze efekty, tak mi się wydaje. Jeśli jesteśmy zadowoleni z tego, co robimy i wierzymy w to, co robimy, to jakby efekt będzie lepszy niż jeśli robimy coś bez przekonania i gdzieś tam dlatego, że coś trzeba zrobić, niż dlatego, że chcemy to robić.

 

Ja może jeszcze na koniec dorzucę takie swoje doświadczenia związane z tym tematem. Zdarzyło mi się pracować z managerami, którzy nie byli techniczni, znaczy w tym sensie, że nie mieli, powiedzmy, wcześniejszych doświadczeń zawodowych, technicznych. Też się to układało, ale miałem też okazję pracować z ludźmi, którzy właśnie wcześniej byli programistami i w jakiś sposób awansowali na te managerskie stanowiska i też to działało.

To nie znaczy, że jedno czy drugie podejście jest złe, to tutaj dużo zależy od człowieka, mam wrażenie. Jest tylko jedno pewne ryzyko, czy takie niebezpieczeństwo, o którym może nie wspomnieliśmy, a które zauważyłem. Mianowicie ci managerowie, którzy faktycznie mają jeszcze mocny ten background techniczny, są automatycznie swojego rodzaju autorytetem, czy takim zwierzchnikiem w tym zespole.

Więc bardzo trudna jest sytuacja, kiedy właśnie ta osoba na przykład prowadzi code review i niejako swoim autorytetem wymusza pewne rozwiązania albo naciska na pewne rozwiązania. Oczywiście tutaj jest duża umiejętność z jednej i drugiej strony, żeby z tej sytuacji wybrnąć. Natomiast jeśli jesteście managerami, to jednak musicie brać pod uwagę to, że niekoniecznie będziecie już zawsze najbardziej technicznie zaawansowaną osobą w tym zespole i upieranie się przy swoich rozwiązaniach niekoniecznie jest dobre dla zespołu i dla projektu.

Dobrze, Łukasz. Wyszedł nam bardzo szary, jeśli chodzi o wydźwięk, ten podcast. Powiedzieliśmy o wadach, powiedzieliśmy o zaletach. Faktycznie to na koniec dnia zależy, czy te umiejętności techniczne…

 

Myślę, że w ogóle to musimy zmienić nazwę tego podcastu: To zależy.

 

To jest faktycznie najlepsze podsumowanie tej naszej dzisiejszej rozmowy. Mimo wszystko może jednak spróbujemy kilka punktów podsumowania na koniec?

 

Jasne, czyli tradycyjnie. Na pewno nie jest tak, że ten manager powinien programować lub nie powinien, to wszystko zależy. I musimy rozważyć wady, zalety.

Na pewno musimy, jeśli już ten manager programuje, to musimy go traktować na równi z innymi członkami zespołu, czyli nie może być tak, że się coś dzieje poza procedurami. To wszystko musi być w ramach tego workflow’u, który normalnie tutaj w zespole występuje. Nie może to być tak, że to programowanie tego to jest jakieś ratowanie sytuacji i gaszenie pożarów.

Jeśli chodzi o zalety, to na pewno rozważmy to, że to programowanie może być narzędziem, które np. pomaga nam usprawnić proces, usprawnić to, jak zespół działa, znaleźć po prostu to, co nie działa i zaproponować usprawnienia. I na pewno jest dobrą też drogą do tego, żeby ten manager miał okazję do wymiany swojej wiedzy, swoich umiejętności i po prostu uczenia członków zespołu, którzy mają mniejsze doświadczenia, wskazywania im drogi robienia właśnie code review. Myślę, że to jest też fajny aspekt.

Są zalety, są wady. Pamiętajmy o tym. I co już jeszcze tutaj możemy dodać, Krzysztofie?

 

Jasne, możemy dodać, że na SolidJobs mamy oferty pracy zarówno dla managerów, jak i dla programistów, więc jeśli coś w waszym zespole niekoniecznie działa tak, jak powinno, chcielibyście rozwijać się w innej firmie, to wpadajcie na SolidJobs. Tam oczywiście znajdziecie tylko ogłoszenia z widełkami wynagrodzeń.

A jeśli w Waszym zespole jest potrzeba zatrudnienia, kogoś na stanowiska managerskie, albo programistyczne, albo inne techniczne, to również SolidJobs jest tym właściwym adresem.

 

Jak zwykle niezwykle subtelnie. I kończymy w ten sposób nasz podcast. Dziękuję, Krzysztofie, za rozmowę.

 

Dzięki, Łukasz.

 

Do zobaczenia.

 

Do zobaczenia. Cześć.