Ja uwazam, ze nie warto po 1 odpowiedzialnosc po 2 kontakt z ludzmi czesto jest na zasadzie, zrob to zrob tamto. Jezeli lubisz rozkazywac i duzo spotkan to okej. Poza tym beda cie traktowac jako przelozonego, a nie jak kumpla z zespolu. Jedyny plus jest taki, ze zdobywasz doswiadczenie w zarzadzaniu ludzmi i mozna pozniej awansowac na jakiegos dyrektora, co moze znacznie podniesc zarobki, ale samo wejscie na stanowisko dyrektorskie jest juz bardzo trudne ze wzgledu na konkurencje.
2
1
Najgorsze w byciu TL - u mnie to sie w sumie nazywa tech lead, wiec kapka coś innego, ale dla uproszczenia mówie- kierowniczych stanowiskach - jest to, że...
w przeciwieństwie do innych "normalnych" biznesów, nie możesz pracownika zwolnić, bo nie ma ludzi na jego miejsce i oni o tym wiedzą i faktycznie nie ma żadnego bata na tych od poziomu mid/senior.
Czasem nawet czuję się bezradny, gdyby rekrutacja przynosiła jakiekolwiek rezultaty, to 1/4 zespołu bym zwolnił, a 1/4 rozstrzelał.
Jasne, wiem, są inne metody niż przemoc. Faktem jest, że przemoc jest najprostsza i w innych branżach się sprawdza. Pracownicy robią, co im się każe, bo się boją zwolnienia, a tutaj trzeba budować autorytet, dobry klimat itp. poprzeczka jest 50x wyzej niż w zwyklej fabryce, gdzie za brama kolejni ukraincy.
2
Zależy to od osobistych preferencji oczywiście (oraz sytuacji w firmie, każdy taką pozycję rozumie nieco inaczej). Ale w moim przypadku - tl;dr; - nie opłaca się.
Udało mi się wybić technicznie na swoim stanowisku i jak zmieniałem projekty w firmie to szła za mną dobra renoma, że nie tylko potrafię zająć się swoimi obowiązkami ale też nakreślić kierunek dla całego zespołu czy projektu. To było podstawą do zaproponowania mi awansu na tech leada (przy testach). Projekt kłopotliwy ze względu na dużą ilość legacy, niedawną wymianię dużej ilości kontraktorów, słaba dokumentacja.. czyli norma. W tej korporacji jest wyraźny podział między tech leadami a line menadżerami - czyli w czystej teorii ja zajmuję się sprawami technicznymi, kieruję ludźmi ale bardziej od strony zadaniowej czy planów na rozwiązanie problemów w projekcie niż typowe spotkania 1:1, performance review itp.
Dostałem 10% podwyżki z 'szansą na więcej' jak się wykażę, 8 zespołów 'pod sobą' - w tym kilkanaście osób bezpośrednio ode mnie zależnych (zespoły te miały własne struktury, układ wynikał z faktu, że zajmowałem się i kierowałem działką testów w całym projekcie gdzie poszczególne zespoły miały jakieś swoje wyszczególnione działki). Pełną rękę do zmian w stacku technologicznym, organizacyjnym czy nawet wymiany ludzi (jak zajdzie potrzeba).
No i wynik jest taki, że po kilku miesiącach zmieniłem firmę.. . Nawet z pełnym wsparciem "z góry" nie było dla mnie możliwe ogarnięcie tego wszystkiego z poszanowaniem work-life-balance. Nigdy nie pracowałem na nadgodzinach - co praktykowało większość leadów. Niestety pozycja wymagała zrozumienia technicznego wszystkich aspektów projektu (a więc to, co robi 8 zepołów przy czym każdy miał inne tematy i problemy), pomóc i pokierowanie ich, a zarazem 1/3 mojego czasu była spotkaniami (to i tak po ukróceniu i wyraźnym zaznaczeniu co myślę o spotkaniach, które mogłyby być emailem). Również wszelakie devopsowe taski na mnie spadały (lubię je robić ale zabierało to czas). Zrozumienie domeny biznesowej i odpowiednie planowanie pod nią (chociażby dyskusje z analitykami, planowanie pracy itp). Rekrutacje. Problemy interpersonalne.
Byłoby to możliwe gdybym podszedł do sprawy mocno olewczo i "pchał taczkę do przodu" jak zapewne robiła to większość przede mną na tym stanowisku. Nie było to jednak dla mnie akceptowalne. I na dłuższą metę pojawiał się dług (w postaci nierozwiązanych, odłożonych na później problemów), który w końcu by mnie 'dopadł'. A wszyskto to za nie wiele % więcej niż na normalnej pozycji przy ogromnie zwiększonej odpowiedzialności. Osobiście wolę rolę 'indywidualnego kontrybutora' - który może mieć wpływ na cały zespół/projekt, ale bez brania na siebie oficjalnie odpowiedzialności jako lead. Zdecydowanie za niska różnica w wynagrodzeniu, aby to ryzyko i dodatkowy stres się opłacał.
3
Jedną z trudniejszych umiejętności jako TL jest nauczenie się słuchać, i czasami przyznać że nie ma się racji. Najgorsza rzecz, to gdy kilka osób próbuje Ci coś przetłumaczyć, a Ty i tak robisz swoje bo wydaje się że wiesz najlepiej.
Popracowałem tak przez chwilę, bardzo fajne doświadczenie - ale zrezygnowałem na razie, uznałem że to za wcześnie w mojej karierze. Docelowo jest to na pewno ścieżka w której można się spełnić, trzeba tylko przestawić swoje myślenie na to, że wcale nie trzeba dużo kodować, i sukces jest całego zespołu, a nie tylko Twój indywidualny.
2
Jeżeli masz wysokiego technicznego skilla i odnajdujesz się w zarządzaniu ludźmi, to zakładaj własną firmę, co będziesz na kogoś robił ;) Awans na team leada to w większości przypadków stopniowa degradacja umiejętności technicznych na rzecz umiejętności typowo liderowych, chyba, że nadrabiasz po godzinach. Moim zdaniem to krok w stronę harowania całe życie na cudzą firmę. Swoją będzie Ci cięzko założyć jeżeli staniesz się nietechniczny.
11
Role TL dlugoterminowo wyobrazam sobie tylko w sytuacji gdybym mial realny wplyw na produkt/firme/zespol/budzet itp itp.
Z tego co obserwuje wiekszosc firm "czelendżuje" takiego TL do wiekszego wysiłku nie dajac mu ku temu odpowiednich narzedzi. Wciskajac kit o tym ze rola TL to jakas nobilitacja i przywilej.
Bylem przez okolo 1,5 roku jedynym Seniorem w zespole powiedzmy ze cos 'a'la taki' "Tech Lead" zespol byl maly ja + 5 osob.
Ja jako "Tech Lead" (troche kodowałem (backend) i devopsowe tematy) + rola SM + delagacja zadan + prezentacje dla stakeholderow + spinanie wszystkiego tj. releasy releas notki + dokumentacja wyznaczanie celow ogolnie pilnowanie zeby szlo do przodu itp itd.
Role PO przyjal nietechniczny manager ktory rownoczesnie byl moim bezposrednim zwierzchnikiem.
Moje bycie "Tech Leadem" stalo sie przypadkiem dostalem awans na tego "jedynego" Seniora w Teamie i tak jakos 'wyszlo'.
W duzym skrocie otrzymałem wymagania dlugoterminowe i "radz sobie". Na PO nie mozna bylo liczyc.
Mialem szereg problemow:
- nigdy nie doprosilem sie o frontendowca - zeby sobie poradzic jeden junior backendowiec wyrazil chec dlubania w React - wiec go przerobilismy problem byl taki ze nie mial duzych umiejetnosci w temacie ani backup-u i nie bylo komu robic review - w odsieczy management dla wsparcia w wakacje zaoferowal mi stazystow z Indii - nie wiem ilu ich bylo 3 czy 5 szkoda czasu
- nie doprosilem sie nigdy o zaden budzet szkoleniowy albo chociaz jakis czas na nauke dla ludzi z teamu
- nie mialem wplywu na ksztalt zespolu - czyli byly np. takie wrzuty "Janusz z teamu znika i bedzie robil super wazne cos w innym projekcie 2 tygodnie"
- zmiana zakresu sprintu + wrzutki w trakcie to standard
- nie znalem budzetu na rekrutacje wiec firma odrzucano wiekszosc kandydatow ktorych zaakceptowalem pewnie z powodu $
- dobila mnie pewna sytuacja gdy chcialem zatrzymac 1 stazyste - mozna powiedziec ze "walczylem o goscia"- firma chciala trzymac goscia na stazu 9 msc - nie chcieli mu dac stanowiska Juniora po 3 msc ani nawet po 6 msc wynagrodzenie na stazu bylo zbyt niskie - odszedl - przyszedl kolejny stazysta i odszedl tak wkolo a ja tracilem czasu na wdrazanie itp itd to bylo mega frustrujace
- brak wymagan + a potem oranie zrobionych ficzerow na froncie "bo tak"
Po okolo 1,5 roku szarpaniny projekt przeszedl do maintenance (dlubie tam czasem 1-2 dev-ow) a ja z czescia zespolu odszedlem do innego wiekszego projektu byc zwyklym 'jednym z wielu'.
Tak czy siak wlozylem w ten projekt sporo wysilku i pracy a przestawili mnie jak "stare szafe". Dałem sie troche złapać jak "uczniak". Tak czy siak nie zaluje tej szarpaniny mimo wad byly zalety.
Chcialem "cos zbudowac" od A do Z i mialem satysfakcje z tworzenia czegos w grupie, podobalo mi sie to jak widzialem jak wszyscy ida "w gore" i jak momentami dobrze sie to zgrywalo mimo niesprzyjajacych okolicznosci. Mialem wplyw na technologie + jakosc kodu + review standardy itp itd. Mogłem zaadaptowac w projekcie to co chcialem.
Mialem wrazenie ze ludzie chcieli ze mna pracowac i wszystko szlo "przeze mnie". To poczucie "sprawczoscii" bylo OK w calosci to bylo dobre doswiadczenie.
Aktualnie jestem na takim etapie w zyciu ze nie przyjalbym takiej roli "w ciemno". Chcialbym na papierze konkrety co nalezy do moich kompetencji/ co moge / i co na tym zyskam.
Jestem troche starszy duzo bardziej wyrachowany i bardziej nastawiony na "moj interes" niz piekne idee i mydlenie oczu.
8h i elo - mam wlasne inicjatywy po pracy i wole robic "swoje" najlepiej jak umiem bez wiekszego zaangazowania tj. "wykonalem profesjonalna robote" pozdro600.
0
Praca TL to po pierwsze odpowiedzialność, więc jak ktoś odpowiedzialny nie jest lub nie lubi na siebie brać odpowiedzialności to niech sobie odpuści.
Miałem raz czy dwa propozycję TL ale odmówiłem bo 1) mam dość nędzny soft skills 2) źle znosił bym stres związany z odpowiedzialnością.
Z punktu widzenia rozwoju kariery od pewnego momentu zarobki menago >> zarobki programisty, także opłaca się. Należy jednak pamiętać że kadra zarządzająca na UoP ma zawsze nielimitowany czas pracy, czyli siedzisz aż zrobisz.
Z byciem manago wiąże się sporo przywilejów:
- Będziesz wiedział o rzeczach o który pracownicy dowiedzą się za miesiąc an townhall/all-hands/czy jak to teraz zwią
- Będziesz wiedział kto odchodzi oraz będziesz miał znaczny wpływ na to kogo firma zatrudni
- Większy respekt w firmie, jak napiszesz do działu IT że Tobie Manago JIRA nie działa to inaczej do tego podejdą
- Pojawia się możliwość zupełnego zerwania z technologią, jak komuś już się koderka znudzi.
Wady:
- Rynek pracy dla manago jest mniejszy i nie tak elastyczny/chłonny jak rynek programistów. W czasie kryzysu usuwa się najpierw najmniej istotne elementy systemu (te co nie produkują kasy) także menago może polecieć jako pierwszy, bo zespoły można zawsze połączyć.
Warto zauważyć że większość firm uznaje za sukces projekt który zupełnie się nie wykoleił. Także nawet zabugowana aplikacja której nikt nie używa, ale na produkcji to sukces. Nie każdy wytrzymuje ten i inne korpo bullshity...
3
@0xmarcin:
Będziesz wiedział o rzeczach o który pracownicy dowiedzą się za miesiąc an townhall/all-hands/czy jak to teraz zwią
Będziesz wiedział kto odchodzi oraz będziesz miał znaczny wpływ na to kogo firma zatrudni
To zależy. Taki wgląd "za kulisy" można mieć nawet nie mając oficjalnego stanowiska managerskiego/lead. Jeśli masz wystarczającą renomę/wpływ na projekt to niekoniecznie musisz mieć oficjalne stanowisko do czegoś takiego. Ja np. brałem udział w cotygodniowych spotkaniach zarządu, mimo że byłem tylko senior programistą.
0
Ogólnie widzę, że co firma, to inna definicja team leada. U nas to jest wlasciwie techlead - gość, który decyduje o rozwiązaniach i zatwierdza istotne zmiany w repo + pomaga niższym programistą, jak czegoś nie wiedzą.
0
gość, który decyduje o rozwiązaniach - no jak nic do architekta mi to pasuje, zatwierdza istotne zmiany w repo to nie macie czegoś takiego jak CR? pomaga niższym programistą, jak czegoś nie wiedzą. no to pasuje jak najbardziej do TLa.
2
Zależy ;) podejrzewam, że różnie to wygląda w różnych firmach.
Z moich obserwacji:
Pójście w leadowanie ma sens, jeśli ktoś ma dość czy nie chce zajmować się z kwestiami implementacyjnymi.
Śmiem twierdzić, że jeśli chodzi o TLa, umiejętności miekkie są dużo ważniejsze niż bycie kozakiem pod względem technicznym.
Trzeba umieć motywować ludzi, maksymalizować potencjał, odczytywać nastroje i wiele innych.
Jeśli ktoś to umie, i nie jest przy tym totalnym nieogarem pod kątem technicznym, powinien dać sobie radę.
Sama znajomość technikaliów nie czyni dobrego TLa. Doskonały developer może być beznajdziejnym liderem.
Praca TLa ma też trochę inną specyfikę z tego względu, że trudniej się skupić na jednej kwestii i iść na głebokość.
A to wpada spotkanie, tu trzeba rekrutować, tu robić prezentację, tu łagodzić konflikt w zespole itd.
To nie każdemu pasuje, zależy od osobowości.
Jeśli ktoś lubi skupiać się kwestiach technicznych, lubi działac blisko kodu, lubi wgryźc się jakiś aspekt projektu, może mieć problem z przestawieniem się na rolę leada. Dobry lead powinien umiec odpuścić i powierzyć innym programowanie. Bez tego łatwo się zajechać, próbując grzebac w kodzie na przekór pierdylionowi nowych obowiązków związanych z leadowaniem, albo zostać micromanagerem zamęczających innych ciągłym wtrynianiem się w szczegóły implementacyjne.
0
@.andy to właśnie dowodzi temu jak różnią się te definicje w zależności od miejsca. Nawet taki tech lead może oznaczać co innego- bywa właśnie że każdy zespół ma swojego tech leada jak wspomniał @renderme, a ja się również spotkałem z tym że tech lead to był taki "główny" architekt. Paradoksalnie, nie było tam takiego stanowiska jak architekt.
4
@Aventus: Bo junior, senior, tech lead, architekt, CTO to tylko nazwy. Liczy się to co masz zrobić, ile ci za to zapłacą i jaki masz wpływ na projekt.
0
@piotrpo: tak można by powiedzieć o jakiejkolwiek roli, niekoniecznie w branży IT. Uważam że Twoje stwierdzenie jest "trochę" na wyrost.
To nie są tylko nazwy. Mają po prostu różne znaczenie w danym kontekście (firmie), ale znaczenie mają.
3
@Aventus: Skoro mają różne znaczenie w różnym kontekście, nie mówiąc już o skali (architekt w projekcie za 20k a architekt (z tą samą odpowiedzialnością w projekcie za 100 baniek, to jednak różne sprawy), to ciężko o określenie ich znaczenia.
Dla mnie - senior, mid, junior, to jedynie sprawianie wrażenia postępu i jakiś tam dodatek "prestiżu". Architekt jest rolą bardzo różnie rozumianą i jego głównym zadaniem jest, żeby części systemu gadały ze sobą. Tech lead jest dla mnie kompletnie rozmytą odpowiedzialnością - w niektórych firmach, to po prostu brygadzista, który podejmuje podstawowe decyzje na poziomie zespołu, w innych odpowiada za konkretną technologię (taki namaszczony ekspert np. od CI/CD, Javy, czy jakiegoś frameworku). W jeszcze innych projektach pełni rolę architekta, tylko ma inny tytuł.
Patrząc na moją firmę, mamy team liderów, którzy mają ogarniać kuwetę w ramach jednego zespołu, mamy też 3 poziomy architektów, (system, solution, enterprise), nie mamy za to tech leadów jako takich. Dla osób technicznych, nie mających aspiracji podpisywania wniosków urlopowych jest ścieżka "technical fellowship", i trafiają tam ludzie z publikacjami, patentami, udzielający się na konferencjach, albo wybitni specjaliści w jakiejś dziedzinie technicznej.
0
@Aventus:
@.andy to właśnie dowodzi temu jak różnią się te definicje w zależności od miejsca.
Masz rację. TL to nie stanowisko a bardziej rola w projekcje.
1
@piotrpo: ale przecież tym co napisałeś (poza tytułem od juniora do seniora) potwierdziles właśnie że mają różne odpowiedzialności, a więc coś znaczą. Sam sobie zaprzeczyles...
Co do junior-senior to ok, być może takie masz z tym doświadczenie. Jeśli tak jest to współczuję (bez uszczypliwości). U mnie te role również mają znaczenie, bo określają czego można się spodziewać od kogoś z danym tytułem, jaki jest zakres odpowiedzialności oraz jak bardzo należy uważać i pilnować zmian dokonywanych przez daną osobę. Oczywiście, są osoby które powinny mieć tytuł niżej lub wyżej, ale to raczej wyjątki niż norma.
0
Aventus napisał(a):
@piotrpo: ale przecież tym co napisałeś (poza tytułem od juniora do seniora) potwierdziles właśnie że mają różne odpowiedzialności, a więc coś znaczą. Sam sobie zaprzeczyles...
Ale to różnie bywa, zależnie od organizacji.
Co do junior-senior to ok, być może takie masz z tym doświadczenie. Jeśli tak jest to współczuję (bez uszczypliwości). U mnie te role również mają znaczenie, bo określają czego można się spodziewać od kogoś z danym tytułem, jaki jest zakres odpowiedzialności oraz jak bardzo należy uważać i pilnować zmian dokonywanych przez daną osobę. Oczywiście, są osoby które powinny mieć tytuł niżej lub wyżej, ale to raczej wyjątki niż norma.
Ale jakie to ma znaczenie? Jak ktoś jest seniorem, to ma rację, a junior z założenia ma same głupie pomysły?
0
Jak ktoś jest seniorem, to ma rację, a junior z założenia ma same głupie pomysły?
Skąd taki wniosek?
1
@piotrpo:
Ale jakie to ma znaczenie? Jak ktoś jest seniorem, to ma rację, a junior z założenia ma same głupie pomysły?
Nie ale nie będziesz oczekiwał żeby junior zrobił giga trudne zadanie, z którym nawet mid/senior będzie miał problem
1
zgrzyt napisał(a):
Ja uwazam, ze nie warto po 1 odpowiedzialnosc po 2 kontakt z ludzmi czesto jest na zasadzie, zrob to zrob tamto. Jezeli lubisz rozkazywac i duzo spotkan to okej. Poza tym beda cie traktowac jako przelozonego, a nie jak kumpla z zespolu. Jedyny plus jest taki, ze zdobywasz doswiadczenie w zarzadzaniu ludzmi i mozna pozniej awansowac na jakiegos dyrektora, co moze znacznie podniesc zarobki, ale samo wejscie na stanowisko dyrektorskie jest juz bardzo trudne ze wzgledu na konkurencje.
Chyba jedno z najlepszych podsumowań:) >> krótko zależy od firmy, ale co do zasady nie warto.
3
Tak czytam niektóre komentarze w tym wątku jak np. ten cytowany powyżej i mam jedną refleksję - dlatego dobrych liderów jest i będzie tak niewielu :)
0
Czy zmiana stanowiska z leader'a na stanowisko seniora lub zwykłego programistę w innej firmie jest degradacją czy można to uznać jako ten sam poziom?
2
Jedyne poziomy na które warto zwracać uwagę to:
- rozwój
- rodzaj projektu
- co się w tym projekcie NAPRAWDĘ robi
- kasa
Nie wiem jak inni, ale ja zwyczajnie ani nie zatrudnię gościa, bo w poprzedniej firmie został jakimś zrządzeniem losu "seniorem", "team leadem", czy co mu tam kreatywność HR wrzuciła dla podbudowania ego. Z drugiej strony nie odrzucę CV gościa, który ma dużą wiedzę, umiejętności i doświadczenie, tylko dlatego, że gdzieś tam mieli np. płaską strukturę, albo stołek na który ma kwalifikacje był juz zajęty przez jakiegoś przyssanego gościa o często skromnych możliwościach.
Przeszedłem w IT ścieżkę od leszcza do architekta. Po drodze byłem np. "Technology Leaderem" w sporej firmie i bez mrugnięcia okiem przeszedłem do innej firmy na stanowisko "software developer", przeszedłem do kolejnej firmy gdzie zostałem "chief programmer" (dla 2-3 dodatkowych osób...) i wykonałem zmianę znowu na "software developer bez przymiotników", po czym skoczyłem z tego tytułu na "coś tam architekt".
Z każdym z tych przejść okazywało się, że pomimo sinusoidy w nazwach stanowisk, za każdym razem okazywało się, że:
- spotykam ludzi, od których mogę się czegoś nauczyć
- mój wpływ na projekt (z małymi wyjątkami) rósł
- robię coraz ciekawsze rzeczy
- zarabiam coraz więcej (nawet pomijając generalny wzrost płac)
Jeżeli aktualna firma naprawdę mnie czymś zirytuje, albo dostanę propozycję dużo ciekawszego projektu w działce, która mnie interesuje, albo zwyczajnie zapłacą mega hajsy, to decyzję będę podejmował niezależnie od tego jak się będzie nazywać stanowisko na które będę miał przejść.
2
Widząc ile pracy ma mój team leader to stwierdzam, że jak nie dostajesz fajnego dodatku do pensji to się nie opłaca.
1
Czy zmiana stanowiska z leader'a na stanowisko seniora lub zwykłego programistę
TL to rola, a nie stanowisko.
0
@.andy: Możesz rozjaśnić (lub ktoś inny) jaka jest różnica? Już kilka razy zderzyłem się ze stwierdzeniem że "X to rola, a nie stanowisko" ale nie znam różnicy.
0
@.andy: Zgodziłbym się gdyby obowiązki jednej strony nie dominowały drugiej, spokojnie jesteś w stanie zdominować pracę zadaniami leada i mieć np 30% albo mniej czasu na pisanie kodu, zwłaszcza jak dopiero zaczynasz i nie umiesz poprawnie delegować rzeczy. Do tego zwykle na stanowisku leada nie jesteś oceniany z tego jaki kod piszesz, tylko z aspektów leadershipowych.