Dlaczego Twój najlepszy specjalista nie radzi sobie jako lider?

Poniedziałek rano, standup. Tomek, jeszcze trzy miesiące temu najlepszy senior w zespole, stoi przed tablicą i tłumaczy, dlaczego sam wziął na siebie najtrudniejszy task ze sprintu.

Znowu.

Zespół milczy. Jeden patrzy w telefon, drugi w laptopa. Tomek pracuje po 60 godzin tygodniowo, a zespół dowozi mniej niż przed jego awansem.

Widzę tę scenę regularnie. Firma awansuje swojego najlepszego człowieka, a potem dziwi się, że zamiast dwóch wygranych, dobrego lidera i silnego zespołu, ma dwie straty. Straciła świetnego specjalistę i zyskała sfrustrowanego menedżera.

Bo kod jest przewidywalny, a ludzie nie. To naprawdę takie proste.

Przez lata jako specjalista budowałeś poczucie kompetencji na twardych wynikach, działający feature, naprawiony bug, zamknięty ticket.

Nagle zostajesz liderem i te mierzalne dowody znikają. Twój dzień wypełniają rozmowy, negocjacje priorytetów, spotkania 1:1, na których ktoś mówi Ci, że jest nieszczęśliwy w pracy. I nie ma na to pull requesta.

Ludzie w stresie wracają do tego, co znają. Psychologowie nazywają to regresją, cofaniem się do zachowań, które kiedyś dawały poczucie bezpieczeństwa. Dla programisty to IDE. Dla architekta, diagramy. Dla testera, przypadki testowe.

Problem w tym, że każda godzina, którą lider spędza w kodzie, to godzina, w której nikt nie zarządza zespołem. A zespół bez kierunku nie stoi w miejscu, cofa się.

Najkrótszą odpowiedzią jest błąd poznawczy.

Widzimy kogoś, kto świetnie koduje, i automatycznie zakładamy, że będzie równie świetnie delegować, rozwiązywać konflikty i prowadzić trudne rozmowy.

To tak, jakby awansować najlepszego kucharza na menedżera restauracji, umiejętność przyrządzenia idealnego sosu nijak nie przekłada się na układanie grafiku, zarządzanie dostawcami i motywowanie kelnerów.

W firmach technologicznych 20–150 osób widzę to szczególnie często. Firma rośnie, przechodzi z fazy „wszyscy się znają” do czegoś bardziej ustrukturyzowanego. Trzeba wybrać liderów. I kto dostaje awans? Osoba z najdłuższym stażem lub najwyższym performance rate.

Tyle, że performance rate mierzy, ile ktoś dowozi jako specjalista. Nie mierzy, czy potrafi sprawić, żeby inni dowozili. To zupełnie inna kompetencja.

Dane są bezlitosne. Według Center for Creative Leadership aż 60% nowych menedżerów nigdy nie otrzymuje żadnego przeszkolenia w momencie przejścia do roli liderskiej.

Firma Gartner potwierdza, że 60% z nich upada w ciągu pierwszych 24 miesięcy, głównie z powodu braku kompetencji zarządczych.

Wyobraź sobie, że wrzucasz juniora na produkcję bez code review, bez mentora, bez dokumentacji.

Absurd? A dokładnie to robimy z nowymi liderami.
W polskich software house’ach wygląda to zwykle tak: piątek, podpisanie aneksu, poniedziałek, jesteś Team Leadem. Żadnego okresu przejściowego, żadnego shadowingu, żadnego mentora.

Oczekiwanie jest proste: „dasz radę, przecież jesteś nasz najlepszy”.

To nie jest problem konkretnej osoby. To systemowe zaniedbanie.

Każdy specjalista, który zostaje liderem, przynosi ze sobą nawyki, które dotychczas były jego siłą. Po awansie stają się kotwicą.

„Zrobię to sam, bo będzie szybciej” – jako senior miałeś rację. Jako lider, robiąc task za kogoś, blokujesz rozwój zespołu i tworzysz bottleneck na sobie. Twój zespół nigdy nie nauczy się chodzić, jeśli cały czas go nosisz.

Perfekcjonizm w code review – przepisywanie cudzego kodu, żeby wyglądał „tak jak trzeba”, to najszybszy sposób na zabicie inicjatywy w zespole. Lider uczy standardów, a nie narzuca swojego stylu.

Unikanie trudnych rozmów – jako specjalista mogłeś zignorować konflikt w zespole. Jako lider, każdy dzień zwłoki pogarsza sytuację. Rozmowa, której nie przeprowadzisz w poniedziałek, wraca do Ciebie w piątek, z odsetkami.

Oduczenie się tych nawyków wymaga świadomego wysiłku. I czasu.

Przygotowanie powinno zacząć się przed awansem, nie po. Oto trzy rzeczy, które działają u moich klientów:

Podwójna ścieżka kariery. Oddziel ścieżkę ekspercką (Staff/Principal Engineer) od menedżerskiej. Wybitny specjalista musi mieć możliwość awansu finansowego bez konieczności zarządzania ludźmi. Jeśli jedyną drogą do podwyżki jest stanowisko liderskie, będziesz produkować niechętnych menedżerów. A niechętny menedżer to tykająca bomba.

Okres przejściowy zamiast jednorazowego aneksu. Traktuj pierwsze trzy miesiące jako „First-time Manager Onboarding”, z mentorem, z jasnym planem wdrożenia w delegowanie i feedback, z regularnymi sesjami. Nie aneks i „powodzenia”.

Kontrakt liderski. Ustal na piśmie: jaki procent czasu lider koduje (np. max 30%), a jaki zarządza. Powiąż premię ze wskaźnikami rotacji i nastrojów w zespole (eNPS), nie tylko z delivery. Bo lider, którego rozliczasz wyłącznie ze sprintu, będzie optymalizował sprint, kosztem ludzi.

Wróćmy do Tomka z początku tego tekstu. Trzy miesiące po wdrożeniu kontraktu liderskiego i cotygodniowych sesjach z mentorem przestał brać najtrudniejsze taski na siebie.

Zespół zaczął dowozić. Tomek wciąż pisze kod, ale 30% czasu, nie 80%.

Jeden konkretny krok, który możesz zrobić jutro: usiądź ze swoim ostatnio awansowanym liderem i zapytaj, ile godzin szkolenia z zarządzania ludźmi masz za sobą (może nawet nie musisz go pytać)?

Odpowiedź prawdopodobnie powie Ci wszystko, co musisz wiedzieć.