Dlaczego asertywność jest ważna dla lidera technicznego?
Asertywność to coś więcej niż umiejętność mówienia "nie". To świadome wyznaczanie własnych granic i komunikowanie ich w jasny, kulturalny sposób. Lider techniczny, który nie jest asertywny, może niechcący brać na siebie zbyt wiele obowiązków lub tolerować rzeczy, które szkodzą projektowi, np. ciągłe zmiany zakresu bez konsekwencji, czy członków zespołu nieprzestrzegających ustaleń. Z kolei asertywny lider:
• Chroni swój zespół przed przeciążeniem: Umie odmówić dodania kolejnego zadania do już pełnego sprintu, proponując realne alternatywy. Dzięki temu zespół pracuje wydajnie, bez gaszenia wiecznych pożarów.
• Utrzymuje porządek w projekcie: Stawia granice zmianom wprowadzanym na ostatnią chwilę i egzekwuje ustalenia (np. wstrzymanie dodawania nowych funkcji przed wydaniem). Unika się w ten sposób chaosu i ciągłych zwrotów akcji w projekcie.
• Szanuje swój czas i zdrowie: Nie pozwala, by każde "pilne" zgłoszenie wymagało siedzenia po nocach. Zachowując równowagę między pracą a życiem prywatnym daje dobry przykład zespołowi.
Co ważne, asertywność buduje także szacunek. Paradoksalnie, otoczenie bardziej ceni lidera, który czasem stawia granice, niż takiego, który zawsze ulega. Jak wskazują badania, asertywni menedżerowie są pewniej swoich decyzji i potrafią jasno przedstawić oczekiwania podwładnym, a przy tym są bardziej otwarci na informacje zwrotne. Innymi słowy, jasna komunikacja w obie strony poprawia współpracę i efektywność zespołu. Lider, który potrafi zakomunikować "to nie jest możliwe w tym terminie" lub "tego od Was oczekuję", tworzy środowisko bez niedomówień, gdzie każdy wie, na czym stoi.
Jak mówić "nie" w konstruktywny sposób
Jednym z największych wyzwań dla lidera bywa mówienie "nie" zarówno przełożonym, jak i członkom własnego zespołu czy klientom. Chcemy być pomocni i kompetentni, więc odruchowo zgadzamy się na dodatkowe zadania. Jednak sztuką jest odmówić tak, aby zachować dobrą relację i jednocześnie postawić granicę. Oto kilka wskazówek, jak konstruktywnie mówić "nie" w środowisku IT:
• Bądź szczery i konkretny: Zamiast wymyślać wymówki, przedstaw rzeczowe powody odmowy. Np. "Nie będziemy w stanie dorzucić tego feature'u w tym sprincie, ponieważ mamy już zaplanowane inne priorytety. Jeśli teraz to wepchnę, ucierpi jakość obecnych zadań.". Taka szczera komunikacja pokazuje, że dbasz o rezultat, a nie że ci się "nie chce".
• Zaproponuj alternatywę: Idealne "nie" często zawiera w sobie propozycję rozwiązania. Jeśli odmawiasz wykonania zadania w nierealnym terminie, zaproponuj inny termin lub zakres. Przykład: "Rozumiem, że to pilne. Obecny zespół może zrealizować tę funkcjonalność na za dwa tygodnie. Ewentualnie, jeśli to musi być szybciej, potrzebujemy dodatkowego developera do pomocy.". W ten sposób pokazujesz, że szukasz rozwiązania, a nie blokujesz inicjatywy.
• Używaj tonu szacunku i empatii: Asertywność nie oznacza bycia opryskliwym. Ważne jest jak mówisz "nie". Zacznij od okazania zrozumienia drugiej strony, a dopiero potem przedstaw swoją odmowę. Np. "Wiem, że zależy Ci na tym raporcie. Chciałbym Ci pomóc, ale dzisiaj mam już zaplanowane kluczowe spotkania. Czy mogę Ci to dostarczyć jutro rano?". Tu empatia łączy się z asertywnym odłożeniem zadania na realny termin.
• Unikaj nadmiernych przeprosin i usprawiedliwień: Masz prawo powiedzieć "nie" bez poczucia winy. Nie musisz długo tłumaczyć się ze swojej odmowy ani tym bardziej za nią przepraszać (oczywiście uprzejme "przykro mi, ale..." na start jest OK). Zbyt wiele tłumaczeń brzmi niepewnie, lepiej krótko podaj powód i przejdź do propozycji rozwiązania.
Przykład (dialog):
PM: "Słuchaj, musisz dołożyć jeszcze poprawkę X do wydania na jutro. To tylko parę linijek kodu."
Tech Lead: "Rozumiem, że zależy Ci na poprawce X przed wydaniem. Obawiam się jednak, że jeśli dorzucimy ją na ostatnią chwilę, możemy nie zdążyć dobrze jej przetestować, a to zagraża stabilności wersji. Proponuję zaplanować ją na następne wydanie, dzięki czemu zrobimy to solidnie. Co o tym myślisz?"
W powyższym scenariuszu lider techniczny nie powiedział po prostu "nie, bo nie". Zamiast tego jasno przedstawił konsekwencje (ryzyko dla stabilności), pokazał zrozumienie dla perspektywy PM-a i zaproponował konkretne wyjście (następne wydanie). Taka postawa jest profesjonalna i trudniej ją zakwestionować. Jeśli druga strona naciska dalej, warto zachować spokój i konsekwencję, czasem pomocna jest technika "zdartej płyty", czyli powtarzania swojego stanowiska innymi słowami tak długo, aż dotrze do rozmówcy, że granica nie zostanie przesunięta.
Wyrażanie oczekiwań wobec zespołu
Bycie asertywnym liderem to nie tylko umiejętność odmawiania, to również jasne komunikowanie oczekiwań względem swoich podwładnych (czy współpracowników). Brak klarownych oczekiwań prowadzi do nieporozumień: jeśli nie mówisz wprost, czego wymagasz, zespół może "niedowieźć" lub pracować w błędny sposób, a Ty będziesz sfrustrowany. Jak temu zaradzić?
• Komunikat "JA" i konkrety: Mów wprost, czego potrzebujesz od zespołu, używając komunikatów typu "oczekuję / potrzebuję / zależy mi". Np. "Oczekuję, że będziemy na bieżąco pisać testy jednostkowe do nowego modułu, to ważne dla jakości projektu". Unikaj pasywnego sugerowania ("dobrze by było mieć testy..."), jasne postawienie sprawy usuwa domysły.
• Ustal zasady i granice w zespole: Jako lider wyznacz ramy pracy, ale też egzekwuj je. Jeżeli ustaliliście, że np. code review jest obowiązkowe przed merge, to tego się trzymaj. Gdy ktoś notorycznie łączy kod bez review, asertywnie reaguj od razu: przypomnij zasadę i oczekiwanie, a jeśli trzeba wprowadź konsekwencje (np. cofnięcie merge i prośba o review). Ludzie muszą wiedzieć, że Twoje zasady nie są "na pokaz".
• Słuchaj i bądź otwarty na feedback: Asertywność lidera działa w dwie strony, Ty mówisz czego chcesz, ale też zachęcasz zespół, by zgłaszał swoje potrzeby czy problemy. Kiedy jasno komunikujesz oczekiwania, zapytaj, czy zespół wszystko rozumie i czy ma zasoby, by temu sprostać. Jeśli programista mówi "potrzebuję wsparcia, nie znam tej technologii", nie odbieraj tego jako podważania Twoich poleceń, to szansa, by wspólnie znaleźć rozwiązanie (szkolenie, pair programming itp.).
Wyrażając oczekiwania, bądź stanowczy, lecz życzliwy. Twój zespół doceni jasność, nawet jeśli początkowo ktoś może kręcić nosem, że stawiasz wymagania, finalnie większość profesjonalistów woli wiedzieć, gdzie stoi poprzeczka. To buduje poczucie bezpieczeństwa: każdy zna swoje role i zadania, a Ty unikasz sytuacji, w których "sam musisz zrobić wszystko", bo bałeś się wyrazić wymagania wobec innych.
Komunikowanie granic i potrzeb względem przełożonych
Lider techniczny jest często w środku hierarchii zarządza zespołem, ale sam podlega menedżerom wyższego szczebla, klientom lub zarządowi. Asertywność przydaje się również "w górę". Oznacza to umiejętność informowania przełożonych o realnych ograniczeniach, potrzebach zespołu, czy zgłaszania problemów, zanim urosną do rangi kryzysu. Kilka przykładów takiej komunikacji:
• Realistyczne terminy i zakres: Gdy szef przekazuje ambitny termin lub dokłada obowiązki, a Ty widzisz, że to nierealne, nie bój się uprzejmie zaoponować. Lepsze jest wcześniejsze "alarmowanie", niż późniejsze niewywiązanie się z obietnic. Powiedz np.: "Aby dostarczyć te funkcje do końca kwartału, potrzebujemy dodatkowych dwóch osób w zespole albo musimy z czegoś zrezygnować. Inaczej istnieje ryzyko, że projektu nie domkniemy na czas.". Taka szczera informacja może skłonić przełożonego do przemyślenia priorytetów.
• Informowanie o przeciążeniu zespołu: Jeśli zauważasz, że Twój zespół pracuje na 120% normy od dłuższego czasu, zgłoś to otwarcie. Przykład komunikatu asertywnego w górę: "Mój zespół od dwóch miesięcy pracuje po godzinach, by dowieźć projekt X. Obawiam się, że dłużej tak nie pociągniemy bez uszczerbku na jakości. Potrzebujemy oddechu, czy możemy przez najbliższy sprint skupić się tylko na refaktorze i bugfixach, bez nowych zadań?". Taka wypowiedź sygnalizuje problem i sugeruje rozwiązanie. Dobry przełożony doceni, że dbasz o zespół i projekt, zamiast milczeć aż połowa ludzi odejdzie z wypaleniem zawodowym.
• Wyrażanie własnych aspiracji i granic: Asertywny lider potrafi też zakomunikować swoje potrzeby przełożonemu. Np. "Chciałbym w przyszłym roku rozwijać się w kierunku architektury oprogramowania, czy jest szansa na projekty, które dadzą mi taką możliwość?" albo "Zależy mi, abyśmy przestrzegali ustalonego procesu deploymentu, ostatnie pominięcie testów spowodowało awarię. Proszę, zadbajmy razem o dyscyplinę w tym zakresie.". W ten sposób mówisz otwarcie, co jest dla Ciebie ważne, zamiast tłumić frustracje.
Pamiętaj, że komunikując się z przełożonymi też masz prawo stawiać granice, oczywiście z zachowaniem profesjonalizmu i szacunku. Twoja asertywność nie jest buntem, lecz troską o powodzenie projektu i dobro zespołu. Często menedżerowie wyżej cenią tych liderów, którzy potrafią czasem powiedzieć niewygodną prawdę, niż tych, którzy zawsze przytakują, a potem projekty się sypią. Odważne, konstruktywne komunikowanie faktów buduje Twój autorytet jako rzetelnego lidera.
Podsumowanie
Asertywność lidera technicznego to umiejętność balansowania między potrzebami projektu, zespołu i przełożonych, bez rezygnowania z własnych granic. Dzięki niej unikniesz przeładowania obowiązkami i projektowego chaosu. Nauczysz się priorytetyzować i skupiać na tym, co naprawdę istotne. Pamiętaj, że asertywność to nie agresja ani egoizm. To klarowna komunikacja: mówienie "tak" wtedy, gdy naprawdę możemy, i mówienie "nie" wtedy, gdy trzeba - w sposób kulturalny i z propozycją rozwiązania. Taka postawa zapobiega frustracji, nedopowiedzeniom i wypaleniu zawodowemu.
Na koniec zachęcam: przyjrzyj się najbliższym wyzwaniom w swojej pracy lidera i spróbuj zastosować powyższe rady w praktyce. Może to oznaczać powiedzenie "nie" zadaniu, które wykracza poza zasoby zespołu, albo odbycie szczerej rozmowy z programistą, który nie trzyma się standardów projektu. Zobaczysz, że z czasem stanie się to łatwiejsze, a Twój zespół i przełożeni będą Cię szanować za konsekwencję i uczciwość. Asertywność naprawdę działa, pozwala liderowi technicznemu prowadzić projekt pewną ręką, zamiast dać się ponieść cudzym żądaniom.
PS: Jako doświadczony programista i mentor wiem, że pewność siebie w komunikacji idzie w parze z kompetencjami technicznymi. Im lepiej znasz się na swoim fachu, tym łatwiej bronić swoich decyzji. Dlatego warto ciągle się rozwijać. Jeżeli chcesz wzmocnić swoje umiejętności (np. w zakresie .NET, ASP.NET Core, AI w C# i nie tylko), rozważ dołączenie do jednego z moich szkoleń online. Pomogłem już wielu developerom stać się pewniejszymi swoich umiejętności - Ty też możesz. Jeśli nie wiesz, które szkolenie wybrać, zajrzyj na tę stronę z listą szkoleń, gdzie znajdziesz pełną ofertę. Powodzenia w dalszym rozwoju i pamiętaj: dobry lider uczy się przez całe życie.
