Twój zespół nie jest problemem. Twoje decyzje – tak.

Na spotkaniu zarządu pada zdanie: „zespół nie daje rady”. CEO kiwa głową. CTO dorzuca: „może powinniśmy wymienić lidera”. HR dostaje brief na rekrutację. I wszyscy wychodzą z poczuciem, że zidentyfikowali problem.

Pracuję z firmami IT od lat i widzę ten scenariusz regularnie. Diagnoza „zespół nie dowozi” jest najłatwiejszą odpowiedzią, jaką może dać zarząd. Jest też najdroższą – bo prawie zawsze mija się z prawdą.

„Na górze w sensie CEO czy CTO mówią: a zespół nie daje rady.”

To zdanie słyszę w różnych wariantach u większości klientów, z którymi pracuję. „Dlaczego mamy taki niekompetentny zespół.” „Kogo myśmy zrekrutowali.” „Oni już nic nie potrafią.” Brzmi jak diagnoza. W rzeczywistości to projekcja.

Bo zanim ktokolwiek powie „zespół nie dowozi”, warto zadać jedno pytanie: a co dokładnie ten zespół dostał do dowiezienia?

Widzę ten wzorzec u 8 na 10 firm. Zespół dostaje zakres, który od początku był nierealny. Priorytety zmieniają się co tydzień. Lider nie ma mandatu, żeby powiedzieć „nie”. Ludzie są rozrywani między projekty. A kiedy delivery pada – odpowiedzialność spada na dół.

To jest jedna z patologicznych form reakcji na kryzys. Problem zostaje uproszczony do kompetencji ludzi na dole, nawet jeśli źródło leży w błędach zarządczych, w niejasnych decyzjach albo w fatalnie ustawionym projekcie. Taka narracja nie tylko nie rozwiązuje problemu. Niszczy też zaufanie, które jest jedynym paliwem, na jakim delivery może działać.

Co gorsza – działa jak samospełniająca się przepowiednia. Zespół słyszy, że „nie daje rady”. Najlepsi ludzie zaczynają szukać pracy. Ci, którzy zostają, przestają się starać, bo wiedzą, że i tak dostaną winę. Firma traci kompetencje, więc delivery spada jeszcze bardziej. I zarząd mówi: „widzicie, mówiłem, że zespół jest słaby”.

Kiedy organizacja wchodzi w tryb „kto zawinił”, dzieje się coś bardzo konkretnego. Ludzie przestają mówić o problemach.

Widzę to u klientów wyraźnie. W firmie, gdzie lider wie, że za złą wiadomość zostanie ukarany – albo przynajmniej publicznie „rozliczony” – informacja o ryzyku przestaje płynąć do góry. Deweloper nie zgłasza, że estymacja jest nierealna. PM nie mówi, że klient zmienił zakres, a nikt tego nie zatwierdził. Lider nie eskaluje, bo ostatnim razem eskalacja skończyła się wymianą lidera, nie naprawą problemu.

Organizacja traci system wczesnego ostrzegania. A bez niego każdy problem w delivery rośnie w ciszy, aż staje się kryzysem.

Ten mechanizm widzę szczególnie w firmach usługowych – software house’ach i agencjach, gdzie presja klienta dodaje dodatkową warstwę stresu. Lider projektu jest zaciśnięty między klientem, który żąda terminów, a zarządem, który żąda marży. Kiedy coś idzie źle, łatwiej jest powiedzieć „zespół nie wyrobił” niż „źle wyestymowaliśmy” albo „zgodziłem się na nierealny termin”.

Znam firmy, gdzie rotacja w zespołach delivery sięga 25-30% rocznie. Zarząd tłumaczy to „rynkiem” albo „pokoleniem Z”. Kiedy jednak rozmawiam z odchodzącymi ludźmi, obraz jest inny. Odchodzą nie dlatego, że mają za dużo pracy. Odchodzą, bo mają poczucie, że ich praca nie ma sensu – bo decyzje zapadają gdzie indziej, a odpowiedzialność spada na nich.

„Czego firmy najbardziej nie chcą usłyszeć? Że popełniły błąd.”

To jest zdanie, które mówię klientom wprost. I reakcja na nie wiele mówi o kulturze organizacji.

Jest taki moment w każdym kryzysie delivery, kiedy rozmawiam osobno z zarządem i osobno z zespołem. Za każdym razem słyszę dwie kompletnie różne historie o tym samym projekcie.

Zarząd mówi: brakuje zaangażowania, ludzie nie dowożą, potrzebujemy lepszych ludzi albo lepszego lidera. Patrzy na delivery z perspektywy wyników – i wyniki są złe, więc problem musi być w wykonaniu.

Zespół mówi: brak decyzji, chaos, zmiany priorytetów, słaba komunikacja, wrzutki z góry, obchodzenie liderów. Patrzy na delivery z perspektywy codzienności – i codzienność jest niemożliwa do ogarnięcia, więc problem musi być w systemie.

Niedawno pracowałem z firmą produktową, gdzie CEO powiedział mi: „mamy problem z zaangażowaniem, ludzie robią minimum”. Tego samego dnia rozmawiałem z dwoma deweloperami z tego samego zespołu. Jeden z nich powiedział coś, co utkwiło mi w głowie: „robię minimum, bo maksimum i tak zostanie zmienione w połowie sprintu. Po co się angażować w coś, co za tydzień będzie nieaktualne?”

To nie był leniwy deweloper. To był zmęczony deweloper, który nauczył się, że zaangażowanie w tym systemie jest karą, nie nagrodą.

„Każdy ma swoją perspektywę i to też ewidentnie widać.”

Kto ma rację? Zwykle obie strony widzą prawdziwe fragmenty obrazu. Jest jednak jeden niesymetryczny element: zarząd ma władzę, żeby zmienić system. Zespół nie ma. Jeśli zarząd widzi tylko „słabe wykonanie”, a nie widzi swojego wpływu na warunki tego wykonania – naprawianie delivery zaczyna się od złego końca.

W Elowenta pierwszą rzeczą, którą robimy w takiej sytuacji, jest zebranie obu perspektyw i położenie ich obok siebie. Nie po to, żeby ustalić, kto ma rację. Po to, żeby zarząd zobaczył, jak jego decyzje wyglądają z poziomu zespołu. To nie jest wygodne spotkanie. Bez niego jednak organizacja będzie dalej leczyć objawy, nie przyczyny.

Żeby było jasne – nie twierdzę, że problem nigdy nie leży w zespole. Bywa tak. Ktoś został źle dobrany. Lider nie daje rady. Warunki się zmieniły, a skład zespołu nie nadąża za nową rzeczywistością. To się zdarza i trzeba to umieć nazwać.

Żeby to jednak uczciwie stwierdzić, trzeba najpierw odsiać błędy systemowe od personalnych. I tu większość firm robi błąd, który kosztuje je miesiące i ludzi – zaczyna od wymiany osób, zanim sprawdzi system.

Prosty test, który robię z klientami: weź trzech różnych liderów i wstaw ich w ten sam system – te same priorytety, ten sam backlog, ten sam zarząd, ten sam klient. Jeśli każdy z nich miałby ten sam problem z delivery – to nie jest problem lidera. To jest problem systemu.

U klienta, z którym pracowałem w zeszłym kwartale, zarząd był przekonany, że problem leży w Team Leaderze. „Nie radzi sobie, nie dowozi, nie komunikuje.” Zrobiliśmy ten test mentalnie – i okazało się, że trzy wcześniejsze osoby na tej pozycji miały dokładnie te same problemy. Nie lider był zły. Stanowisko było ustawione tak, że nikt nie mógł na nim wygrać. Lider dostawał sprzeczne wytyczne od dwóch dyrektorów, nie miał budżetu na narzędzia, o które prosił od pół roku, i odpowiadał za wyniki zespołu, nad którego składem nie miał żadnej kontroli.

„Jeżeli zarząd jest świadomy, to wie, że sam mógł popełnić błędy, ale jeżeli jest nieświadomy, no to jest jeszcze trudniej.”

To rozróżnienie – świadomy vs nieświadomy zarząd – zmienia wszystko w pracy z firmą. Ze świadomym zarządem można naprawiać. Z nieświadomym trzeba najpierw zbudować tę świadomość, a to wymaga czasu i zaufania.

Najtrudniejszy moment w mojej pracy to nie audyt procesów i nie analiza backlogu. To moment, w którym trzeba powiedzieć komuś wysoko w organizacji, że popełnił błąd.

„Im wyżej stoi, tym jest bardziej nieomylny i nie chce wiedzieć, że się pomylił.”

Nie mówię tego z osądem. Rozumiem mechanizm. CEO, który zbudował firmę od zera, ma silne poczucie, że wie lepiej. CTO, który wybrał architekturę, nie chce słyszeć, że to ona blokuje delivery. Founder, który obiecał klientowi termin, nie chce przyznać, że obietnica była nierealna. To jest ludzkie.

Dopóki jednak organizacja broni błędnych decyzji zamiast je korygować, delivery będzie się sypać. Można wymienić cały zespół, wdrożyć nowe narzędzia, zatrudnić trzech Scrum Masterów – i nic się nie zmieni, bo źródło problemu siedzi wyżej.

Konkretnie – kiedy wchodzę do firmy z tym tematem, zaczynam od trzech rzeczy:

• Rozmowy z zarządem i zespołem osobno, żeby zebrać obie perspektywy bez cenzury.
• Przeglądu ostatnich trzech decyzji, które wpłynęły na delivery – kto je podjął, na jakiej podstawie, co się stało potem.
• Prostego pytania do zarządu: gdybyś wymienił cały zespół na nowych ludzi jutro, czy te same problemy wróciłyby za trzy miesiące?

To ostatnie pytanie zwykle wywołuje ciszę. Długą ciszę. I ta cisza jest początkiem prawdziwej rozmowy.

W firmach, z którymi pracuję, zmiana zaczyna się od jednej rzeczy: oddzielenia diagnozy systemowej od personalnej. Zanim powiesz „lider nie daje rady”, sprawdź, czy dałeś mu warunki, żeby dać radę. Zanim powiesz „zespół nie dowozi”, sprawdź, co im dałeś do dowiezienia. Zanim wymienisz ludzi, sprawdź, czy nowi dostaną ten sam niemożliwy setup.

To nie znaczy, że nikt nigdy nie ponosi odpowiedzialności personalnej. Znaczy, że uczciwość wymaga sekwencji: najpierw system, potem ludzie.

Znam bardzo wielu właścicieli, CEO i CTO, którzy to rozumieją. Którzy przychodzą i mówią: „wiem, że problem może leżeć po mojej stronie, pomóż mi go zobaczyć”. Z takimi firmami praca idzie szybko, bo nie trzeba walczyć z ego, żeby dotrzeć do przyczyny.

A są firmy, które przychodzą z gotową diagnozą: „napraw nam zespół”. I dopiero w trakcie pracy okazuje się, że zespół nie wymagał naprawy. Wymagał ochrony.

„Zespół nie daje rady.” Być może. Ale zanim to powiesz, zadaj sobie jedno pytanie: czy dałeś im warunki, żeby dać radę?

Bo prawdziwa odwaga w zarządzaniu to nie dokręcanie śruby zespołowi, który i tak daje z siebie wszystko. Prawdziwa odwaga to spojrzenie w lustro i zapytanie: co ja zrobiłem, żeby ten zespół mógł dowozić? I co zrobiłem, żeby mu to utrudnić?

Jeśli odpowiedź nie jest jednoznaczna – to nie zespół jest miejscem, od którego powinieneś zacząć.