Problemy z menedżerskim ABC

Wielu menedżerów IT, w tym CIO, rozpoczynało karierę od stanowisk „technicznych” – są programistami, administratorami, specjalistami od baz danych. Awansują, bo wykazali się dobrymi wynikami w pracy. Inny wykazali pewne cechy, które spowodowały, że z pozycji wykonawców przeszli do pozycji menedżerów – osób zarządzających wykonawcami.

Nie ma w tym oczywiście nic zdrożnego. Trzeba jednak pamiętać, że czym innym jest praca inżyniera – programisty, administratora, sieciowca itp. – a czym innym menedżera. Wymagane są inne umiejętności, postawy i zachowania. To, co wcześniej przyczyniło się do naszego sukcesu w roli specjalisty od baz danych (np. głęboka wiedza dot. technicznych aspektów tematu, czy umiejętność prowadzenia długotrwałych analiz w celu znalezienia rozwiązania dla problemu) niekoniecznie sprawdzi się gdy zaczynamy pełnić rolę osoby zarządzającej zespołem ludzi.

Wielu menedżerów IT nie zauważa tego, że zmienił się charakter ich pracy i musi zmienić się też ich ABC – Attitudes, Behaviours & Communication – czyli postawy, zachowania i sposób komunikacji. Bazując na własnych obserwacjach, rozmowach, współpracy z licznym gronem menedżerów, rozmowach z osobami zaineresowanymi tematem pokusiłem się o określenie kilku „grzechów”, jakie popełniają menedżerowie IT w obszarze ABC.

Kształcenie informatyków w Polsce ma niestety od wielu lat pewne braki. O ile nasze uczelnie dobrze przygotowują ich od strony wiedzy technicznej czy metodologicznej, o tyle bardzo kiepsko robią to – o ile w ogóle – od strony umiejętności miękkich. Technik/inżynier, który świetnie „dogaduje się” z kodem programu czy ustawieniami sieciowego routera – awansowany na menedżera zespołu IT – bardzo często ma problemy w komunikacji z ludźmi.

Potwierdzają to przeprowadzone kilka lat temu badania, które zbierały m.in. informacje o cechach deficytowych wśród pracowników IT („Raport z badania Zapotrzebowanie pracodawców na tzw. kompetencje miękkie absolwentów kierunków ścisłych”, Uniwersytet Mikołaja Kopernika, 2013). Pokazały one, że najwięcej problemów w IT mamy z komunikatywnością, asertywnością i orientacją na potrzeby klienta. O ile braki te w mniejszym stopniu przeszkadzają specjalistom IT, którzy nie mają kontaktów z odbiorcami ich działań, to niestety są częstymi problemami dla menedżerów IT. Próbują oni używać z całym otoczeniem takiego samego języka komunikacji, jak ze swoim zespołem.

Z życia: W firmie dostarczającej rozwiązania IT menedżer jednego z zespołów 3 lata z rzędu otrzymywał bardzo słabe oceny ze strony przełożonych i partnerów biznesowych, a rewelacyjne ze strony zespołu, którym kierował. Badanie było anonimowe i przeprowadzone w sposób, który minimalizował możliwość manipulacji przez np. wywieranie wpływu na pracowników. Przeprowadzona przez doświadczonego doradcę analiza pokazała, że powodami takiej różnicy były pewne zachowania i nieumiejętność komunikowania się tego menedżera z osobami spoza zespołu. Używane słownictwo, zwroty, zachowanie, które były akceptowalne w ramach zespołu – z którego ten menedżer resztą się wywodził – były niezrozumiałe lub źle odbierane przez przełożonych i partnerów. Uświadomienie sobie tego przez menedżera, odkrycie potrzeb i oczekiwań osób spoza zespołu, coachingowe wsparcie w wypracowaniu odpowiedniej komunikacji i postawy spowodowały, że z jednej strony wzrosły oceny menedżera, a z drugiej był on w stanie skuteczniej reprezentować potrzeby swojego zespołu. Zmniejszyła się też jego frustracja spowodowana wcześniejszym brakiem porozumienia.

Związana jest ona ze składaniem nadmiernych obietnic czy przyjmowaniem zbyt wielu zobowiązań, czy to kierowanych z wyższych szczebli organizacji, czy też od klientów lub partnerów, na których nam zależy. Z pozoru grzech ten brzmi dziwnie. Dlaczego mamy nie podejmować zobowiązań, nie dostarczać rzeczy, których od nas oczekują? Oczywiście powinniśmy to robić, ale w sposób spójny z dostępnością zasobów, które do tych nowych zadań możemy oddelegować. Tymczasem często za obietnicami realizacji nie idzie wskazywanie konsekwencji. Przyjęcie dodatkowego zadania oznacza niemożliwość dowiezienia w wyznaczonym czasie innych, zwiększenie kosztów funkcjonowania jakiegoś obszaru IT czy frustracje ludzi, którzy muszą siedzieć po godzinach, aby dowieźć „zobowiązanie szefa”. Rezultatem może być utrata jednej z najważniejszych wartości menedżera, czyli przewidywalności. Jeśli coś obiecałem – muszę to dowieźć. Jeśli nie jestem w stanie czegoś zrobić – muszę odmówić. Inne zachowania oznaczają pogorszenie naszej wiarygodności wśród partnerów i utratę zaufania wśród pracowników, gdyż nie będą mieli pewności, czego się mogą po nas spodziewać.

Jedynym rozsądnym wyjściem jest, z jednej strony bieżąca wiedza, czym zajmuje się nasz zespół, co i kiedy będzie w stanie zrobić. Z drugiej – w przypadku otrzymania „zlecenia, a nie do odrzucenia” – wykazanie się asertywnością, np. poprzez pokazanie CEO czy CIO jaki będzie wpływ dodatkowej pracy na różne aspekty tego, za co jesteśmy odpowiedzialni. Możemy zaproponować wstrzymanie realizacji jakiś zadań (w porozumieniu z ich zleceniodawcami) czy zaangażowanie dodatkowych zasobów. Im bardziej wiarygodni będziemy w oczach naszych rozmówców (patrz poprzedni akapit) tym bardziej skłonni będą oni nas wesprzeć, pomagając w zatrzymaniu innych prac czy pozyskując środki na dodatkowe działania. Swoją drogą asertywność pojawiła się jako kolejna cecha deficytowa wśród pracowników IT we wspomnianym wcześniej badaniu.

Z życia: W pewnej korporacji co roku pracownicy działów biznesowych – korzystający z usług IT – oceniali pracę różnych szczebli menedżerów IT, z którymi najczęściej współpracowali. Ku zdziwieniu kierownictwa IT najlepsze oceny miał menedżer, który najczęściej odmawiał przyjmowania zleceń. Z rozmów z uczestnikami ankiety wyniknęło, że był on najbardziej wiarygodny dla swoich partnerów. Jeśli obiecał, że dostarczy rozwiązanie, to tak się działo. Jeśli mówił, że nie jest w stanie tego wykonać w oczekiwanym terminie – to z powodu swojej solidności w dostarczaniu rozwiązań – był wiarygodny bardziej niż osoby, które dużo obiecały, ale miały równie dużo opóźnień w realizacji zadań.

Perfekcjonizm jest częstą cechą inżynierów, nie tylko w obszarze IT. Jest to zrozumiałe, gdyż dokładność, przewidzenia i zapobieżenia ryzykom – czy też maksymalne dopracowanie oferowanych rozwiązań na stanowiskach wykonawczych – są pożądanymi cechami. Jednak nie do końca są one pożądane na stanowisku menedżerskim. Od menedżera IT często oczekuje się obecnie elastyczności, szybkiego podejmowania decyzji czy dostarczania informacji. Mniej ważna jest umiejętność dogłębnej analizy i dostarczania „na 100% przebadanych danych” (oczywiście poza specyficznymi wyjątkami) niż zdolność do oszacowania wycen, czasu czy zakresu pracy, obarczona z definicji jakimś błędem, ale pozwalająca na dokonywanie szybszych decyzji biznesowych.

Z drugiej strony, dla podwładnych menedżera IT istotne jest posiadanie pewnej przestrzeni na popełnianie błędów. Zespół będzie lepiej pracował, jeśli ma świadomość, że drobne, pojedyncze błędy, nie wynikające z zaniedbań czy umyślnych działań, nie będą powodem do „sądu nad winnym”. Nie należy ich oczywiście ignorować, ale wykorzystać do nauki – swojej i pracowników – do wyciągnięcia wniosków, a nie konsekwencji, do poproszenia winnych np. o wprowadzenie zmian w procesie, które zapobiegną powtórnym, podobnym błędom.

Z życia: W trakcie procesu rekrutacji na stanowisko menedżerskie w znanej sieci księgarni jedno z zadań polegało na podaniu liczby kostek, z których zbudowana była konstrukcja narysowana w rzucie izometrycznym. Na rysunku nie było widać kostek „z tyłu” – nie było wiadomo, ile ich może być. Jeden z rekrutowanych, którzy dotarli do kolejnego etapu zapytał, co było celem tego zadania. Bo przecież nikt nie był w stanie podać rzeczywistej liczby kostek. W odpowiedzi usłyszał, że „Dokładnie liczyć to musi magazynier, bo tego od niego wymagamy, a od menedżerów oczekujemy szybkiego oszacowania sytuacji i podejmowania decyzji na takiej podstawie.”.

Jedno ze znanych mi korporacyjnych przysłów mówi, że „Niektórym rybom lepiej się pływa w mętnej wodzie”. W przełożeniu na rzeczywistość działania zespołów IT oznacza to, że niektórzy dobrze czują się w środowisku, w którym nie wszystko jest jasne, widoczne, wyjaśnione czy pokazane. Cechą widoczną niektórych menedżerów IT jest to, że nie lubią pokazywać, czym się zajmują, jakie mają dalsze plany działania, jak wygląda stopień zaangażowania zasobów, którymi zarządzają, ich dostępność czy kompetencje.

Brak transparentności może ukrywać braki w kompetencjach czy błędy, które tego typu menedżerowie popełniają w zarządzaniu zespołem. Jednocześnie nie ujawnianie tego, że dana osoba może sobie nie radzić w zarządzaniu zespołem powoduje, że nie otrzymuje we właściwym czasie pomocy. Tak, jak nie każdy rodzi się z buławą w plecaku, tak nie każdy jest urodzonym liderem. Wiedząc, jakie dana osoba ma braki, możemy ją wesprzeć doradztwem czy mentoringiem z dobrym efektem dla niej, bo przestanie się stresować, że popełnia błędy.

Z życia: W jednej z organizacji, które chciały wdrożyć zwinne podejście do zarządzania dostarczaniem produktów technologicznych, problemem okazała się nie niechęć do zmiany jako takiej czy brak doświadczenia w nowym podejściu do pracy, ale potrzeba ujawnienia przez menedżerów, jakimi zasobami dysponują – od strony kompetencji, dostępności, zakresu zadań, które w danej chwili wykonywali. W efekcie etap przejścia do nowego sposobu zarządzania był hamowany do czasu, aż udało się przekonać kilkoro z nich do zmiany podejścia, a z tymi, z którymi się nie udało tego zrobić, firma się rozstała.

Powyższe historie nie wyczerpują niestety listy „grzechów”, a raczej braków umiejętności menedżerów IT. Zapewne każdy z nas byłby w stanie podać jeszcze kilka obszarów i związanych z nimi przykładów niewłaściwych postaw, zachowań, złej komunikacji. Nie jest bynajmniej moim zadaniem wypominanie komukolwiek jego zachowania. Moim celem jest wskazanie, jak nas widzą nasi partnerzy biznesowi i przełożeni. Chcę wskazać, na co trzeba zwrócić uwagę, w jakich obszarach zdobywać doświadczenie, czego się uczyć i o czym rozmawiać z dobrymi, doświadczonymi menedżerami IT…

…okazją do tego będzie udział w konferencji Let’s Manage IT 2016, która odbędzie się w dniach 2-3 czerwca 2016 roku w Gdyni. Wśród wielu gości, którzy podzielą się własnym doświadczeniem w rozwoju umiejętności menedżerów IT, będzie m.in. Paul Wilkinson – doświadczony trener i doradca, wspierający rozwój umiejętności miękkich menedżerów i zespołów IT. Więcej na stronie http://konferencja.letsmanageit.pl

Jarosław Łojewski – doradca, coach i trener, zajmuje się wsparciem w rozwoju umiejętności miękkich wśród specjalistów i menedżerów IT. Korzysta m.in. z 10-letniego doświadczenia pracy w roli Business Relationship Managera w międzynarodowej korporacji, w której to odpowiadał m.in. za budowanie relacji i komunikację między IT i częścią biznesową firmy. Przeszedł ścieżkę kariery od programisty do dyrektora departamentu w dziale IT.