Przy wzroście małej organizacji, która bazuje na tworzonym wewnętrznie rozwiązaniu software’owym zmienia się też rola CTO, który z „głównego programisty” powinien zmienić się w sprawnego menadżera działu IT. Dla wielu osób ten przeskok jest trudny, a najczęściej hamują ich własne przekonania, przywiązanie do technologii jak do ulubionej pluszowej zabawki w dzieciństwie oraz brak świadomości, że ich rola wraz z rozwojem organizacji znacząco się zmieniła.

Taka sytuacja może mieć też miejsce w dużych firmach, gdzie dana osoba jako główny programista / architekt była odpowiedzialna za implementację i rozwój oprogramowania, którego znaczenie w organizacji rośnie, a razem z nim rośnie i zmienia się też zakres odpowiedzialności tej osoby i charakter jej pracy. Zostaje może nie CTO, ale menadżerem kluczowego obszaru w IT, co również będzie nakładać na taką osobę inne wymagania niż dotychczas.

Jest to jeszcze trudniejsze w sytuacjach, gdy organizacja rośnie szybko, bo ich produkt czy usługa „złapała trakcję” rynkową (ze startupowej nowomowy na nasze – „produkt / usługa dobrze się sprzedają”) i na przejście wszystkich faz tej zmiany jest mało czasu, a całość odbywa się w klimacie przypominającym „lądowanie w Normandii”. Żeby uniknąć nieprzyjemnych niespodzianek z tym związanych zapraszam do przestudiowania poniższej listy głównych hamulców ograniczających rozwój zarówno CTO jak i organizacji, w której pracuje.

CV / Hype – driven-development – “zrobimy to w FAJNEJ technologii”

Ale to na Wordpressie mamy to robić?

Jak słyszę Wordpress to od razu wiem, że to się nie uda …

Wordpress to obciach …

To są słowa, które powinny dać do myślenia osobom rekrutującym przyszłego CTO, czy to jest na pewno odpowiedni człowiek na to stanowisko. Nie chodzi tu konkretnie o samego Wordpressa, jednak jest to przykład, który często się powtarza w rzeczywistości. Chodzi o dyskredytowanie technologii, bez jakiejkolwiek analizy potrzeb i sprawdzenia, czy warto wymyślać koło od nowa. Jest co prawda takie niepisane prawo, że każdy programista tworzący aplikacje webowe musi napisać przynajmniej trzy systemy zarządzania treścią (czyli CMS jak np. Wordpress) od zera, ale temu hobby powinien raczej oddawać się w wolnym czasie (chyba, że firma będzie sprzedawała własny CMS).

CTO, dawny główny programista, często też może chcieć „zaktualizować” swoje CV o najnowsze trendy technologiczne. I nie będzie w tym nic zdrożnego tak długo, jak budowanie czegoś nowego, będzie wynikało z potrzeby biznesowej (tzn. dwa cele będą zbieżne).

CTO myślący przez pryzmat fajności technologii, a nie jej użyteczności buduje rzeczy, które lubi, a nie te które są niezbędne. Zamiast rozwiązywać problemy biznesowe czy wspierać biznes w działaniach za pomocą sprawdzonych rozwiązań technologicznych tworzy nowy zestaw problemów za pomocą nowych technologii. Pieniądze i czas są inwestowane nie w te działania, które są niezbędne. Czasami, dla organizacji małych i średnich może to oznaczać katastrofę (przeinwestowanie w technologię w dużych organizacjach oczywiście tez może się zdarzyć, jak np. 1.2 MILIARDA USD w Kmart, które to prawdopodobnie zabiło tę firmę, ale w dużych firmach to często splot jeszcze szeregu innych problemów).

Nieumiejętne zarządzanie ryzykiem

Świeży CTO może mieć problemy z myśleniem o zarządzaniu ryzykiem związanym z budowanymi, czy wdrażanymi technologiami.

Przykład takiego podejścia:

Nie będę robił testów bezpieczeństwa, bo tymi rękami tworzyłem kod, infrastrukturę, etc.

Zazwyczaj wynika to z obawy, że to podważy kompetencje takiego CTO. Jest to metoda obsługi ryzyka na tzw. strusia - dopóki głowę mam w piasku jestem niewidzialny, tzn. dopóki nie zacznę zajmować się problemem / nie uznam czegoś za problem to on nie istnieje.

A później następuje atak - wyciek danych, zaszyfrowanie dysków / ransomware itd. i CTO zaczyna śpiewać głosem Zenka Martyniuka:

jak do tego doszło nie wiem … nie mogę jeść nie mogę spać ….

Podobnie np. z testami wydajności, czy innymi działaniami, które mają szansę wykazać, że wdrożone rozwiązania nie są idealne. Ale tu leży pies pogrzebany - idealne, żadne z nich nie jest. Działania mające na celu to wykazać są jak najbardziej pożądane jako strategia zarządzania ryzykiem (oczywiście, jeśli wykryte problemy są następnie rozwiązywane).

Chyba, że CTO pracuje w organizacji, w której toczy się walka jak w dżungli i każdy czyha na każdego, a najmniejsze potknięcie jest doskonałą okazją do tego, żeby leżącego „jeszcze w nogę uszczypnąć” - na to nie mam recepty, oprócz zabezpieczania poduszki finansowej i uciekania stamtąd w miarę sprawnie.

Zaniedbanie rozwoju zespołu kosztem prac technicznych

Zamiast na rozwoju zespołu nowy CTO skupia się na zadaniach technicznych. To jest częste w sytuacjach, gdy dzisiejszy CTO był zatrudniony jako główny programista (często w okresie tworzenia nowego produktu / firmy), który później organicznie zostaje stanowisko dowodzenia w IT. Ale jak to mówią Amerykanie „stare nawyki szklana pułapka” („old habits die hard”) i odruchowo pierwsze co taki CTO robi, to grzebanie w technologii, zamiast myśleć o tym jak usprawnić pracę całego zespołu. Ten temat szerzej opisałem w artykule o grzechach początkujących managerów (często wyrosłych ze specjalistów).

Niejasne procesy i problemy w komunikacji

Dajmy na to, że taki CTO wdrożył u siebie JIRA i jest szczęśliwy, że tak zwinnie zarządza projektem, czy rozwojem produktów software’owych, bo na wszystko każe wpisywać zgłoszenie i przypisywać do sprintów. Mam dla takiego szczęśliwego CTO złe wiadomości – jeśli nie szkolisz ludzi, z którymi pracujesz (nie mówię tu o zespole programistów / IT, a o biznesie) i nie wyjaśnisz, a w zasadzie nie ustalisz wspólnie zasad tej współpracy to wdrożenie JIRA nic nie pomoże. Co więcej, spowoduje tylko kolejne frustracje, bez rozumienia ew. korzyści.W biznesie często nikt nie rozumie tych story pointów, velocity, sprintów, burndown chartów, sprint i product backlogów i dlaczego ma ich to obchodzić. Biznes będzie widział tylko fakt, że zamiast w mailu musieli wysłać to samo w JIRA, zaznaczyć jakieś pola, których znaczenia nie rozumieją. Czasami jeszcze ktoś na nich nakrzyczy, że oni NIE MAJĄ prawa przypisywać zadań do osób (ale skąd mieli wiedzieć, skoro nikt nie ustalił zasad współpracy w oparciu o narzędzie??) i zaczynają traktować JIRA jak czarną dziurę, do której jak już coś wpadnie, to ginie bez pamięci.

Brak przeglądu rynku

Czasami wystarczy kupić młotek, zamiast zajmować się budową fabryki młotków (szerzej o tym w artykule o problemach komunikacyjnych w IT). To jest częsty problem w myśleniu programistów, którzy WOLĄ budować niż coś wdrożyć. Ale CTO powinien już w którymś momencie przestać tak myśleć. Budowanie przez kodowanie powinno zastąpić budowanie przez wdrażanie sensownych rozwiązań – sensownych, czyli w uproszczeniu takich pasujących do architektury, w sensownym koszcie rozwiązującym problem biznesowy. Do tego wymagana jest jednak znajomość rozwiązań dostępnych na rynku. Znajomość rynku pozwoli również na proponowanie potencjalnych usprawnień, czy definiowania nowych produktów i usług bazujących na dostępnych na rynku rozwiązaniach.

Braki w umiejętnościach rekrutacyjnych

Wszyscy są za słabi, bo praktycznie nie czytają w myślach i nie rozwiązują problemów zgodnie z tym, co w głowie takiego CTO powstało (to jak w szkole – jest wiele rozwiązań, ale jak nie wpiszesz się w schemat, to kaplica). CTO nie może zatrudnić nikogo z doświadczeniem, bo boi się o swoją pozycję. Nie potrafi zatrudnić nikogo młodego, bo nie patrzy na potencjał, tylko na to co dana osoba potrafi tu i teraz (a często jest to niewiele) i nie chce brać dodatkowych obowiązków związanych z uczeniem nowej osoby. Jest to zadanie średnioterminowe, a zestresowany CTO potrzebuje zmian (pomocy) na teraz i kółko się zamyka.

Do czego to prowadzi, czyli jak IT pod wodzą niedoświadczonego CTO staje się TYM ZŁYM

Konsekwencje postawy opisanej powyżej są zazwyczaj takie, że IT staje się „chłopcem do bicia”. Jak coś nie idzie w firmie, to jest w IT „znowu bez czapki chodzą” i jest pretekst, żeby na nich wylać swoje żale. Niestety jest to przynajmniej w połowie zasłużone, ze względu na podejście nieadekwatne w danym momencie do realizacji obowiązków CTO. Finał jest taki, że jest to deprymujące zarówno dla użytkowników biznesowych („o boże, znowu muszę iść do IT po coś, od razu mi się nie chce tego robić”), jak i dla samego CTO, czy też szerzej działu IT („znowu coś od nas chcą, a my jeszcze siedzimy nad zadaniami sprzed 2 miesięcy”).

CTO z zespołem zajmują się nie tym co trzeba, nie ma czasu na kluczowe sprawy

Programiści i szerzej IT jest zapchane robotą, bo wzięli się za nową, nieznaną (im) technologię podążając za potrzebą efektu nowości; No i problem jest taki, że eksplorują ją na miarę swoich możliwości. Jeśli jest to coś zupełnie świeżego na rynku, to mało jest na ten temat materiałów (dokumentacji, czy odpowiedzi na forach).

Dla organizacji często takie podejście jest obarczone dużym ryzykiem – dłuższy czas dostarczenia, potencjalnie więcej błędów (wynikających z tego, że technologia nie jest jeszcze „wygrzana”). Więc jeśli firma NIE jest budowana na tym, że wymyśla jakąś technologię, to lepiej będzie bazować na znanych i sprawdzonych rozwiązaniach, a nie czekać aż CTO z ekipą nowinki przyswoją i na ich podstawie rozwiązanie zbudują.

CTO i zespół jest przeładowany, nie ma czasu myśleć strategicznie

Jeśli w IT zasuwają tak, że nie ma kiedy taczki załadować, to zazwyczaj wiąże się to z brakiem refleksji na temat tego, czy płyniemy w dobrym kierunku i czy te wysiłki służą nadrzędnemu celowi biznesowemu. Wygląda to tak, że CTO i zespół są cały czas czymś zajęci, ale nie przekłada się to na zbliżanie się realizacji strategii organizacji. To tak, jak byśmy zostali wyrzuceni z łodzi i mieli dopłynąć do plaży, która jest w zasięgu wzroku. Wkładamy dużo wysiłku w machanie kończynami, jednak nie przekłada się to na zmniejszenie dystansu do brzegu – wszystko dlatego, że taplamy się w wodzie, zamiast nasze wysiłki odpowiednio ukierunkować.

Brakuje rąk do pracy

Brak skupienia na rozwoju zespołu – zarówno pod względem kompetencji jak i liczebności sprawia, że dużo rzeczy jest na głowie CTO. „Nie mam czasu na rekrutację, muszę gasić pożary, niech HRy mi kogoś znajdą – podeślę wymagania.” Wymagania się kończą na dwóch zdaniach, a później są spotkania z zupełnie nietrafionymi kandydatami i gorzkie żale, że HRy nie robią swojej roboty i nie ma kim robić. Błędne koło wzajemnych oskarżeń rozpędza się coraz bardziej, a zagadnienie podstawowe – rozwój zespołu, pozostaje nie ruszone.

Rozwój tzw. Shadow IT

Shadow IT to sytuacja, w której działy biznesowe, bez współpracy i często bez wiedzy własnego działu IT wdrażają rozwiązania technologiczne na potrzeby obsługi swoich procesów.

Im takich procesów obsługiwanych niezależnie od IT jest więcej, im więcej kupowanych niezależnie rozwiązań, tym częściej prowadzi to do zatrudniania dedykowanych osób w dziale biznesowym do pracy de facto w IT, tworząc równoległy dział IT. To częstsze zjawisko w dużych organizacjach, ale w małych i średnich też będzie tak, że np. dział marketingu czy sprzedaży na własną rękę będzie rozwijał i wykorzystywał narzędzia technologiczne.

Na krótką metę rozwiązuje to problemy, na dłuższą może sprawiać, że jeśli w którymś momencie własne rozwiązania organizacji (te zbudowane, wdrożone przez IT) będą miały rozmawiać z tymi kupowanymi na zewnątrz to może się okazać, że koszty tego są duże, a i opór działu IT / CTO będzie spory (taki po prostu ludzki, że dana osoba została pominięta w decyzjach, które w teorii są w jej kompetencjach).

Czasami takie zewnętrzne rozwiązania mogą nie być poprawnie analizowane pod kątem bezpieczeństwa, czy spełniania określonych wymogów (np. backupy danych), co finalnie może doprowadzić do sporych problemów, gdy dojdzie do utraty danych lub ich wycieku z zewnętrznego systemu.

Co może zrobić organizacja, żeby wspomóc takiego CTO?

Jeśli są problemy we współpracy z CTO, czy szerzej działem IT i IT staje się wąskim gardłem, to najprawdopodobniej bez współpracy z innymi działami / osobami w firmie problemy się nie rozwiążą. Inne działy mogą się wspomagać osobami takimi jak analityk biznesowy, który pomoże rozwiązać część problemów procesowo, zamiast od razu rzucać się na implementację w oprogramowaniu (czasami Excel wystarczy), ale to tylko jeden z elementów układanki.

Nie obejdzie się prawdopodobnie bez kilku uczciwych „sesji nienawiści”, tudzież "godzin szczerości", gdzie problemy zostaną uczciwie (acz bez uszczypliwości) wyłożone i spisane. Następne w kolejności jest zaplanowanie taktyki na krótki okres i strategii na dłuższy, żeby poukładać współpracę pomiędzy działem IT, a resztą organizacji. Jest to szczególnie ważne w firmach, których praca opiera się o sprawne działanie ich rozwiązań IT, albo jeszcze ważniejsze, gdy oprogramowanie jest produktem / platformą, z której korzystają zarówno klienci jak i pracownicy firmy i jest w zasadzie centralnym narzędziem umożliwiającym firmie działanie (np. e-commerce, e-learning, etc.).

Dosypywanie więcej „gruzu na pakę” CTO i działowi IT rzadko pomaga, skoro już ledwo ciągną (jeżeli od Melexa oczekujemy ładowności i mocy Kamaza, to sami rozumiecie, że trzeba oczekiwania przeskalować). Jeśli nie będzie przestrzeni (czasu, finansów) na myślenie strategiczne, zaplanowanie w jakimkolwiek horyzoncie prac, wprowadzenia nowych członków do zespołu, to raczej nic się nie poprawi.

Na pewno konieczne są też szkolenia typowo managerskie dla takiej osoby, żeby wskazać obszary, w których powinna rozwijać swoje kompetencje i dać narzędzia do prawidłowej realizacji zadań w nowej rzeczywistości (można też zgłosić się do mnie, to wyjaśnię co i jak -> moje namiary).

W takich sytuacjach niezbędna jest też refleksja w organizacji i CTO, czy to jest robota dla niej/niego? Nie każdy specjalista będzie dobrym managerem, nie wszystkim przejście z jednego trybu w drugi musi odpowiadać – osobowościowo, czy też zakresem obowiązków. To już jest najtrudniejsza przeprawa, zwłaszcza jeśli np. taki CTO jest mocno związany z firmą, bo budował ją od podstaw, a być może dodatkowo jest jeszcze jej współwłaścicielem.