Czy warto być team leaderem?

Cześć,

Około rok temu zostałem team leaderem nowego zespołu, bo zostałem doceniony za pracę w moim ówczesnym zespole, pchanie tego wszystkiego do przodu i to chyba nawet w dobrym kierunku.

Po tym roku, zadaje sobie pytanie, czy było warto. Konkretnie mam na myśli to, że obecnie w pracy każdy dzień to jest trochę "walka o przetrwanie". Próbuje zrobić ile tylko mogę, ale wiadomo, w ciągu dnia mam dużo przerw, dużo osób coś ode mnie chce, wielu osobom pomagadam, wyjaśniami itd. itd.. Moi przełożeni są raczej zadowoleni z tego jak to wszystko idzie, ale zaczynam obawiać się tego, że będę miał tego dość (albo może już mam skoro piszę tego posta). Wracając wspomnieniami do czasów, kiedy nie byłem team leaderem, to czuje się, że byłem wtedy dużo mniej obciążony psychicznie. Robiłem rzeczy, pisałem kod, rozmawiałem z ludźmi, ale nie czułem, że każdy dzień to jest walka (no może czasem ale bardzo rzadko :) ). Możliwe, że sam na siebie narzucam takie, powiedzmy, "wymagania" albo sam się nakręcam, więc może to też kwestia mojego podejścia i muszę nad tym popracować, ale to trochę inny temat. Oczywiście dostałem podwyżkę więc robię to nie za darmo, ale wiedząc ile zarabiają ludzie w moim zespole, zarabiam tylko 10-20% więcej niż oni więc nie jestem przekonany czy te pieniądze są tego warte. Pewnie kolejną odpowiedią na pytania z tematu byłoby "zależy w jaką stronę chcesz się rozwijać". Pewnie też, ale chciałem zapytać jakie Wy macie opinie na ten temat.

mój znajomy też dostał taki "awans" po 3 miechach zmienił firmę :D to zależy od indywidualnej sytuacji, bardzo trudno będzie Tobie coś doradzić... to zależy od zbyt wielu czynników.

Moim zdaniem nie, wszystkich team leaderów których poznałem robili nadgodziny, oprócz programowania w Sprincie mają sprawy organizacyjne i tym podobne rzeczy, do tego dochodzą 'meetingi' organizacyjne i zwyczajnie się nie wyrabiają. Jeżeli nie umiesz wyznaczać granic na początku projektu, obowiązków jako Team Leader to może Ci być ciężko być taką osobą.

Warto dla kogoś kto to lubi i się do tego nadaje. Serio.

W tej branży często bycie team leadem wydaje się naturalnym krokiem na ścieżce kariery, ale to nie jest takie proste. Oczywiście team lead w każdym miejscu może oznaczać coś innego, ale najczęściej to taki senior (a więc osoba techniczna) z częściowymi obowiązkami HRowymi (zarządzanie członkami zespołu). No i tu jest właśnie haczyk- bo nie każdy musi lubić lub się nadawać do obowiązków HRowych.

Najlepiej jeśli firma ma dwie ścieżki rozwoju- zarządzania ludźmi i zarządzania technicznego. Te drugie też nie zawsze do każdego będzie pasować, a zaryzykowałbym stwierdzenie że już team lead bardziej uniwersalnie przypasuje do większości osób.

Ja w swojej obecnej pracy dostając sygnały że szykuje się dla mnie awans dawałem jasno do zrozumienia że nie interesuje mnie ścieżka team leada, w związku z czym firma w zasadzie dla mnie utworzyła stanowisko techniczne (dla mnie teraz, wraz ze wzrostem firmy będzie coraz większe zapotrzebowanie na takie role oczywiście).

No i pamiętajmy również że nie każdemu musi pasować większy zakres odpowiedzialności niż np. ma senior programista. Nie ma obowiązku awansu, a dobry pracodawca nie powinien mieć problemów ze zwiększaniem płacy wartościowej osobie na tym samym stanowisku. Jeśli taki problem jest, to warto pomyśleć nad zmianą pracy. Ewentualnie cieszyć się tym co się robi, jeśli taki stan rzeczy odpowiada.

ja się spotkałam z sytuacją ze był sekretarzem kierownika, i orþcz tego kapłanem scruma , właściwie nie wiem jaki teoretycznie powinien być zakres jego obowiązków? Według mnie na każdym kierowniczym stanowisku trzeba mieć jaja (metaforycznie) , a takie osoby właśnie z tego powodu często nie są awansowane ;) Chyba w jakimś poradniku zarządzania czytałam że najpierw taka osoba powinna zarządzać ludźmi a potem dostać awans który tylko potwierdzi stan faktyczny

Czy będąc team-leaderem czujecie, że pracujecie więcej? Praca was bardziej angażuje? (nadgodziny itp.)

Ja pracuję w zasadzie prawie zawsze mniej niż 8 godzin dziennie, ale na pewno jest to bardziej stresujące - to w dużej mierze zależy od organizacji w firmie, w mojej zespoły mają stosunkowo dużą autonomię ale to też ma minusy:

• natłok obowiązków jest znacznie większy niż jako senior i na początku było to problemem, z czasem zmieniłem sobie organizację (trackery, kalendarze, odrzucanie spotkań gdzie nie ma dobrej agendy albo takich które można zastąpić mailem, blokowanie sobie czasu w ciągu dnia) i zacząłem delegować (tutaj też można to zrobić na wiele sposobów i na początku poleciałem trochę w delegowanie małych tasków bez kontekstu co oczywiście się nie sprawdziło)
• czasami musisz zajmować się "trudnymi sprawami", bo na przykład masz budżet który nie pozwoli na dwa awansy mimo że dwie osoby sobie mocno na te awanse zasłużyły i wiesz że ktoś z tej dwójki przez to odejdzie
• musisz patrzyć na perspektywę poza zespołem - jakie projekty czy inicjatywy dzieją się w firmie i jak mogą wpływać na zespół (np jak trzeba kogoś zrekrutować to musisz o to zadbać 3-6 miesięcy wcześniej), jeśli coś nie jest jasne to czasami trzeba pomóc PO albo analitykom i wyciągnąć od innych zespołów jakieś informacje
• musisz być wystarczająco stanowczy żeby dbać o interesy zespołu i umieć odpowiednio rozmawiać z ludźmi z biznesu czy z twoimi przełożonymi tak żeby zespół nie ucierpiał bo np. ktoś podważa wasze estymaty albo próbuje narzucić durne praktyki, albo macie PO który nie umie napisać historyjki tak żeby ktoś to zrozumiał
• jesteś pierwszym punktem kontaktu z zespołem więc nawet z ogarniętym PO musisz wiedzieć więcej o kontekście biznesowym tego co się robi i jak to wpływa na inne procesy w firmie, o tym jak wszystko jest zaimplementowane (tutaj przydaje się dobra dokumentacja do której można kogoś odesłać i mieć spokój), musisz kojarzyć zakres pracy i ludzi z zespołów które są organizacyjnie bliżej ciebie
• jesteś odpowiedzialny za procesy w zespole, więc siłą rzeczy musisz sobie pogodzić te dodatkowe obowiązki jak takie bardziej strategiczne planowanie, zajmowanie się trochę project managementem, rekrutacjami i innymi dziwnymi rzeczami i przynajmniej połowę czasu musisz spędzić faktycznie jako developer, a zwłaszcza na początku to nie jest łatwe
• jesteś odpowiedzialny za wyniki pracy zespołu, więc jak coś wybuchnie na produkcji, to ty jesteś za to odpowiedzialny bo procesy za które jesteś odpowiedzialny tego nie wyłapały
• jesteś odpowiedzialny za rozwój ludzi, w tym takich którzy niekoniecznie wiedzą co chcą robić ani jak się rozwinąć

Generalnie to jest trochę połączenie developera z zupełnie innymi rolami, na pewno nie każdemu coś takiego pasuje. Ja się na to zgodziłem bo bycie czysto developerem mi się zaczęło nudzić a to jest coś innego, ale długoterminowo nie widzę się w tej roli - mimo wszystko sporo można się nauczyć.

Też jestem leadem :P i musze powiedziec, ze to strasznie trudne i niewdzieczne zadanie.

W tej branzy kazdy jeden 2+ lat senior wie wszystko najlepiej i nikogo nie slucha.
Nie polecam.

Miang napisał(a):

ja się spotkałam z sytuacją ze był sekretarzem kierownika, i orþcz tego kapłanem scruma , właściwie nie wiem jaki teoretycznie powinien być zakres jego obowiązków? Według mnie na każdym kierowniczym stanowisku trzeba mieć jaja (metaforycznie) , a takie osoby właśnie z tego powodu często nie są awansowane ;) Chyba w jakimś poradniku zarządzania czytałam że najpierw taka osoba powinna zarządzać ludźmi a potem dostać awans który tylko potwierdzi stan faktyczny

Dlatego szczególnie nie warto, jeśli ktoś poszedł na informatykę nie po to żeby rozmawiać z ludźmi i ma problemy z komunikacją. Tymczasem ludzie miewają problemy już na starcie, bo na rozmowie kwalifikacyjnej. Komunikatywność i ogólnie umiejętności miękkie to coś, w czym braki są zdradliwe. Niby można żyć w piwnicy, ale wtedy narzeka się na to jaki świat jest okrutny i że trzeba gadać z ludźmi. I że jako kierownik ma się nadgodziny, bo się zgodziło na taką umowę.

jak patrze na mojego TL, nie warto. Jakbym mial sie uzerac z junioro-seniorem co robi nazwy metod z d**y, overcomplicated kod, a na koniec wisienka na torcie jest PR z niedzielajaca funkcjonalnoscia lub pierwszy lepszy corner wywala temat, fuck this shit, a na dokladke wszystkie te dodatkowe tematy wymienione wyzej, fuck this shit. Chyba ze z 2.5x raise, ale tak na pewno nie ma fuck this shit

Mi się zdarzyło bywać TL (w małych firmach się po prostu bywa w konkretnych projektach) i bardzo to lubię, z chęcią bym porzucił kodowanie na rzecz zarządzania. Nawet planuje zrobić podyplomówke z zarządzania. Miałem to zrobić już ale nie chce robić tego zdalnie a zaraz znowu wszystko bedzie zdalne bo covid.

Byłem w firmie, gdzie w pierwszej kolejności wyposażono komputery Team Leaderów w dyski SSD! :]
A dopiero potem reszta dostała upgrade.

U mnie TL zarabia mniej więcej w okolicach widełek seniora. A obowiązków ma w cholerę, często po godzinach siedzi, robi rzeczy devopsowe, czasem kodzi, spotkania, faktury, w cholerę tego. Mnie by szlag po paru dniach trafił. Jak dla mnie szkoda zdrowia.

Wszystko zależy od płacy :D TL oprócz części technicznej ma również masę innych obowiązków, głównie typowo hr'owe spotkania (Z klientem, wyższym mgmt etc). W mojej obecnej firmie porównując mój kalendarz do TL, ratio spotkań to ok 1:3. Trzeba też to lubić... Osobiście irytowały by mnie ciągłe spotkania adżajlowo-skramowo-organizacyjne i inne bohomazy... No chyba, że dodatek do pensji był by sowity :P

Regułą kciuka jest to, że jeżeli ktokolwiek w zespole robi nadgodziny to wynika to z niekompetencji leadów, product ownerów lub product managerów przy szacowaniu historyjek. Skąd wynika Twoja presja na nadgodziny? Sam ją sobie narzucasz? Chcesz udowodnić swoim kolegom z pracy, że jesteś leadem bo dowozisz w sprincie najwięcej story pointów przez robienie nadgodzin? Przecież lead nie musi dowozić najwięcej kodu. Jeżeli product manager narzuca deadline to jaki proces myślowy poprzedził te szacunki? Zgadywanie?

Zwykle zadaniem leada jest to, żeby podnieść wydajność całego zespołu, żeby nie było tak, że jest jakaś owieczka, która coś tam sobie dłubie na boku i jest zablokowana od tygodni. Lead musi za wczasu identyfikować takie owieczki i pomagać im się odblokować. Dodatkowo lead może przełamywać remisy w dyskusjach. Jeżeli zespół się spiera nad jakimś rozwiązaniem to lead zadając dodatkowe pytania i ustalając jakieś cele może pomóc zespołowi rozstrzygnąć w którą stronę wszyscy mają iść. Ale lead sam w sobie nie musi narzucać rozwiązań, może, a nawet powinien je delegować. Inaczej kończysz jak OP.

@twoj_stary_pijany:

Jeżeli zespół się spiera nad jakimś rozwiązaniem to lead zadając dodatkowe pytania i ustalając jakieś cele może pomóc zespołowi rozstrzygnąć w którą stronę wszyscy mają iść.

To już zależy od konkretnej firmy, a nawet zespołu w ramach tej samej firmy. TL niekoniecznie musi być najbardziej kompetentną technicznie osobą. Wręcz przeciwnie- czasem TL idzie ta ścieżką właśnie dla tego że nie jest najmocniejszy technicznie.

Oczywiście inaczej to wygląda w firmach gdzie TL to właśnie przede wszystkim osoba silna technicznie. Co nie znaczy że takie rozwiązanie jest najbardziej optymalne, bo zarządzanie ludźmi i zarządzanie techniczne to różne zakresy odpowiedzialności.

Zgadzam się. Są różne poziomy techniczności leada. Ja osobiście wolę być techniczną osobą w zespole bo mam więcej czasu na robienie kolegom review oraz własny research. Lead natomiast często w obowiązkach ma rozmowy dydaktyczne gdzie musi ustawić jakąś agresywną osobę do pionu i pilnować takich miękkich tematów. Mnie osobiście takie dyskusje strasznie męczą chociaż nie ukrywam, że czasem można pomóc taką rozmową jakiemuś koledze z zespołu wskoczyć na wyższy poziom i to jest bardzo satysfakcjonujące.

Co do zespołów gdzie lead jest osobą najsilniejszą technicznie. Mam wrażenie, że jest to pułapka. Mając obowiązki dydaktyczne nie da się być ze wszystkim na bieżąco. Jedna osoba, nawet jeżeli zaczyna jako najbardziej kompetentna technicznie, prawie na pewno po np. roku zostanie prześcignięta przez jakiegoś młodego wilczka z zespołu pod względem technicznym. Lead jest skazany na porażkę w takim bezpośrednim starciu.

co do nadgodzin to tez kwestia psychiki. Mi szef kiedys cos powiedzial, ze o 17 30 dostaniemy materialy i zebym przejrzal, to powiedzialem, ze o 17 30 bede juz po 6 browarze i nie ma opcji, zebym siedzial nagodziny.

Niech sie gosc ogarnie, mam 6 pracodawcow na jego miejsce.

Aventus napisał(a):

@twoj_stary_pijany:

Jeżeli zespół się spiera nad jakimś rozwiązaniem to lead zadając dodatkowe pytania i ustalając jakieś cele może pomóc zespołowi rozstrzygnąć w którą stronę wszyscy mają iść.

To już zależy od konkretnej firmy, a nawet zespołu w ramach tej samej firmy. TL niekoniecznie musi być najbardziej kompetentną technicznie osobą. Wręcz przeciwnie- czasem TL idzie ta ścieżką właśnie dla tego że nie jest najmocniejszy technicznie.

Oczywiście inaczej to wygląda w firmach gdzie TL to właśnie przede wszystkim osoba silna technicznie. Co nie znaczy że takie rozwiązanie jest najbardziej optymalne, bo zarządzanie ludźmi i zarządzanie techniczne to różne zakresy odpowiedzialności.

Tutaj nawet nie chodzi o siłę techniczną tylko moderację dyskusji. Nie trzeba być geniuszem żeby wiedzieć że dyskusja toczy się w kółko i wracają te same argumenty, nawet głupie spisanie tego wszystkiego na żywo tak żeby ludzie mieli tabelkę z zaletami i wadami i wnioskami które się wyciągnęło jest w stanie bardzo szybko takie dyskusje nakierować i pozbyć się wtrąceń ludzi którzy słuchali jednym uchem i czegoś nie zrozumieli, tak samo jak określenie konkretnego celu i porównanie wniosków z tym celem, albo ucinanie dyskusji które nie mają znaczenia dla celu. Musisz do tego być techniczny, ale nie musisz być najbardziej kompetentną osobą w zespole.

Jak wolisz chodzić na spotkania i klikać w Jirę niż kodować to tech lead jest spoko.
Tylko wtedy albo odkładasz zdobywanie doświadczenia technicznego na półkę, albo siedzisz po godzinach na swoimi mini projektami.
Niedawno dostałem ofertę na TL, powiedziałem że nie mój język (chyba był tam Python), a rekruterka na to że "nie szkodzi, TL koduje u nas maks 30% czasu, a w zasadzie język nie jest taki ważny".
Więc jak wolisz się rozwijać w umiejętnościach miękkich (czynnik ludzki), MS Office i obsłudze Teams to jest OK.

@Ąowski: podobne pytanie zadaje sobie większość młodych liderów (pierwsze ~2 lata). Jaki jest sens zmiany ścieżki kariery, skoro:

• Nie jestem w stanie kodować tyle ile kiedyś
• Brakuje mi sprawczości, zamiast dowozić pisze jakieś maile
• Zamiast robić to w czym jestem dobry, muszę latać po spotkaniach, na których widzę swoje braki np. w komunikacji (ciężko przegadać PM-a albo byc partnerem dla osób nietechnicznych)
• Kiedyś brałem taski z Jiry, teraz muszę ustalić co należy zrobić i w jakiej kolejności
• Nie jestem w stanie wszystkiego skontrolować
• Jako TL muszę być najlepszy i wiedzieć wszystko
• Muszę dbać o zgranie i atmosferę w zespole oraz rozwój jego członków
• …

TL (line manager) bardziej tworzy środowisko pracy dla swojego zespołu, aby ten działał w sposób efektywny oraz dba o rozwój członków zespołu i do niego rekrutuje. Twoim zadaniem jest robić robotę „za pomocą” zespołu, nie jesteś już indywidualnym kontrybutorem. Twoja moc wpływu to suma wpływu członków zespołu (wg. Andiego Grove). Jesteś rozliczany z efektów.

Z czasem (jako manager, VP, …) będziesz miał więcej zadań administracyjno-HRowych i zaczniesz coraz więcej czasu poświęcać na budowanie zespołu/obszaru/organizacji. Kodowanie 30% czasu jako TL to sporo. Ja angażując się w tematy produktowe byłem w stanie osiągnąć góra 10%.

Najważniejsze na końcu - liderowanie/managerowanie nie jest dla każdego. To rola wymagająca rozwoju umiejętności miękkich takich jak pisanie, czytanie i mówienie :) Jestem przeciwnikiem robienia ze świetnych specjalistów kiepskich managerów, chociaż tak jest w większości przypadków, bo managerki trzeba się nauczyć albo hard way, albo ze wsparciem organizacji (szkolenia, mentoringi).

Co mogę doradzić:

1. Jak najszybciej znajdź sobie mentora
2. Przeczytaj https://charity.wtf/2019/01/04/engineering-management-the-pendulum-or-the-ladder/amp/
3. Przeczytaj na start „Making of a Manager” i „Od inżyniera do managera”
4. Daj sobie czas (2 lata) i zrób check. Przez ten czas skup się na tym, co daje największa wartość oraz rozwijaj skille managerskie (odstaw kodowanie, teraz rozwijasz drugą nóżkę).

@devRandom:

Tutaj nawet nie chodzi o siłę techniczną tylko moderację dyskusji. (...) Musisz do tego być techniczny, ale nie musisz być najbardziej kompetentną osobą w zespole.

Po raz kolejny zaznaczam- tutaj nadal potrzebna jest osoba najsilniejsza technicznie (zakładam że koniec końców wszystkim zależy na jak najlepszym kodzie/architekturze). Trwa dyskusja, żadna strona argumentów nie przeważa. Spotkanie ewidentnie dobiega końca, ale decyzji nadal nie ma. Zakładamy że mamy TLa i osobę najbardziej kompetentną w zespole (Bob):

TL: Ok, czyli nadal nie jesteśmy pewni? Bob, co uważasz?
Bob: Tłumaczy co uważa, i dla czego właśnie tak. Decyzja podjęta, większość przytakuje, ktoś może pokręcić nosem ale liczy się że w końcu klamka zapadła.

Ja nadal nie widzę argumentu za tym że to właśnie TL jest tą osobą podejmująca techniczne decyzje. I nie zgadzam się z tym że to kwestia moderowania dyskusji. Moderowanie to nie podejmowanie ostatecznych decyzji.

EDIT: Swoją drogą pisze tak o tym bo znam to z autopsji. W zdrowym zespole TL nie będzie miał przerostu ambicji i odda pałeczkę prowadzenia (technicznego) komuś bardziej kompetentnemu, jeśli ktoś taki jest.

EDIT 2: Działa to też w drugą stronę. Osoba silna technicznie będzie znała swoje słabości, oraz wiedziała kiedy decyzja toczy się o faktyczne dobre rozwiązanie techniczne, a kiedy dyskusja rozbija się o osobiste preferencje i trzeba wziąć krok w tył aby oddać głos komuś innemu (najczęściej właśnie TLowi).

Warto jeśli dostrzegasz ciekawe wyzwania, warto jeśli te wyzwania Cię mobilizują do szukania ciekawych rozwiązań, warto jeśli mimo zróżniowanych trudności będziesz szukał sposobu na rozwiązanie problemu, sposobu na dalszy rozwój itp a nie, że już Ci się nie chce, albo, że problem przerasta. Warto jeśli chcesz wiele wnieść od siebie i jeśli w swoich rozwiązaniach widzisz interes innych ludzi. Wtedy jak najbardziej warto, ponieważ praca z Tobą będzie dla wielu osób zaszczytem.

A tak schodząc na ziemię, jeśli np. jesteś leniem jak ja to TL to dobra opcja na lato. Ja osobiście rozważam taką opcję, gdy nie wyjdzie mi w życiu, bo w lato nie lubię zbytnio siedzieć przed komputerem. Ciągnie mnie wtedy do ludzi, lubię się udzielać, poza tym jak kilka dni nie koduję to inny ze mnie człowiek, pedantycznie dobrze zorganizowany :D

@Aventus: od razu widać, że jesteś bardzo analitycznym umysłem i uważasz, że w przypadku o którym mówisz to Bob podjął decyzję. W rzeczywistości to TL podjął decyzję na podstawie rekomendacji Boba i w taki sposób, żeby Bob czuł się ważny w zespole. TL ma takich Bobów kilku w zespole i każdy musi czuć się ważny bo każdy Bob zacznie szukać pracy jeżeli poczuje się obrażony lub ignorowany więc następnym razem TL odda decydujący głos komuś innemu, żeby ta inna osoba miała poczucie sprawczości. Widać, że Twoim celem jest przede wszystkim wygranie dyskusji i podbudowanie własnego ego (edit: powinienem napisać "celem Boba"), kiedy celem TL jest przede wszystkim to, żeby zrealizować cele całego zespołu, np. dowiezienie jakiegoś ficzeru na czas w określonym budżecie i utrzymanie/powiększenie zespołu. Bob i TL mają inne cele do zrealizowania.

Gdyby TL został przyparty do muru i byś naciskał na niego zbyt mocno to zapewniam Cię, że zobaczyłbyś projekcję siły w jego wykonaniu i byś mógł się nawet spodziewać rozmowy dyscyplinarnej od niego lub waszego wspólnego szefa.

@twoj_stary_pijany:

Widać, że Twoim celem jest przede wszystkim wygranie dyskusji i podbudowanie własnego ego

Tia, szczególnie dla tego staram się jak najwięcej trzymać z dala od decyzji podejmowanych przez poszczególne zespoły, zachęcam do osiągania porozumienia drogą konsensusu i odzywam się wtedy kiedy zostaje poproszony o dołączenie do spotkania aby doradzić :D Myślę że jak zaczynasz stosować argumenty ad personam to nie mamy więcej do dyskutowania. Dziękuję za analizę mojej osobowości na postawie kilku wpisów, nie skorzystam ;)

Wszystko zależy od tego gdzie pracujesz i jak wygląda kultura i organizacja pracy.

Ja pracowałem w takiej firmie, że nawet za 3 razy większa stawkę bym tego robić nie chciał, a w innej firmie bez problem bym się zgodził z pocałowaniem ręki.

jak jestes dynamicznym alpha male to tak

Z ciekawości, może to nie o TL, ale znacie jakiegoś dobrego menago nietechnicznego (bądź z minimalnym technicznym backgroundem)?

@ToTomki: To zależy co masz na myśli przez "dobrego menago". Tak samo co masz na myśli przez "słabego menago".

Są takie uniwersalne rzeczy jak:

• micromanagement
• totalne nieogarnięcie co robimy i po co
• brak zrozumienia jak się tworzy software
• niedocenianie osiągnięć

Ale jak zaczynasz rozmawiać z ludźmi to szybko wyłapiesz że każdy dev ma lekko inne oczekiwania :)

Możesz wymienić co doceniałeś a co cię wkurzało, biorąc pod uwagę nawet technicznych managerów?

Ąowski napisał(a):

Po tym roku, zadaje sobie pytanie, czy było warto. Konkretnie mam na myśli to, że obecnie w pracy każdy dzień to jest trochę "walka o przetrwanie". Próbuje zrobić ile tylko mogę, ale wiadomo, w ciągu dnia mam dużo przerw, dużo osób coś ode mnie chce, wielu osobom pomagadam, wyjaśniami itd. itd..

Nie wiem co w twoim przypadku oznacza rola TL, bo może być różnie w różnych firmach/zespołach. Czego oczekują od ciebie ludzie u góry (wyznaczyli ci jakieś cele?), czego oczekuje od ciebie zespół (pytałeś?). I wreszcie, zasadnicze pytanie, co w tym co robisz najbardziej ci się nie podoba?