Github
Linkedin
Jako programista, który zawsze cenił pełną kontrolę nad swoimi zadaniami, zdecydowałem się podjąć wyzwanie zostania tech leadem. Początkowo wydawało się to świetnym pomysłem, ale nowe wyzwania i rosnąca presja doprowadziły mnie do ściany. Wtedy zdałem sobie sprawę, że muszę zadbać o siebie i pracować w sposób, który nie doprowadzi mnie do wypalenia. Dziś podzielę się swoją historią wzlotów i upadków, a ostatecznie znalezienia równowagi - o przezwyciężaniu wypalenia, odzyskiwaniu zdrowia i odnajdywaniu satysfakcji w pracy. Mam nadzieję, że zainspiruje to Cię i da Ci energię do radzenia sobie z własnymi wyzwaniami.
Email, który zmienił wszystko, przyszedł w typowy poniedziałkowy poranek. “Chcielibyśmy, żebyś pokierował zespołem Vue Storefront Magento” - brzmiała wiadomość. Po latach pisania kodu i bycia “pixel-perfect” frontend developerem, to była moja szansa na awans. Jednak jak miałem się wkrótce przekonać, droga od bycia sprawnym programistą do skutecznego tech leada była o wiele bardziej wymagająca, niż sobie wyobrażałem.
Jeśli jesteś programistą rozważającym skok w kierunku przywództwa technicznego lub niedawno przyjąłeś taką rolę, moja historia może pomóc Ci uniknąć niektórych pułapek, w które ja wpadłem. Pozwól, że podzielę się tym, jak przeszedłem tę transformację - od początkowego entuzjazmu, przez momenty kryzysu, aż do znalezienia własnego, zrównoważonego sposobu kierowania zespołem technicznym.
Życie jako programista: komfort kodowania
Jako programista w Divante znalazłem swój rytm. Moje dni miały wygodne tempo - głęboko pochłonięty w kodzie, dopracowywawałem implementacje frontendowe i cieszyłem się, że kolejny design zakodowałem pixel-perfect. Każda linijka kodu była pod moją kontrolą, każdy problem miał jasne rozwiązanie, a mój sukces był mierzony w ukończonych zadaniach i działających funkcjonalnościach.
Przeszedłem długą drogę od skromnych początków, przechodząc z zupełnie innej kariery jako dekarz do pozycji frontend developera. Ta podróż nauczyła mnie wartości ciężkiej pracy i satysfakcji z opanowania rzemiosła. Wypracowałem sobie reputacje “człowieka pixel-perfect” i cieszyłem się przewidywalnością tego, czego ode mnie oczekiwano.
Ale komfort może być zwodniczy. Podczas gdy byłem świetny w pisaniu kodu i rozwiązywaniu problemów technicznych, część mnie zaczęła odczuwać pragnienie czegoś więcej. Ten sam napęd, który pchnął mnie do zmiany kariery lata temu, szeptał, że nadszedł czas na kolejną zmianę.
Skok w tech leading: gdy wszystko się zmieniło
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ć.