Po kilku latach programowania i rozwijania projektów Magento, czułem, że znam tą platformę na wylot. Mogłem rozwiązać każde zadanie, pisałem kod, pomagałem innym. Jak każdy programista, który się rozwija dostałem wtedy propozycję objęcia funkcji tech leadera. Oczywiście się na to zgodziłem i przez kolejnych kilka lat próbowałem się odnaleźć w nowej roli. Wyszło na to, że się nie odnalazłem i zawróciłem do roli programisty. Po drodze przeżyłem dużo wzlotów i upadków łącznie z wypaleniem zawodowym. Było to trudne, ale było warto. Czytaj dalej aby dowiedzieć się dlaczego.
Pod koniec 2021 roku pracowałem dla Gorilla Group jako indywidualny kontrybutor. Miałem tam też możliwość kontrybucji do PWA Studio - headless frontendu do Magento.
Byłem zafascynowany tym projektem i jego stackiem technologicznym. Szczególnie jarałem się wtedy Reactem i wiązałem przyszłość z tą technologią.
Ku mojemu zdziwieniu dostalem propopzycję pracy od firmy, która rozwijała konkurencyjny do PWA Studio projekt - Vue Storefront. Jak nazwa wskazuje, framework użyty w tamtym projekcie to był Vue.
W dodatku chcieli abym został tech leader i prowadził zespół. Mówiąc wprost - zostałem tech liderem, bez doświadczenia w kierowaniu projektem i bez doświadczenia w Vue JS. Co mogło pójść nie tak?
Strefa komfortu jest dla słabeuszy
Nie jeden kołcz Ci to powie - trzeba wychodzić ze strefy komfortu! Ile można siedzieć i pykać zadania, poprawiać bugi i narzekać na scrum?
W naszej pracy programistów dominuje kultura oparta na precyzji i kontroli nad kodem. Właśnie dlatego transformacja z programisty do lidera jest taka trudna. Wymaga połączenia głębokiego zrozumienia architektury systemów z umiejętnościami miękkimi, takimi jak zarządzanie konfliktami czy budowanie i prezentowanie wizji technologicznej.
Transformacja jest trudna. Unikanie transformacji może objawiać się:
- przywiązaniem do dobrze znanych technologii i frameworków
- unikaniem odpowiedzialności za decyzje architektoniczne
- preferowaniem pracy samemu zamiast z zespołem/innymi programistami
Dla mnie najtrudniejsze w transformacji i w wyjściu z tej strefy komfortu było to, że musiałem porzucić swój dobrze znany warsztat i narzędzia i zacząć robić coś zupełnie innego. Zamiast robić sam to prezentować jak coś ma być zrobione innym i stworzyć środowisko pracy, które pomoże realizować to czego potrzebujemy.
Przecież nie będę słaby, wyjdę z tej strefy
Czas na zmianę. Jednego dnia byłem programistą, zajmującym się głównie kodowaniem i technicznymi implementacjami. Następnego, byłem odpowiedzialny za prowadzenie zespołu pracującego nad dużym projektem integracyjnym - takim o wysokiej widoczności i jeszcze wyższych stawkach.
Na początku czułem się, jakbym nosił nieswoje buty. Mój kalendarz, wcześniej wypełniony blokami czasu skupionym na kodowaniu, nagle stał się labiryntem spotkań. Zamiast bezpośredniego rozwiązywania problemów technicznych, byłem teraz odpowiedzialny za prowadzenie innych do znajdowania rozwiązań. Umiejętności, które uczyniły mnie skutecznym programistą - głębokie skupienie, techniczny perfekcjonizm, niezależna praca - nie wystarczały już. W rzeczywistości czasami wręcz mi przeszkadzały.
Prawdziwe wyzwanie nie było techniczne - było nim wszystko inne. Jak zrównoważyć kodowanie i zarządzanie? Kiedy wkroczyć z pomocą, a kiedy się wycofać, aby zespół mógł się rozwijać? Jak poradzić sobie, gdy twój najlepszy programista decyduje się odejść z zespołu? To nie były problemy, które można było rozwiązać kilkoma liniami kodu czy sprytną decyzją architektoniczną.
Pułapka pozornego sukcesu
Moja kariera tech leada rozwijała się jak Man City pod wodzą Pepa Guardioli- szybko i imponująco z zewnątrz, ale wewnątrz coś iskrzyło. Pomimo zewnętrznego sukcesu, czułem się coraz bardziej przytłoczony. Ciągłe przełączanie kontekstu między kodowaniem a zarządzaniem, ciężar odpowiedzialności zarówno za decyzje techniczne, jak i bezpieczeństwo zespołu, oraz niekończący się strumień spotkań zbierały swoje żniwo.
Punkt przełomowy nastąpił, gdy zdałem sobie sprawę, że zacząłem bać się widoku swojego komputera. Ta sama praca, która kiedyś dodawała mi energii, teraz pozostawiała mnie wyczerpanym i odłączonym. Spędzałem w pracy więcej godzin niż kiedykolwiek, a jednak czułem się mniej produktywny. Na spotkaniach przyłapywałem się na kiwaniu głową, podczas gdy mój umysł wędrował gdzie indziej. W domu nie mogłem przestać myśleć o pracy, a w pracy nie mogłem skupić się na zadaniach.
Co gorsze, była to izolacja. Jako tech lead znajdujesz się w unikalnej pozycji - nie jesteś już tak naprawdę programistą, ale nie jesteś też tradycyjnym menedżerem. Do kogo się zwrócić, gdy to od ciebie oczekuje się wszystkich odpowiedzi?
Nowy początek: znalezienie własnej ścieżki
Przełom rozpoczął się od prostego przyznania - potrzebowałem pomocy. Po miesiącach próbowania bycia perfekcyjnym liderem technicznym, który może zrobić wszystko, w końcu otworzyłem się przed moim przełożonym w sprawie moich trudności. Ta rozmowa, choć trudna, była pierwszym krokiem ku pozytywnej zmianie.
Zdałem sobie sprawę, że bycie świetnym tech leadem nie polega na przepracowywaniu większej liczby godzin czy znaniu wszystkich odpowiedzi. Zamiast tego chodziło o znalezienie zrównoważonego podejścia, które sprawdzi się zarówno dla mnie, jak i dla mojego zespołu. Oznaczało to wprowadzenie kilku fundamentalnych zmian:
- Zacząłem wyznaczać wyraźne granice między czasem pracy a czasem prywatnym, traktując swoją energię jako ograniczony zasób, którym trzeba starannie zarządzać.
- Zamiast próbować być wszędzie i robić wszystko, nauczyłem się bardziej ufać mojemu zespołowi. To nie była tylko delegacja - to było włączenie drugiego biegu.
- Co najważniejsze, przestałem próbować dopasować się do czyjegoś wyobrażenia o tym, jaki powinien być tech lead. Moje doświadczenie jako byłego dekarza, który został programistą, nauczyło mnie wartości praktycznego przywództwa opartego na konkretach, i postanowiłem wykorzystać tę siłę.
Czego naprawdę nauczyło mnie bycie Tech Leadem
Patrząc wstecz na wszystko co przeszedłem, teraz rozumiem, że bycie tech leadem nie polega na byciu najlepszym programistą czy osobą, która pracuje najdłużej. Chodzi o znalezienie równowagi - między kodowaniem a przewodzeniem, między pchaniem tematów do przodu a wycofaniem się, między rozwojem zawodowym a osobistym dobrostanem.
Oto najcenniejsze lekcje, jakie wyciągnąłem po drodze:
O sile autentyczności
Długo próbowałem wpasować się w wyobrażenie “idealnego Tech Leada”. Dopiero gdy przestałem udawać i zacząłem czerpać z własnych doświadczeń - tak, nawet z mojej przeszłości jako dekarz, oraz z moich mocnych stron, ale też i trudności - praca stała się prostsza. Czy próba bycia “idealnym” liderem nie oddala nas czasem od tego, co moglibyśmy naprawdę wnieść do zespołu?
O pułapce przepracowania
Myślałem, że więcej godzin w pracy === lepsze rezultaty. Rzeczywistość szybko zweryfikowała to przekonanie. Kiedy byłem przemęczony, podejmowałem gorsze decyzje i nie potrafiłem wspierać zespołu. Co ciekawe, mój zespół działał najlepiej właśnie wtedy, gdy ja byłem wypoczęty i skoncentrowany. Przypadek?
O zaufaniu i kontroli
Najtrudniejsza lekcja? Zrozumienie, że nie muszę (i nie powinienem) rozwiązywać wszystkich problemów sam. Każda sytuacja, gdy powstrzymałem się od natychmiastowego “ratowania” sytuacji, stawała się szansą rozwoju dla zespołu. Zobaczyłem, jak ludzie rozkwitają, gdy dasz im przestrzeń na własne decyzje - i własne błędy.
O tempie rozwoju
Czułem presję, by znać się na wszystkim od zaraz. Z czasem zrozumiałem, że próba nadążenia za każdą nową technologią i trendem to prosta droga do frustracji. Co by się stało, gdybyśmy zamiast tego skupili się na systematycznym, zrównoważonym rozwoju?
Słowo końcowe
Droga od programisty do tech leada to nie tylko rozwój kariery - to osobista transformacja. Wymaga porzucenia starych nawyków i przyjęcia nowych sposobów myślenia. Ale co najważniejsze, wymaga znalezienia własnego, zrównoważonego sposobu przewodzenia.
Celem nie jest bycie perfekcyjnym tech leadem - chodzi o bycie najskuteczniejszym liderem, jakim możesz być, pozostając wiernym sobie i dbając o swój dobrostan. W końcu przywództwo to maraton, nie sprint.
Epilog: następny rozdział
Niedługo zaczynam coś nowego i nie będę miał już formalnie roli tech leadera. Niektórzy mogą postrzegać moją decyzję o wycofaniu się z liderstwa, by skupić się na byciu senior full stack engineerem i mentorem, jako krok wstecz. Ja widzę to inaczej - chodzi o poruszanie się w kierunku, który przynosi największą wartość i satysfakcję.
Pracując jako tech lead odkryłem coś ważnego o sobie: choć lubię prowadzić i być mentorem, moja prawdziwa pasja leży w rozwiązywaniu złożonych wyzwań technicznych i pomaganiu innym w indywidualnym rozwoju. To odkrycie nie było porażką.
Przywództwo w technologii nie zawsze oznacza zarządzanie zespołem. Czasami oznacza bycie doświadczonym inżynierem, który potrafi zarówno projektować złożone rozwiązania, jak i pomagać innym rozwijać ich umiejętności. Chodzi o znalezienie roli, w której twoja unikalna kombinacja umiejętności i pasji może mieć największy wpływ.
Dla mnie oznacza to skupienie się na tym, co robię najlepiej: pisaniu kodu, rozwiązywaniu problemów i mentorowaniu innych w relacji jeden na jeden. To przypomnienie, że rozwój kariery nie zawsze jest liniowy, i to jest w porządku. Najważniejsze jest bycie szczerym ze sobą odnośnie tego, gdzie możesz wnieść największą wartość i co przynosi ci największe spełnienie.
Pamiętaj, nie ma jednej “właściwej” ścieżki w technologii. Najlepszy ruch w karierze to ten, który jest zgodny z twoimi wartościami i pozwala ci wnieść swój unikalny wkład, niezależnie od formy, jaką może przybrać.