Ile sobie można krzyknąć za team leadera ?

Powiedzmy tutaj jedno: Team Leader to bardzo szerokie pojęcie.
Czasami TL to taka osoba, która oprócz kodowania pilnuje jeszcze, żeby ludzie składali timesheety na czas. Wtedy jakichś większych umiejętności nie trzeba.
Czasami TL to taka osoba, która oprócz ganiania ludzi za timesheetami jest jeszcze odpowiedzialna za cały zespół - czyli jeśli któryś z programistów zawalił, to TL musi być i łagodzić sytuację. Wtedy TL jednocześnie musi pilnować zespołu i w miarę możliwości być osobą techniczną.
Czasami TL to taka osoba, która oprócz pilnowania zespołu jest odpowiedzialna za cały proces zespołu. Wtedy TL musi mieć wiedzę z zakresu procesów powstawania oprogramowania (tj. musi wiedzieć co chce monitorować, jak powinien wyglądać proces wdrożeniowy, pilnuje żeby zadania dobrze były opisane itp.) bo jest odpowiedzialny za cały proces powstawania i utrzymywania oprogramowania.
Czasami TL to taka osoba, która oprócz pilnowania procesu wytwarzania i utrzymywania oprogramowania musi się orientować w całej architekturze wokół swojego kawałka. Wtedy taki TL musi mieć jeszcze wiedzę o architekturze systemów.

Pytanie - o którym tutaj mówimy?

wartek01 napisał(a):

Powiedzmy tutaj jedno: Team Leader to bardzo szerokie pojęcie.
Czasami TL to taka osoba, która oprócz kodowania pilnuje jeszcze, żeby ludzie składali timesheety na czas. Wtedy jakichś większych umiejętności nie trzeba.

To moim zdaniem nie zasługuje na etykietkę "team lead". Co ten "Lead" w "Team lead" niby znaczy?

Czasami TL to taka osoba, która oprócz pilnowania zespołu jest odpowiedzialna za cały proces zespołu. Wtedy TL musi mieć wiedzę z zakresu procesów powstawania oprogramowania (tj. musi wiedzieć co chce monitorować, jak powinien wyglądać proces wdrożeniowy, pilnuje żeby zadania dobrze były opisane itp.) bo jest odpowiedzialny za cały proces powstawania i utrzymywania oprogramowania.

Wierd. Moim zdaniem cały zespół powinien się składać z takich ludzi.

Czasami TL to taka osoba, która oprócz ganiania ludzi za timesheetami jest jeszcze odpowiedzialna za cały zespół - czyli jeśli któryś z programistów zawalił, to TL musi być i łagodzić sytuację. Wtedy TL jednocześnie musi pilnować zespołu i w miarę możliwości być osobą techniczną.
Czasami TL to taka osoba, która oprócz pilnowania procesu wytwarzania i utrzymywania oprogramowania musi się orientować w całej architekturze wokół swojego kawałka. Wtedy taki TL musi mieć jeszcze wiedzę o architekturze systemów.

No ja miałem na myśli jego z tych dwóch

TomRiddle napisał(a):

To moim zdaniem nie zasługuje na etykietkę "team lead". Co ten "Lead" w "Team lead" niby znaczy?

No to, czy zasługuje to na etykietkę "team lead" to inna kwestia. Wiem tylko tyle, że takie byty się zdarzają.

Wierd. Moim zdaniem cały zespół powinien się składać z takich ludzi.

Nie rozumiem czemu. Masz np. juniora, dwóch midów, seniora i TLa na jakimś projekcie od zera. Wtedy to TL (być może w porozumieniu z seniorem - ale to TL właśnie ma głos rozstrzygający) wyznacza kierunek jak powinien wyglądać cały proces.

No ja miałem na myśli jego z tych dwóch

Tak jak napisałem - wariancja jest spora. Podobne różnice możesz znaleźć w innych rolach. Np. Project Manager - czasem to taka sekretarka co biega z fakturami, czasem to człowiek, który bierze na siebie cały kontakt z klientem, czasem to taki product owner, analityk i architekt w jednym. Senior - czasem to taki typ, co klepie kod dłużej niż inni, a czasem to taki tech lead w zespole.

Jeszcze lepiej jest z stanowiskami w różnych firmach. Np. VP (VicePresident) - są firmy, gdzie osób na takim stanowisku jest bardzo niewiele i są one odpowiedzialne za całe działy. Są firmy, gdzie VP oznacza, że masz pod sobą jakiś zespół. I są wreszcie firmy, gdzie nawet Senior Dev może coś takiego dostać.

wartek01 napisał(a):

TomRiddle napisał(a):

To moim zdaniem nie zasługuje na etykietkę "team lead". Co ten "Lead" w "Team lead" niby znaczy?

No to, czy zasługuje to na etykietkę "team lead" to inna kwestia. Wiem tylko tyle, że takie byty się zdarzają.

Wierd. Moim zdaniem cały zespół powinien się składać z takich ludzi.

Nie rozumiem czemu. Masz np. juniora, dwóch midów, seniora i TLa na jakimś projekcie od zera. Wtedy to TL (być może w porozumieniu z seniorem - ale to TL właśnie ma głos rozstrzygający) wyznacza kierunek jak powinien wyglądać cały proces.

I don't think so. Tzn mogłoby tak być, ale to nie byłoby tak super jak team-samoorganizujący się; zakładając oczywiście ze jest zdolny do tego - nie każdy zespół jest.

W ogóle to warto by zacząć od rozróżnienia ról, które niektórzy prawdopodobnie mylą.

z tego co było mówione na pierwszych rozmowach team leaderowania było by jakieś 30% czasu reszta kodowanie

Wspomnianym TL'em - rozwijając tytułowym Team Leadem może być nawet junior albo tester, który ma doświadczenie w ... zarządzaniu zasobami/projektem i najlepiej wdrożonym wystarczająco w projekt/firmę.

Obowiązki jak wiadomo, może to być przeplatanka scrum mastera z menadżerem i trochę komunikacji z PO (+każde inne porypane company native procesy).

Drugą osobą często pod skrótem TL jest Tech Lead i tutaj ta osoba prawdopodobnie dobrze by było, aby w poziomie umiejętności technicznych była co najmniej dobra.

Jeśli mowa o pierwszej osobie, to w zasadzie ciężko powiedzieć czy powinieneś cokolwiek dostać, bo takie osoby są w zależności od firmy albo dużo pod devami, albo w tych samych widełkach, albo dużo nad developerami (mowa o ludziach full time team lead).

serek napisał(a):

TomRiddle napisał(a):

To po co taki team lead w ogóle?

No ale od kiedy jest powiedziane, że TL musi być jakimś wymiataczem? Może akurat to będzie TL z takimi umiejętnościami, które umieszczą go gdzieś pod koniec widełek mida, a umie jeszcze za mało, żeby więcej zarabiać. Zresztą TL nie musi być wcale programistą. Zależnie od projektu nie musi mieć wcale skili technicznych.

Nie każdy projekt będzie wymagał jakieś wymiatacza w roli TLa. Może średnie umiejętności wystarczą. U mnie w firmie TL zarabiają mniej więcej od górnych widełek mida, a maks zarabiają nie wiele więcej niż senior-programista.

Znam TLa po AWFie i jakoś nikomu to nie przeszkadza^^

No jeśli zawodowo robi się pompki, to pewnie nie jest to problem. Ale generalnie team leader to jest osoba, która poza siedzeniem na spotkaniach z biznesem i innymi team leaderami, powinna też być w stanie pomagać zespołowi w kwestiach technicznych. Nietechniczny team leader będzie miał z tym problemy.

Nie wiem skąd przekonanie, że "Team Leader" to nie musi być ogarnięty programista. Twierdzenie inaczej, to tak jak gdyby mówić, że majster na budowie, może mieć mniejsze umiejętności niż gość od podawania cegieł. Wyjątkiem są osoby ogarnięte technicznie, ale z softskillami na poziomie linkera w C++.
Jeśli ma być "liderem", to musi mieć autorytet. Jak go zdobędzie w grupie technicznych gości, nie mając technicznej wiedzy i nie będąc w stanie wnieść przyzwoitego wkładu w to co zespół dostarcza? Przecież w tydzień skończy chlipiąc w kącie jak jakiś junior scrum master.

Disclaimer, nie czytałem całego wątku.

z tego co było mówione na pierwszych rozmowach team leaderowania było by jakieś 30% czasu reszta kodowanie

Okłamali Cię. Team leaderem byłem krótko i udało mi się te 30% osiągnąć, tym nie mniej pozostali team leaderzy w dziale mieli czas na kodowanie jeden, może dwa dni w tygodniu, dlatego wiem, by osiągnąć te 30% potrzeba bardzo specyficznych warunków, które akurat miałem szczęście zastać.

1. Masz dojrzałe automaty do synchronizacji ogólnego postępu z przełożonymi, dzięki temu masz mało spotkań i maili.
2. Jesteś dotarty z resztą programistów, wiesz czego możesz się po nich spodziewać przez co rozdzielanie i planowanie zadań przychodzi gładko a pull requesty to głównie próby wyłapania drobnych bugów/przeoczeń, ale formalność z perspektywy architektonicznej.

Także jak widzisz, masz niewielkie szanse by te 30% osiągnąć, więc pozostaje pytanie, czy zatrudniające osoby mają tego świadomość i po prostu podali takie proporcje, żeby Cię zwabić, czy faktycznie będą Cię z tego rozliczać? Bo jeśli to drugie to od razu negocjuj stawkę za nadgodziny.