Gdzieś między retrospekcją po nieudanym sprincie a eskalacją do zarządu manager IT traci grunt pod nogami. Nie dlatego, że nie zna się na robocie. Raczej dlatego, że nikt go specjalnie nie pyta, czy potrzebuje pomocy – bo przecież skoro zarządza innymi, to sam sobie poradzi. Ten cichy aksjomat kosztuje firmy sporo, choć nikt nie stawia go wprost na tablicy w sali konferencyjnej.
Syndrom środkowego piętra – skąd się bierze ta izolacja
Manager IT to klasyczny człowiek pośrodku. Dostaje priorytety z góry, odpowiada za wyniki na dole, a przestrzeń między tymi dwoma warstwami jest często dość wąska. DeMarco i Lister opisali to w Peopleware jeszcze w 1987 roku – twierdzili, że główne przyczyny niepowodzeń projektów programistycznych tkwią w ludziach i relacjach, nie w technologii. Trzy dekady później ta obserwacja nadal trzyma się mocno. Twój manager IT może doskonale ogarniać Jirę, backlog i Sprint Review, ale jeśli nikt nie dba o to, żeby on sam miał z kim porozmawiać o trudnych decyzjach, zaczyna podejmować je w próżni.
Standish Group w swoim CHAOS Report od lat śledzi losy projektów IT. Dane są raczej przygnębiające – tylko co trzeci projekt kończy się tym, czym miał się skończyć, a znacząca część przekracza budżet lub harmonogram. Oczywiście winne są metodologie, wymagania i technologia. Ale jeśli przyjrzysz się retrospekcjom po fakapach, często gdzieś w tle jest manager, który przez 6 miesięcy nie miał z kim skonsultować eskalacji, bo bał się wyglądać na niekompetentnego przed zarządem i słabego przed zespołem.
Prawo Brooksa i konsekwencje dla menedżerskiego wsparcia
Fred Brooks sformułował w 1975 roku swoją słynną obserwację: dodanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej. Przez lata traktowaliśmy to jako tezę o programistach i onboardingu. Tymczasem to samo działa na poziomie zarządzania. Kiedy manager IT wpada w kłopoty, organizacja często reaguje, dorzucając mu kolejne spotkania statusowe, dodatkowy reporting do zarządu i konsultanta od governance, który zjawia się na dwa tygodnie i zostawia 40-stronicowy raport. Efekt jest przewidywalny – manager ma teraz więcej do ogarnięcia i mniej czasu na rzeczywiste zarządzanie.
Wyobraź sobie team lead w firmie usługowej, który nagle przejmuje projekt po poprzedniku – 8 osób, termin za 4 miesiące, połowa wymagań nieudokumentowana. Zamiast dostać kogoś, z kim może co tydzień przez godzinę przegadać decyzje, dostaje dostęp do platformy e‑learningowej z kursem PRINCE2 Foundation i maila z życzeniami powodzenia. Kurs ma 3 dni materiału wideo. Projekt ma 4 miesiące. Rachunek jest prosty.
Co tak naprawdę daje wsparcie dla managera IT
Drucker pisał w The Effective Executive, że skuteczni menedżerowie nie podejmują wielu decyzji – koncentrują się na tych naprawdę ważnych. Żeby to osiągnąć, potrzebują środowiska, które nie generuje ciągłego szumu decyzyjnego. Wsparcie dla managera IT to w praktyce kilka konkretnych mechanizmów:
- regularny dostęp do zewnętrznego konsultanta lub mentora, który nie jest uwikłany w wewnętrzną politykę firmy;
- jasna eskalacja – zdefiniowane z góry, kiedy decyzja idzie wyżej, a kiedy manager ma pełną autonomię;
- przestrzeń na retrospekcję własną, nie tylko zespołową – godzina co dwa tygodnie, żeby manager mógł ocenić własne decyzje bez presji oceny przez przełożonego;
- dostęp do peer grupy innych managerów IT, najlepiej spoza własnej organizacji, gdzie można mówić wprost.
Ten ostatni punkt jest niedoceniany. Managerowie IT, których znam, najchętniej rozmawiają z kimś, kto przeżył podobny projekt, a nie z kimś, kto przeczytał o nim w podręczniku. Peer learning w grupie 6–8 osób z różnych firm daje coś, czego żadne szkolenie ITIL ani certyfikacja SAFe nie zastąpi – perspektywę kogoś, kto nie ma interesu w tym, żebyś wyglądał dobrze albo źle.
Kiedy brak wsparcia staje się problemem organizacji, nie jednostki
Efekt Ringelmanna, opisany jeszcze w 1913 roku, mówi o tym, że wraz z rozrostem grupy zaangażowanie jednostki spada. Dla managerów IT działa to trochę inaczej – im większa organizacja, tym bardziej manager ma wrażenie, że system jakoś sobie poradzi bez jego pełnego zaangażowania. Skoro jest komitet sterujący, jest PMO, jest właściciel produktu i Scrum Master – to po co manager miałby się przemęczać? Problem w tym, że to wrażenie bywa złudne. Koordynacja między tymi rolami i tak spada na managera, zwłaszcza gdy projekt zaczyna się sypać.
Firmy, które traktują wsparcie dla managerów IT jako jednorazowe szkolenie – trzy dni warsztatów raz na rok – zwykle odkrywają problem wtedy, gdy manager albo odchodzi, albo projekt pada. Wsparcie, które działa, jest procesem, nie wydarzeniem. Oznacza to kogoś dostępnego przez kilka miesięcy, kto zna kontekst projektu, zna strukturę zespołu i może powiedzieć wprost, gdy widzi, że manager jedzie po bandzie.
Pytanie, które warto postawić sobie szczerze: kiedy ostatnio ktoś w twojej organizacji zapytał managera IT nie o status projektu, ale o to, czego mu brakuje, żeby ten projekt dowieźć?
Źródła
- DeMarco T., Lister T., “Peopleware: Productive Projects and Teams”, Dorset House, 1987.
- Brooks F.P., “The Mythical Man-Month”, Addison-Wesley, 1975.
- Drucker P., “The Effective Executive”, Harper & Row, 1967.
- Standish Group, “CHAOS Report” – cykliczny raport o wynikach projektów IT, standishgroup.com.
Zdjęcie: Vladimir Srajber / Pexels
