Pierwszy raz jako Lead

W najbliższym czasie dostanę niewielki zespół (na 2-3 dev) do poprowadzenia - technologiczną część ogarniam, ale zastanawiam się nad częścią zarządczą mojej roli. Będziemy pracować nad własnym produktem, architektura i wymagania już są przynajmniej częściowo wyklarowane - projekt to taki późny greenfield.
Moje założenie jest takie, że przede wszystkim mam umożliwić zespołowi pracę, dbać o jakość tego co wytwarza, oraz w miarę możliwości chronić przed wścibskimi oczkami i rączkami managerów w organizacji.

Czy moja wizja roli ma sens, czy może oczekujecie od swoich leadów czegoś zupełnie innego?
Jakich błędów przede wszystkim powinienem się wystrzegać?

Uwagi, pomysły osób technicznych, które zarządzają innymi - szczególnie mile widziane :-)

Jako lead musisz odpowiednio wcześnie widzieć że dzieje się źle i reagować. do tego musisz być osoba decyzyjną, jeśli zespół nie potrafi podjąć decyzji w rozsądnym czasie to ty musisz ją podjąć i uciąć temat by nie przepalać dalej czasu. Do tego to ty musisz pilnować by z kodu nie zrobiło się spadżetti, były testy i tak dalej (nie, nie musisz robić cr osobiście ale jeśli osoby które do tego wyznaczysz zawiodą to wina spada na ciebie). I najważniejsze, jeśli w zespole jest chaos to nie wina innych tylko ciebie, nie raz przejmowałem zespół gdzie był totalny rozpierdziel i chaos, po tygodniu było wszystko opanowane, ale to kwestia twoja czy to potrafisz, mi to przychodzi naturalnie.

Jaka sam nazwa wskazuje masz być liderem. Rozwiązywać konflikty wewnątrz zespołu i między zespołem a innymi zespołami/prawnikami, monitorować co i jak się dzieje. Czy ktoś w czymś nie utknął. Oganiać czy ludzie mają co robić, wiedzą co mają robić. Komunikować decyzje przełozonych - np zwalniać ludzi.

Bierzesz na siebie odpowiedzialność, więc nie krępuj się narzucać swoje decyzje bo to twoja praca. Nie trzeba być do tego chamem. Można być jednocześnie stanowczym i kulturalnym. Tłumacz jednak możliwie dokładnie swoje decyzje, przede wszystkim jeżeli masz doczynienia z juniorem. Nawet jeżeli ta decyzja wynika wyłącznie z twojego widzimisie, to dev powinien o tym wiedzieć.

Nie rób mobbingu/micromanagementu i będzie git, pisze to ponieważ miałem liderów którzy to robili i mimo że było to dawno temu to pamietam to do tej pory oraz żywię uraz taki że nie wiem czy podałbym im rękę jak bym się z nimi spotkał na konferencji IT czy gdziekolwiek.

Tldr
zachowuj się jak człowiek i dbaj o swoich ludzi, komunikuj problemy i zachowuj się profesjonalnie

Zapytaj się managera, jakie są wobec Ciebie oczekiwania i za co będziesz rozliczany. W każdej firmie obowiązki TL-a są trochę inne. Warto na pewno ustalić, kto odpowiada za rozwój i oceny ludzi (tzw. people management).

Zastanawiam się co tu mądrego napisać w jednym zdaniu. Na pewno przygotuj się na to, że za porażki odpowiadasz Ty, a za sukces cały zespół :) Sukces w tej roli to na pewno dowożenie i pozytywny feedback od zespołu - trzeba umieć zbalansować jedno z drugim.

Przygotuj sobie bota na Teamsach / Slacku żeby co 2h pingował podwładnych o status.

Musisz mocno podszkolić umiejętności miękkie, przede wszystkim pamiętaj że gracie zespołowo i jeśli jedna osoba zaczyna lekko kuleć nie oznacza to że musicie ją hejtować, nadal gracie do jednej bramki - mamy wielu programistów którzy są świetni jako one man army, a gdy dochodzi do pracy w zespole powoduje to problemy. Motywuj, dziel się odpowiedzialnością (o tym zaraz). Musisz być decyzyjny, nikt inny nie podejmie decyzji za Ciebie.

Rzecz absolutnie istotna - dziel się powolnie odpowiedzialnością w pewnym stopniu. O czym mówię?

Jeśli zaczniesz jako jedyny za dużo wiedzieć o założeniach projektu - tworzy się problem. Zwalasz sobie na głowę wszystkich którzy mają braki i tracisz możliwość spokojniej pracy. Co jeszcze? Odbiera ci to spokój, bo jeśli pójdziesz na urlop zaczyna się stop developmentu. Robisz code-review i zatwiedzasz je jako jedyny? Oddeleguj z czasem to zadanie 50/50 - nadal sprawdzaj wszystko, ale z ograniczonym zaufaniem puszczaj mniejsze taski tylko po twoim lekkim rzucie okiem gdy ktoś inny już to sprawdził. Dziel się wiedzą o której zespół nie jest wstanie wiedzieć - przegadałeś coś z biznesem na callu? - Podziel się, zapamiętają to też oni, będą mieć z tyłu głowy.

Rozpisujecie sami taski, rozwiązania? Must have - planingi techniczne między wami w których możecie omówić rozwiązanie. Deleguj po czasie rozpisywanie tasków skoro je ogadaliście, nie ma sensu żebyś marnował na to czas bo po ogadaniu i tak wychodza często rzeczy do sprawdzenia, jeśli będziesz robić to tylko ty - stworzysz bloker i będzie problem.

Cały sęk w byli dobrym team leadem aby nie stać się zbyt ważnym. Zespół z którym dzielisz się również swoimi zadaniami pozwala pracować i tobie i im znacznie pewniej.

Jak dbać czasem o motywacje? - Widzisz że ktoś ma problem z zadaniem, nie tyle z rozwiązaniem co motywacją do tej działki? - Przejmij to i dokończ, koniec końców to oni będą więcej kodować więc jak będą zdemotywowani czymś czego do końca nie chcą robić w danym momencie niepotrzebnie spowolni to pracę. Featury zawsze w założeniu dzielcie na więcej niż jedną osobe, nie musi to być pair programming, wystarczy że ktoś zrobi 15-25% jakieś featura, a ktoś reszte - ograniczyć braki wiedzy o systemie, dodasz dodatkową osobę do zadania za które bierzesz odpowiedzialność która może złapać braki/błędy tej drugiej zanim stracicie dużo czasu przez code review.

@anonimekpan: no jak się dałeś wrobić w 1,5 etatu to twoja wina. Normlanie tl koduje 30-50% czas max i zarządzanie jest ponad kodowaniem, więc są dni że nic nie koduje i jest to normalne.