Dzień z życia Tech Leada

Spotkałeś kiedyś na swojej drodze prawdziwego lidera? Co odróżniało go od innych? Co sprawiało, że chciałeś za nim podążać? A może zawsze brakowało Ci wskazanego kierunku? Czy w świecie technicznym również potrzebujemy liderów?

Po co nam lider? Przecież wiemy lepiej!

W każdym zespole, prędzej czy później, albo powstanie pewna ustalona hierarchia (np. starzy vs młodzi), albo specjalizacje w wybranych obszarach. Tak długo, jak zespół jest zgrany, ma stały skład, panuje zgodność we wszystkich aspektach i wyborach technologicznych, developerzy są zawsze dostępni, pomysły i priorytety biznesowe nie są zmieniane, a projekty realizowane są zgodnie z planem, ba nawet z zapasem - wtedy lider nie jest nam potrzebny. Wszyscy jednak wiemy, że to utopia i prędzej czy później potkniemy się o najmniejszy kamyk.

Naprawdę niewiele potrzeba, spójrzmy tylko - na rynku pojawia się nowy framework i w zespole zacznie się dyskusja nad wyborem (patrz: święta wojna Symfony vs Laravel), żona Adama kupi miesięczną wycieczkę last minute z okazji ich 10-tej rocznicy ślubu, Piotrek złamał rękę podczas wczorajszej gry w tenisa a Product Owner oznajmia, że w trybie pilnym musimy dorobić jeszcze jeden feature. W efekcie zaczynamy się zakrzykiwać, pojawiają się pierwsze nerwowe ruchy, pierwotne ustalenia stają się nieważne, tam gdzie był ład i porządek wkrada się chaos.

Kto nad tym wszystkim zapanuje? Czy zostawiamy to w duchu Agile samo-organizującym się zespołom? Czy Product Owner będzie w stanie rozstrzygnąć spór w zakresie wybrania technologii? Kto przejmie zadania od Adama i Piotrka? Czy nasz kod jest gotowy do dodania tam funkcjonalności zgłoszonej przez PO?

Mówimy oczywiście o dość abstrakcyjnej sytuacji, gdzie pali się wszędzie - nie zawsze jednak jest aż tak źle - zatem po co nam lider? Czym on się zajmuje day-by-day?

W skrócie, rolą Tech Leada w zespole jest:

bliska współpraca z Product Ownerem lub Project Managerem
rozkładanie projektów na składowe i definiowanie mniejszych kroków w szczegółach, od strony technicznej
przygotowywanie wizji technicznej
odpowiedzialność za decyzje techniczne
przeprowadzanie analiz wykonalności technicznej, identyfikowanie ryzyk czy blokerów, oraz zależności
pomoc w usuwaniu blokerów, eliminacji ryzyk
dbanie o nieustanny rozwój techniczny zespołu, jak również przygotowywanych rozwiązań
dbanie o jakość, w tym również bezpieczeństwo czy performance
dbanie o usuwanie długu technologicznego
definiowanie standardów kodowania oraz procesów związanych z cyklem wytwarzania oprogramowania
pomoc w organizacji pracy zespołu
wprowadzanie nowych osób do zespołu
wspomaganie w rozwoju poszczególnych developerów i osiąganiu przez nich założonych celów
prowadzenie i organizacja spotkań technicznych zespołu

Naturalny czy wybrany?

Czy możemy komuś nakazać, że od jutra będzie “rządził”? Oczywiście, że tak. Czy możemy go do tego przygotować, nauczyć? W pewnym sensie tak, wskazując na konkretne obszary i wyznaczając cele. Czy to zadziała? Jest taka szansa, ale wymagane jest umocowanie i wskazanie kto za co jest odpowiedzialny oraz bliska współpraca z takim liderem. Czy możemy zostawić takiego mianowanego lidera samego sobie? W mojej ocenie już niekoniecznie.

Z drugiej strony mamy osobę, która sama w sobie ma tyle zaparcia oraz odpowiednie (przywódcze) cechy charakteru, które niejako naturalnie predysponują ją do bycia liderem. Taka osoba sama dostrzega, gdzie są największe potrzeby działania, sama definiuje kierunki rozwoju, sama wskazuje co można zmienić. Do tego nie czeka na pozwolenie - działa proaktywnie, bierze odpowiedzialność. Czy musimy ją zachęcać do takich działań? Nie. Czy potrzebne jest autorytarne wskazanie, że “rządzi”? Nie. Czy potrzebny jest tytuł? Również nie. Czy potrzebujemy taką osobę kontrolować? Co najwyżej w minimalnym zakresie. Zatem mamy układ idealny? Niemalże - mówimy tutaj o dużej samodzielności, ale przede wszystkim taka osoba musi być obdarzona bardzo dużym zaufaniem i swobodą w działaniu (nawet jeśli ma popełnić kosztowny błąd), ze wspólnym ustaleniem kierunku działania - pomoc poprzez wspólne ustalanie celów, kierunków, przestrzeń i czas na działanie.

Leadership
(źródło: memegenerator.net)

Moje osobiste doświadczenia wskazują na drugi wariant - sam wielokrotnie działałem w takim modelu, pełniłem taką rolę i to się po prostu sprawdzało. Co w sytuacji, gdy nie mamy takiego naturalnego lidera? Możemy mianować autorytarnie jednego lidera, możemy przeprowadzić głosowanie, możemy spróbować z różnymi osobami, przy różnych projektach, technologiach czy obszarach (tzw. feature lead odpowiedzialny za design całego feature) i na tej podstawie się wyłoni lub będą liderzy per case - na pewno takiemu liderowi musimy zapewnić dużo więcej wsparcia niż w przypadku tego, który naturalnie się wykreuje.

Tech Lead jako developer

Lider liderem, ale mówimy tutaj przede wszystkim o osobie technicznej. Tym co nas napędza i stanowi paliwo dla naszych działań jest technologia, a konkretnie rzecz biorą kodowanie. Czy pełniąc rolę lidera technicznego jest przestrzeń na takie działania? Czy od tech leada wymagamy, aby programował? Na oba postawione tutaj pytania odpowiedź brzmi: TAK, zdecydowanie tak!

Zależy nam przede wszystkim na tym, aby taki lider miał cały czas kontakt z technologią, z rozwiązaniami przygotowywanymi w zespole, samemu doświadczał problemów związanych z wdrażaniem kodu na produkcję i jeszcze lepiej dobierał rozwiązania czy podejmował techniczne decyzje.

Zatem, jak jednocześnie pełniąc obowiązki lidera być aktywnie działającym developerem w zespole?

uczestnictwo w Code Review, z zastrzeżeniem że nie możesz być tym od którego będzie ostatecznie zależało czy dane CR pójdzie dalej
wspólne programowanie w zespole - pair oraz mob programming, dla wybranych komponentów
przygotowywanie prototypów, walking skeletonów
development mało istotnych oraz czasochłonnych zadań w projekcie
naprawianie mało skomplikowanych, krytycznych błędów

Zalecane są tutaj proporcje w postaci zaledwie 30% czasu przeznaczonego na prace developerskie, pozostałe 70% na spotkania, analizy i inne działania. Warto również zaznaczyć, tak jak zostało wskazane przy bulletach, że na Tech Leadzie nie może spoczywać ciężar developmentu, nie może od jego dostępności zależeć czy wydamy daną funkcjonalność, czy dany fragment kodu trafi na produkcję. Oczywiście, ważne jest aby był uwzględniany podczas dyskusji jak dane rozwiązanie zaprojektować czy na jakie elementy zwrócić uwagę.

Kolejny wniosek, który można z tego obrazu wyciągnąć jest taki, że rola lidera technicznego nie polega na byciu najlepszym programistą w zespole, ale upewnianie się, że inni maja przestrzeń i robią to, co potrafią najlepiej i mogą się na tym polu rozwijać.

Nie bądź zachłanny - podziel się tortem z innymi

Jeżeli mamy tylko 30% czasu na programowanie, do tego całkiem sporo spotkań, analiz i zaglądania to tu, to tam - sami nie jesteśmy w stanie wszystkiego ogarnąć. Warto podzielić się tym tortem! Delegujmy prace do innych, przede wszystkim te wymagające dużego zaangażowania czasowego. Jednocześnie jako lider techniczny nie podejmuj samemu wszystkich decyzji technicznych - zostaw przestrzeń na to dla innych, ustal reguły w których momentach Twoje zdanie będzie kluczowe, a gdzie zostawiasz wolną rękę. Czasem wystarczy tylko wskazać kierunek, pewien wzorzec postępowania czy ustalić wspólnie standard.

Przykładowym podejściem jakie można przyjąć podczas decydowania co oddajemy innym jest tzw. Eisenhower Matrix

Eisenhower Matrix
(źródło: slab.com)

Czas opuścić strefę komfortu

W tak dynamicznie zmieniającym się środowisku każdy potrzebuje się rozwijać, a do tego chcemy sprawnie podejmować decyzje. Dlatego też wymagane jest zbieranie różnych doświadczeń, spoglądanie szerzej, odkrywanie nieznanego - krótko mówiąc wykraczanie poza swoją strefę komfortu.

W przypadku Tech Leada, może to być inna technologia, niż ta którą zna najlepiej czy inny obszar biznesowy. Z jednej strony warto jako backend developer, od czasu do czasu spróbować swoich sił na froncie, z drugiej natomiast coraz szerzej promowana jest idea T-shaped developer’a. Jeśli zaś chodzi o wymiar biznesowy, wiedza jak działa funkcjonalność wytwarzana przez inny zespół może być pomocna podczas definiowania zależności między komponentami, lepszego planowania z uwagi na czekanie aż dostarczone zostaną efekty pracy z innego obszaru czy po prostu może to być inspiracja, aby w którym z przypadków zastosować inne podejście, skorzystać z wiedzy i doświadczeń innych (ang. Don’t reinvent the wheel). Tą skarbnicą wiedzy dla lidera może być przykładowo uczestnictwo w review/demo organizowanym przez inny zespół.

Jeszcze innym wymiarem może być zbieranie nauki, tam gdzie z pozoru tego zupełnie się nie spodziewamy - na polu miękkich umiejętności. Od czasu do czasu poprowadź retro zespołowe czy daily, wystąp z prezentacją, złap się na kawę z developerem lub porozmawiaj o feedbacku z działu wsparcia klienta.

Najważniejszy jest zespół

Aby lider mógł dobrze pełnić swoją rolę, musi być częścią zespołu - razem odnosicie sukces, razem przeżywacie gorycz porażki, wspólnie wyciągacie wnioski.

“It’s fine to celebrate success but it is more important to heed the lessons of failure”- Bill Gates

Z drugiej strony sukces zespołu to Twój sukces, i tak jak zespół dba o Ciebie, tak Ty musisz zadbać o niego. Jako osobie o szerszej perspektywie, często bogatym doświadczeniu, liderowi powinno zależeć na samodzielności i niezależności zespołu. Do lidera w pierwszej kolejności zgłaszają się inni z problemami, to na lidera patrzą inni w zespole, gdy idzie nie tak jak się spodziewaliśmy. We wspólnym interesie, zespołu oraz lidera, jest doprowadzenie do takiego miejsca, gdzie w wielu przypadkach obecność lidera nie będzie potrzebna. Dlatego często liderzy angażowani są w coaching, mentoring czy tutoring innych osób w zespole. To lider techniczny organizuje pracę zespołu wokół zagadnień technicznych, planuje usprawnienia techniczne i dba o dług technologiczny, wymianę wiedzy poprzez

stawianie celów technicznych dla zespołu
przygotowywanie prototypów rozwiązań
organizowanie dedykowanych refinementów technicznych
wspólne sesje kodowania
organizację wewnętrznych szkoleń, sesji Event Stormingu czy spotkań typu Brown Bag (aka Lunch & Learn) lub Lightning Talks

Do tego dochodzi jeszcze wymiar rozkładania parasola ochronnego przed nadmiarem spotkań technicznych czy dotyczących architektury - Tech Lead powinien przygotowywać koncepcje rozwiązań i przedstawiać je zespołowi zamiast angażować go w całości, na każdym kroku. Z drugiej strony mamy jeszcze trzymanie zespołu z daleka od “polityki” wewnątrzfirmowej i zapewnienie spokoju w zespole.

W dużym skrócie, drogi liderze - zadbaj o swój zespół, stwórz dla nich przestrzeń do rozwoju i spokojnej pracy - to zespół zadba również o Ciebie!

Nie po to studiowałem informatykę, żeby…

To zdanie zapewne jako osoby pracujące w tej branży słyszycie dość często, i to w różnych okolicznościach. Często wynika to z introwertycznej natury wielu osób, ale również z tego, że developerzy po prostu chcą skupić się na tym co lubią i potrafią najlepiej czyli programowaniu. W przypadku lidera sytuacja wygląda inaczej - od niego oczekujemy, że będzie osobą o dużych umiejętnościach interpersonalnych, będzie w stanie sprawnie się komunikować. Dlatego też, taka osoba dużo czasu spędza na spotkaniach, jest pewnego rodzaju rzecznikiem prasowym zespołu, do zespołu wraca z ustaleniami, to do tej osoby inni przychodzą po feedback na temat developerów z zespołu. Jako developer nie zawsze musiałeś mieć zdanie i mogłeś siedzieć cicho, jako lead wszyscy oczekują od Ciebie, że wypowiesz się w każdym temacie.

Aby móc dawać wartościowy feedback na temat pracy zespołu, a w szczególności poszczególnych osób tam pracujących, warto zainwestować, jako lider techniczny, w czas na regularne rozmowy 1-on-1 z tymi osobami, jak również Product Ownerem, Project Managerem czy Engineering Managerem - w zależności od organizacji pracy w zespole.

Nie ulega wątpliwości, że tech lead będzie dużo rozmawiał, konsultował, i spędzał czas na spotkaniach - powinien być gotowy na to podejmując się tej roli oraz zadbać o rozwój swoich umiejętności na tym polu.

Życie to sztuka wyboru

Jednym z kluczowych zadań lidera technicznego jest odpowiedzialność za decyzje techniczne. Często wymaga to przygotowania, zagłębienia się i wybadania tematu, a nierzadko po prostu zaplanowania pewnych działań. To od tech leada będziemy wymagać przygotowania planu rozwoju technicznego zespołu (ang. technical development plan) - czy to w postaci wyznaczonych celów, często nawet rozpisanych zadań na bazie przeprowadzonych analiz SWOT, zebranego feedbacku od użytkowników czy wiedzy, która płynie z powtarzających się błędów w logach czy systemach typu Sentry.

Z drugiej strony, aby dokonywać trafnych wyborów, lider techniczny, zreszta jak każda osoba w branży IT, musi dążyć do ciągłego doskonalenia się - po prostu nieustannie rozwijać się. W przypadku lidera technicznego wyzwanie jest tym większe, że trzeba spoglądać na technologie naprawdę szeroko, bardzo często wychodzić poza swoją specjalizację, o czym pisałem kilka akapitów wyżej.

Nieodzownym elementem podejmowanych decyzji technicznych jest także ustalanie priorytetów - to lider, razem z zespołem, będzie stawał przed wyborem które rozwiązanie wybrać, czy skupić się na dostarczeniu szybko wartości użytkownikom czy zadbać w pierwszej kolejności o dług technologiczny - to ciągła walka, wyprzedzanie ruchu przeciwnika, mitygacja ryzyka zanim wystąpi. Życie Tech Leada to sztuka wyboru.

Znajdź swój rytm dnia

Dzisiaj, gdy zdecydowana większość osób z branży IT pracuje zdalnie, na wszystko potrzebujemy zestawić spotkanie. Daily - spotkanie, planowanie - kolejne spotkanie, konsultacja architektoniczna - jeszcze inne spotkanie, rozmowa o uwagach dot. kodu z Code Review - również się zdzwaniamy itd. itd. Ciężko w tym biegu znaleźć przestrzeń, aby… popracować. Dochodzi do tego jeszcze ciągłe przełączanie kontekstu, jak również wszechobecne rozpraszacze w postaci wyskakujących powiadomień, wiadomości na komunikatorach, przychodzące maile, SMSy, … Naprawdę ciężko się skupić na wykonaniu powierzonego nam zadania.

Jak sobie z tym wszystkim radzić w roli lidera technicznego, od którego przecież tak wiele oczekujemy?

Moja recepta na sukces:

wyłącz, lub maksymalnie ogranicz przychodzące powiadomienia np. zamiast chmurki z treścią wiadomości - wystarczy nadawca i “licznik bólu” czyli ile wiadomości czeka na odpowiedź
pocztę sprawdzaj 2-3 razy dziennie, raz na początku dnia, raz w ciągu i raz na koniec oraz uświadamiaj innych, że poczta czy komunikatory są z natury asynchroniczne
zadbaj o regularność, cykl dnia, powtarzalne rutyny np. zaczynaj dzień od poczty, wiadomości na komunikatorze, przegląd błędów (logi, systemy raportujące), Code Review a dopiero później właściwe zadania
codzienna lektura techniczna tzw prasówka do kawy - wystarczy 30 min dziennie
zaczynaj pracę przed spotkaniami w zespole - warto być przynajmniej godzinę przed daily, aby ogarnąć najpilniejsze tematy i przygotować się do spotkań
organizacja kalendarza w taki sposób, aby spotkania były skupione w blokach
podział czasu na bloki: czytanie wiadomości (mail, komunikator), spotkania, wspomaganie zespołu/developerów, programowanie
rezerwuj czas w kalendarzu na programowanie (np. codziennie 8-10 rano) oraz spotkania techniczne z zespołem (np. piątkowe weekly o 12)
naucz się odmawiać udziału we wszystkich spotkaniach
poznaj swój zespół - wiedza kto kiedy najlepiej pracuje pomoże w organizacji spotkań
higiena pustej skrzynki mailowej
wypróbuj Pomodoro
na koniec dnia przygotuj listę TODO najpilniejszych tematów na kolejny dzień

Rola lidera technicznego jest niezwykle wymagająca, ale także dająca sporo satysfakcji - szczególnie, gdy widzisz jak to zespół odniósł sukces dzięki Twojemu wsparciu.

“Management is doing things right; leadership is doing the right things” — Peter F. Drucker

Do tego jest to mieszanka elementów bardzo technicznych, jak również tych miękkich. Na koniec kilka rad dla obecnych i przyszłych Tech Leadów

naucz się delegować
znajdź czas na programowanie
rozmawiaj, współpracuj z biznesem
bądź częścią zespołu
nie podejmuj wszystkich decyzji samodzielnie
nie mów innym jak mają robić - wskaż drogę, pozwól popełnić błąd
naucz się mówić NIE

Niech przyświeca Wam maksyma autora książki In Search of Excellence

“Under promise and over deliver” — Tom Peters

Powodzenia!

Przydatne linki:

tagi: tech lead , technical leadership , leadership , software architect , agile , Peter F. Drucker , Tom Peters , Patrick Kua