Jeśli menedżer jest mądry, zacznie siedzieć nad książkami, układać relacje z inżynierami i budować zaufanie do siebie. Ale jeśli nie, to - kierując się doświadczeniem z poprzedniego miejsca pracy - postanawia "dokręcić śrubę". W miejsce zbyt luźnego zarządzania pojawia się zarządzanie zbyt sztywne: eskalacje, środki dyscyplinarne, zostawanie po godzinach. Wzrasta poziom napięcia w organizacji, "siada" atmosfera, aż wreszcie - w aspekcie dalszych niepowodzeń menedżera - pojawia się kryzys: odejście grupy kluczowych osób do konkurencji, kolejny niedotrzymany termin, generalny upadek morale. A zarząd po raz kolejny przekonuje się, że zarządzanie IT nie jest tak bardzo podobne do tego, co można przeczytać w książkach.

Superprogramista na równi pochyłej

W każdym zespole informatyków znajdzie się tzw. superprogramista. Czasami oczywiście wcale nie jest to programista, a np. administrator czy grafik. Pracuje szybciej i wydajniej niż ktokolwiek inny, produkty wychodzące spod jego ręki zawsze są lepszej jakości; rzadko przekracza terminy, do dotrzymania których się zobowiązał, itd.

Oczywiście każdy chciałby mieć go w swoim projekcie, bo nawet sama jego obecność zwiększa szansę sukcesu. Superprogramista pracuje więc coraz więcej. Stopniowo zaczyna zostawać po godzinach, a z jego twarzy znika życzliwy uśmiech, a pojawia się wyraz zniecierpliwienia. Raz i drugi fuknie na kogoś, kto prosi go o pomoc; zaczyna odprawiać z kwitkiem osoby, które chciały go zaangażować. W jego programach pojawiają się błędy, niezrozumiałe ograniczenia funkcjonalne. A co najgorsze - superprogramista przestaje dotrzymywać terminów.

Jeśli w porę nie zatrzyma się tego schematu, wkrótce superprogramista przekształci się we wroga publicznego numer jeden. Niechby nawet dalej pracował lepiej i wydajniej niż inni, ale nikt nie będzie porównywał go do "innych", tylko do niego samego sprzed paru miesięcy, gdy jeszcze był prawdziwym superprogramistą.

Poprawiacze strzelają w kolano

Działy informatyki obfitują w ludzi, którzy najlepiej pracują, kiedy ich nie widać i o nich nie słychać. Klasycznym przykładem są administratorzy. W dużej organizacji, posiadającej własny help desk, nie uczestniczą bezpośrednio w obsłudze użytkowników. Nie kontaktują się bezpośrednio z użytkownikami. Co więc robią? Mnóstwo potrzebnych rzeczy: konfigurują system, aplikują "łatki" bezpieczeństwa, obserwują monitoring, nieustannie weryfikują bezpieczeństwo systemów, itd.

Kiedy firma zaczyna tzw. optymalizację kosztów, z reguły pierwsze, co wdraża, to narzędzia pozwalające zobaczyć, gdzie koszty powstają, a co przynosi biznesowi wartość. A ponieważ ich wdrażaniem zajmują się tzw. renomowane firmy konsultingowe zaludniane przez ekonomistów, za "przynoszące wartość" zostają uznane wyłącznie działania na tzw. front office. IT zostaje potraktowane jako centrum kosztów, a nikomu nie chce się wnikać w terminy, takie jak "optymalizacja wydajności platformy middleware" albo "stress-testy bazy danych za pomocą robota". I zawsze jakoś tak się składa, że lwią część kosztów podlegających optymalizacji generują administratorzy, korzystając z drogiego sprzętu, licencji oraz usług. Pojawia się więc tendencja, aby te koszty "restrukturyzować", czyli - mówiąc krótko - radykalnie zmniejszyć. A ponieważ nie ma szybkiego i bezpośredniego przełożenia pomiędzy liczbą etatów, jakością narzędzi monitoringu, częstotliwością "łatania" systemów oraz zapasami mocy w infrastrukturze a ową mityczną "wartością biznesową", oszczędności są znaczne. Optymalizacja kosztów przynosi nadspodziewane korzyści, konsultanci odjeżdżają, żegnani wylewnymi podziękowaniami oraz słoną fakturą, zapłaconą bez dyskusji.