Twój zespół wie, co nie działa. Wystarczy zapytać.

W większości firm IT, z którymi pracuję, zespół potrafi wymienić trzy największe problemy z delivery w ciągu pierwszych pięciu minut rozmowy. Bez przygotowania, bez analizy, bez dashboardu. Wiedzą, co nie działa. Wiedzą od dawna. Tylko że nikt ich nie pyta. Albo pyta, ale nie słucha.

Post A z tego tygodnia mówił o tym, dlaczego diagnoza „zespół nie dowozi” prawie zawsze jest błędna. Ten wpis idzie dalej: jak stworzyć w firmie warunki, w których prawdziwe problemy wychodzą na powierzchnię, zamiast gnić w ciszy?

Zacznę od tego, co widzę u klientów, kiedy wchodzę do firmy po kilku miesiącach kryzysu delivery. Ludzie są zamknięci. Na spotkaniach mówią to, co bezpieczne. Problemy zgłaszają pomiędzy sobą na Slacku, ale nie eskalują. Lider wie, że coś nie gra, ale nie podnosi tematu, bo ostatni, który podniósł, dostał po głowie.

To nie jest firma z toksyczną kulturą. To jest normalna firma, w której ktoś kiedyś zareagował na złą wiadomość tak, że ludzie wyciągnęli wniosek: lepiej nie mówić.

W Elowenta nazywam to efektem zamrożonej informacji. Dane o problemach istnieją w systemie – ludzie je mają. Przepływ tych danych do góry jest jednak zablokowany, bo organizacja nauczyła ludzi, że za przynoszenie złych wiadomości jest kara, nie nagroda.

I tu jest sedno: nie da się naprawić delivery bez informacji o tym, co je blokuje. A tej informacji nie dostaniesz, jeśli ludzie boją się ją podać. Zamrożona informacja to najdroższy koszt ukryty w firmie – bo nie widać go na żadnym dashboardzie, ale widać go w każdym opóźnionym sprincie.

Jedno z najprostszych narzędzi, które wprowadzam u klientów, to zmiana pytania na retrospektywach i spotkaniach kryzysowych. Zamiast „kto zawinił” albo „dlaczego tego nie dowieźliście” – pytanie brzmi: co w systemie sprawiło, że ten wynik był trudny do osiągnięcia?

Różnica wydaje się kosmetyczna. W praktyce zmienia wszystko.

Kiedy pytasz „kto”, ludzie się bronią. Szukają wymówek, wskazują na innych, minimalizują swój udział. Kiedy pytasz „co” – zaczynają opisywać system. I nagle słyszysz rzeczy, o których nikt wcześniej nie mówił: że priorytety zmieniły się trzy razy w sprincie, że decyzja o zakresie przyszła za późno, że klient dodał wymagania po deadline, że lider nie miał mandatu, żeby odmówić.

To nie są wymówki. To jest diagnoza.

Jeden z moich klientów wprowadził tę zmianę na retro i po trzech tygodniach CTO powiedział mi: dowiedziałem się więcej o problemach w delivery w trzy retro niż w sześć miesięcy codziennych statusów. Bo ludzie wreszcie mówili o systemie, nie o sobie.

To pytanie działa zresztą w obie strony. Kiedy sprint poszedł dobrze, zamiast pytać „kto to dowiózł”, pytamy: co w systemie pomogło, że tym razem się udało? Odpowiedzi zwykle wskazują na konkretne warunki – jasne priorytety, brak wrzutek, lider obecny na co dzień. I właśnie te warunki trzeba replikować, nie ludzi.

Samo zadanie lepszego pytania to za mało, jeśli kontekst spotkania nadal krzyczy „szukamy winnego”. Dlatego kiedy wchodzę do firmy w kryzysie delivery, staram się zebrać perspektywy osobno, zanim kogokolwiek posadzę przy jednym stole.

Konkretnie wygląda to tak:

• Rozmawiam z zarządem osobno. Pytam: co widzicie jako problem? Co próbowaliście? Co nie zadziałało?
• Rozmawiam z liderami osobno. Pytam: czego potrzebujecie, żeby dowozić? Co wam przeszkadza? Czego nie możecie powiedzieć zarządowi?
• Rozmawiam z zespołem osobno. Pytam: gdybyście mogli zmienić jedną rzecz w tym, jak pracujecie, co by to było?

To ostatnie pytanie jest najważniejsze. Odpowiedzi zespołu są zwykle bardzo konkretne – nie abstrakcyjne narzekanie, tylko wskazanie palcem: tu jest blokada. Deweloper powie: chcę pracować nad jednym projektem, nie trzema. PM powie: chcę wiedzieć, kto decyduje o zakresie, bo teraz mam trzech szefów. Lider powie: chcę móc odmówić, kiedy ktoś wrzuca zadanie poza sprintem.

Zbieranie perspektyw osobno nie jest manipulacją. To jest ochrona uczciwości odpowiedzi. Ludzie mówią co innego, kiedy szef siedzi w pokoju, niż kiedy go nie ma. I te drugie odpowiedzi są zwykle bliższe prawdzie.

Dopiero potem – kiedy mam pełny obraz – mogę usiąść z zarządem i powiedzieć: oto jak wasze decyzje wyglądają z poziomu zespołu. Nie jako oskarżenie. Jako informacja zwrotna, której organizacja sama sobie nie jest w stanie dać.

To jest moment, w którym wielu liderów po raz pierwszy słyszy, jak ich decyzje wpływają na codzienność zespołu. Nie dlatego, że są złymi ludźmi. Dlatego, że nikt wcześniej nie miał odwagi im tego powiedzieć. Albo próbował, ale forma była taka, że zarząd się zamknął zamiast słuchać.

Nie chcę tworzyć iluzji, że jedna rozmowa rozwiązuje wszystko. Nie rozwiązuje. Jest jednak jedna rozmowa, od której zmiana się zaczyna, i widzę to konsekwentnie u moich klientów.

To jest rozmowa, w której CEO albo CTO mówi do zespołu, wprost i publicznie: wiem, że część problemów z delivery leży po naszej stronie. Chcę wiedzieć, co możemy zrobić inaczej.

Brzmi prosto. W praktyce wymaga ogromnej odwagi, bo wymaga rezygnacji z pozycji „ja wiem lepiej” na rzecz pozycji „pomóżcie mi zobaczyć”.

Z takimi firmami zmiana idzie szybko. Nie dlatego, że problemy są mniejsze. Dlatego, że informacja zaczyna płynąć. Zespół widzi, że ktoś bierze odpowiedzialność, i sam zaczyna brać. Liderzy odzyskują mandat do podejmowania decyzji. Frustracja zamienia się w konstruktywną rozmowę. Delivery nie naprawia się z dnia na dzień, ale naprawia się szybciej, bo ludzie współpracują zamiast się bronić.

U jednego z moich klientów po takiej rozmowie zespół w ciągu dwóch tygodni zgłosił dwanaście blokad, o których zarząd nie miał pojęcia. Dwanaście. Każda z nich spowalniała delivery, a żadna nie wymagała budżetu, żeby ją usunąć.

A są firmy, w których ta rozmowa nigdy nie następuje. I tam zmiana trwa trzy razy dłużej – nie dlatego, że system jest gorszy, tylko dlatego, że ego blokuje przepływ informacji.

Jeśli rozpoznajesz swój zespół w tym tekście, nie musisz czekać na konsultanta ani na wielką transformację. Cztery zmiany, które możesz wprowadzić od następnego tygodnia:

Po pierwsze – zmień pytanie na najbliższej retro z „dlaczego nie dowieźliśmy” na „co w systemie nam przeszkadzało”. Nie tłumacz dlaczego. Po prostu zadaj inne pytanie i słuchaj, co się zmieni w odpowiedziach.

Po drugie – porozmawiaj z dwoma osobami z zespołu jeden na jeden. Nie o wynikach, nie o statusie – o tym, co im przeszkadza w pracy. I kiedy powiedzą coś niewygodnego, nie tłumacz się. Zapisz.

Po trzecie – na następnym spotkaniu zarządu powiedz jedno zdanie: może część problemu leży po naszej stronie. Nie musisz mieć gotowego rozwiązania. Sam fakt, że ktoś na górze to powiedział, zmienia dynamikę.

Po czwarte – sprawdź, czy Twój zespół ma warunki do pracy. Nie lepsze narzędzia, nie większy budżet – podstawy. Jasne priorytety, ochrona przed wrzutkami, lider z mandatem do podejmowania decyzji.

To nie są wielkie zmiany. To jest punkt startowy, od którego organizacja zaczyna mówić o problemach zamiast je ukrywać. A kiedy zaczyna mówić – zaczyna się naprawa.

Twój zespół wie, co nie działa. Wie od dawna. Pytanie nie brzmi, czy mają tę wiedzę. Pytanie brzmi: czy dałeś im warunki, żeby się nią podzielić?

Jeśli nie dałeś – zacznij od tego. Reszta przyjdzie sama.