Jak wejść w rolę lidera w IT bez tracenia kontaktu z technologią i własnym stylem pracy?
W tym artykule poznasz konkretne lekcje z doświadczenia Jakuba Kubryńskiego – o budowaniu autorytetu, dawaniu feedbacku, delegowaniu zadań i unikaniu najczęstszych błędów początkujących liderów. Dowiedz się, co naprawdę oznacza bycie liderem technicznym i jak rozwijać się bez wypalania. Niezależnie od tego, czy planujesz zostać liderem, czy po prostu chcesz lepiej odnajdywać się w zespole.
Liderem zostajesz wtedy, gdy zaczynasz działać, nie gdy ktoś cię mianuje
W rozmowie Jakub opowiadał o tym, że nigdy nie planował zostania liderem. Miał po prostu trudny projekt, w którym zaczął ogarniać rzeczy: rozmawiać z klientem, poprawiać procesy, usprawniać współpracę. Zespół sam zaczął przychodzić do niego z tekstem „Kuba, pogadaj z nimi”. I tak został liderem zanim ktokolwiek mu to oficjalnie zaproponował.
Jeśli masz w sobie impuls do działania i chcesz naprawiać rzeczy wokół siebie, to już pierwszy krok. Tak właśnie zaczyna się wiele ścieżek „jak zostać liderem IT”.
Strach przed nieznanym: co powstrzymuje programistów przed zostaniem liderem?
Jeśli myślisz o wejściu w rolę lidera, ale coś cię powstrzymuje, nie jesteś sam. Wiele osób z technicznym backgroundem ma podobne obawy. Najczęstsze z nich to:
-
lęk, że odejdziesz od tego, co lubisz najbardziej, czyli kodowania,
-
obawa, że zostaniesz „kierownikiem bez sensu”: bez przygotowania i narzędzi,
-
brak jasności, czego właściwie się od ciebie oczekuje i niechęć do improwizacji.
Te wątpliwości są naturalne. Ważne, by ich nie ignorować, tylko zadbać o konkretne przygotowanie. Dobrze zaprojektowany program rozwoju liderskiego, oparty na ćwiczeniach, scenkach, feedbacku i realnych sytuacjach z życia zespołu, potrafi zdjąć wiele z tych blokad. Zarządzania, podobnie jak inżynierii, można się po prostu nauczyć.
Jak poznać, że jesteś gotowy na rolę lidera?
To nie jest tak, że pewnego dnia nagle poczujesz się gotowy. Gotowość pojawia się wtedy, gdy teoria z książek i szkoleń zaczyna działać w praktyce, a Ty jesteś w stanie sobie z tym poradzić.
Przykłady:
- odmówienie komuś podwyżki z jasnym, merytorycznym uzasadnieniem – bez zasłaniania się HR-ami, po prostu: „uważam, że to jeszcze nie ten moment, ale tu jest plan, co warto poprawić”;
- udzielenie konstruktywnego feedbacku, nawet gdy coś „poszło totalnie źle”;
- rozwiązanie konfliktu w zespole.
To właśnie w takich momentach okazuje się, czy jesteś gotowy. Jak ujął to Kuba Kubryński:
„I się okazało, że… nic się nie spaliło. Nikt mnie nie wyrzucił przez okno. Wtedy poczułem: okej, chyba naprawdę potrafię to robić.”
To był moment przełomowy – nie dlatego, że wszystko zrobił idealnie, ale dlatego, że wiedział, co robi i widział efekty.
Feedback: najlepsze narzędzie lidera (i nie tylko lidera)
Jeśli miałbyś dziś zrobić tylko jedną rzecz na swojej ścieżce, zacznij budować kulturę feedbacku w zespole. To nie jest temat zarezerwowany tylko dla liderów. To umiejętność, która przydaje się każdemu w IT.
Jak to robić:
- nie traktuj feedbacku jak ataku – to forma troski,
- mów ludziom wprost: “Jeśli nie powiesz mi, co robię źle, to zawsze będę robił to źle”,
- przyjmuj feedback spokojnie i wdrażaj go,
- dawaj przykład – sam też udzielaj informacji zwrotnych.
Case: Jakub dostał feedback, że jego żart był słaby i nieprofesjonalny. Zamiast się obrazić, podziękował, poprawił się i temat był zamknięty.
Delegowanie odpowiedzialności w IT – krok po kroku
Nie da się od razu przeskoczyć z mikrozarządzania do pełnej autonomii. Ale można zacząć proces:
- Zacznij pytać ludzi: “Co byś zrobił jako pierwszy krok?”
- Pomóż im dojść do planu działania – zamiast go narzucać.
- Nie myl delegowania z abdykacją – nadal jesteś odpowiedzialny, ale dajesz przestrzeń.
W tym kontekście padł też temat Extreme Ownership – podejścia znanego z książki Jocko Willinka i Leifa Babina (tak, tych od Navy SEALs).
W skrócie:
Kiedy wchodzisz w rolę lidera, zmienia się też zakres Twojej odpowiedzialności. Odpowiadasz nie tylko za swoje zadania, ale też za to, jak działa cały zespół.
To nie znaczy, że wszystko zawsze jest Twoją winą. Chodzi o to, że masz wpływ i masz obowiązek go wykorzystywać.
„Skoro coś się nie wydarzyło, może mogłem lepiej pomóc, może mogłem wcześniej zareagować, może mogłem dopytać. Może mogłem coś zrobić inaczej.”
To właśnie ten mindset. Nie chodzi o szukanie winnych, tylko o refleksję: „co ja mogę zrobić lepiej jako lider?”
Jak niechcący zabijać inicjatywę? Case study
Jakub miał dobre intencje. Chciał challenge’ować pomysły swojego zespołu. Problem? Robił to zbyt mocno, zbyt szybko, zbyt bezpośrednio. Ludzie zaczęli się wycofywać, nie wychodzili z nowymi pomysłami.
Dopiero feedback od mentora otworzył mu oczy: “To nie oni są nieproaktywni. To ty ich gasisz, zanim skończą mówić.”
Ten case świetnie pokazuje, że nawet najlepsze intencje mogą prowadzić do złych efektów, jeśli brakuje autorefleksji i otwartości na feedback.
Co możesz zrobić dzisiaj?
Zacznij budować kulturę feedbacku.
To coś, co możesz robić bez czekania na awans czy kurs. Możesz to wdrożyć jako developer, QA, UX/UI designer lub product manager, niezależnie od tytułu.
To najskuteczniejszy soft skill w branży IT. Fundament, na którym zbudujesz wszystko inne: lepszą współpracę, trafniejsze decyzje i własny rozwój liderski.
Najważniejsze lekcje z lunchu #2 – w skrócie
- Liderem stajesz się przez działanie, nie przez nominację.
- Feedback to klucz do rozwoju – również w roli programisty.
- Delegowanie ≠ abdykacja.
- Twoje intencje nie zawsze równe są efektom – pytaj, proś o feedback.
- Nie czekaj na „gotowość” – działaj i ucz się po drodze.
Chcesz więcej takich konkretów?
➡ Zapisz się na mailing Horyzontu Lidera, w którym dzielimy się cennymi wskazówkami dotyczącymi zarządzania w IT.
➡ Subskrybuj kanał DevStyle na YouTube, aby nie przegapić kolejnych rozmów i inspirujących materiałów!
Obejrzyj całą rozmowę tutaj:
