Czy potrzebujesz CTO do zarządzania swoim Zespołem IT? 9 pytań, które pomogą urealnić tę potrzebę.

Cześć, dzień dobry.

Witam was w podcastzie IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce.

Podcast IT i Biznes kieruje do właścicieli firm oraz menedżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek 14. Czy potrzebujesz CTO do zarządzania swoim zespołem IT? 9 pytań, które pomogą urealnić te potrzeby.

Czym właściwie jest CTO?

Realizacja różnych przedsięwzięć na styku IT i biznesu to często niełatwa sztuka. Trzeba pogodzić nagłe potrzeby biznesowe, plany długoterminowe, rentowność tej inwestycji, sprawy technologiczne, zarządzanie problemami pojawiającymi się ad hoc, czy też wyzwaniami HR-owymi związanymi z zespołami technicznymi oraz nietechnicznymi, a także często też rywalizacją między różnymi działami w firmie oraz ich priorytetami. W nawiązaniu do wskazanych rzeczy w dzisiejszym odcinku opowiem o tym, kim jest CTO, jaką pełni on rolę w organizacji, w czym powinien wspierać CTO firmę i zespoły, a także zadam 9 pytań, które wskażą różne problemy, które chce się rozwiązywać poprzez zatrudnienie CTO, a które da się często rozwiązać w inny sposób warty rozważania.

Zatem nie przedłużając, serdecznie zapraszam do odsłuchania dzisiejszego odcinka. Cześć, dzień dobry. Rozpoczynamy odcinek, w którym przyjdzie mi się zmierzyć z pytaniem, czy potrzebujesz CTO do zarządzania swoim zespołem IT.

Odpowiedź na to pytanie brzmi, to zależy od tego, jak bardzo wyczerpałeś, wyczerpałaś już inne możliwości organizacyjne. Wiem, trochę brzmi enigmatycznie, ale zacznijmy od początku. Kim jest CTO? CTO to skrót od Chief Technology Officer, czyli szef działu technicznego, technologicznego.

Kiedy zatrudniamy szefa sprzedaży, czy marketingu, ma on zarządzać zespołem, który będzie dowoził sprzedaż, bądź lidy, w dużym uproszczeniu. Podobnie jest z CTO. Zatrudniamy go wtedy, kiedy chcemy, aby zarządzał on zespołem IT, który będzie dowoził Twoje projekty realizowane in-house.

Czasami zatrudnia się też CTO w ogóle na starcie budowy zespołu, aby wspomógł on działania rekrutacyjne i poukładał cały proces wytwarzania oprogramowania. Wtedy pełni on też rolę analityka, czy product ownera na wczesnym etapie. Czasem też pełni rolę wsparcia HR-u, więc też to się zdarza.

Zdarza się, że mylnie podchodzi się do tematu tak, że zatrudnia się CTO, który będzie pełnił niejaką rolę organizatora prac projektowych, testera projektu, lidera technicznego. Jednocześnie czasami taka osoba też programuje, ale nie przekłada się to efektywnie na wykorzystanie czasu tej osoby. Ale nie przekłada się to na efektywne wykorzystanie czasu tej osoby, który to czas raczej nie należy do najtańszych, z uwagi na to, że CTO na dziś w Polsce jest naprawdę mało.

Rola i odpowiedzialność CTO w firmie

CTO z mojej perspektywy to osoba, która musi bardzo dobrze rozumieć kwestie biznesowe, rozumieć bardzo dobrze kwestie techniczne i umieć ze sobą te dwa światy połączyć. Po pierwsze poprzez dobrą organizację procesu komunikacji i realizacji zadań dla zespołu oraz biznesu. Po drugie poprzez zadbanie o urealnianie na bieżąco obu stron.

Po trzecie poprzez pomoc w planowaniu strategicznym, a także w ustaleniu co warto robić in-house, a co można zlecić na zewnątrz. I po czwarte powinien pomóc w ugaszaniu najtrudniejszych sytuacji, kiedy jedna ze stron się zatnie, w cudzysłowie zatnie. Co mam na myśli poprzez zacięcie się jednej ze stron? Chodzi o moment, kiedy zespół techniczny mówi, że się czegoś nie da zrobić, albo będzie to bardzo czasochłonne, albo o moment, kiedy ktoś z biznesu mówi, że coś jest potrzebne na za dwa, trzy dni, albo na wczoraj i trzeba wypracować kompromis, co się da w takim czasie zrobić i będzie spełniało też oczekiwania biznesowe, a co można zrobić jako doszlifowanie później.

W tego typu sytuacjach w zespole może brakować tej takiej trzeciej strony, takiego mostu między właśnie biznesem, a zespołem technicznym, która właśnie będzie takim łącznikiem i to właśnie powinna być jedna z ról CTO. Skoro już wiemy, kim ten CTO jest i jaką powinien wspierać firmę, zadajmy sobie dziewięć pytań, czy przedstawmy dziewięć sytuacji, które urealnią nam potrzebę zatrudnienia takiej osoby. Bo z mojego doświadczenia wynika, że w firmach często pomysł pojawienia się CTO czy pomysł zatrudnienia CTO wynika trochę z potrzeby chwili, czyli właśnie są różne sytuacje, które powodują, że taka pierwsza myśl albo pierwsza sugestia też różnych agencji rekrutacyjnych to jest, masz jakiś problem z zespołem IT, z jego zarządzaniem, z czymkolwiek, zatrudnij CTO.

Ale chciałbym tutaj pokazać też alternatywną drogę, to znaczy to, że jeżeli skupimy się dużo bardziej na tym problemie, jaki mamy do rozwiązania, albo na sytuacji przede wszystkim, którą mamy w swojej konkretnej firmie, to być może tutaj okaże się, że to wcale nie CTO jest rozwiązaniem naszych wszystkich problemów, tylko być może potrzeba nam innej osoby. No i teraz właśnie jakiej osoby, to o tym sobie opowiemy w kontekście danej sytuacji, danego pytania.

9 sytuacji - kiedy faktycznie potrzebujesz CTO (lub nie)

1. Chcę przejść z Software House’u na zespół wewnętrzny

No i pytanie pierwsze, czy sytuacja numer jeden, to chcę przejść ze współpracy z Software House’em na zespół zewnętrzny,czy powinienem zacząć od zatrudnienia CTO? Czyli to jest taki przypadek, kiedy współpracujesz długoterminowo z Software House’em, masz zespół, z którym prowadzisz bieżącą współpracę, no ale z jakiegoś powodu chcesz przejść na współpracę z zespołem wewnętrznym.

Czyli chcesz zakończyć współpracę z Software House’em i zacząć współpracę ze swoim zespołem wewnętrznym. Teraz pytanie, czy powinieneś zacząć od zatrudnienia CTO? Tak naprawdę na początek powinieneś, powinnaś się zastanowić na tym etapie, dlaczego, jaki jest powód przejścia ze współpracy z Software House’em na zespół wewnętrzny i według tego powodu tak naprawdę zastanowić się, jak też będzie wyglądał proces, plan takiego przejścia, jak sobie to wyobrażasz. No bo inaczej ten proces będzie przebiegał, będzie bardziej krótki, jeżeli już teraz jesteś na przykład niezadowolony, niezadowolona ze współpracy z Software House’em, no i chcesz po prostu z tej współpracy zrezygnować, nie chcesz już ufać Software House’om, chcesz po prostu zbudować zespół wewnętrzny, czujesz, że dla twojej organizacji to będzie efektywnie lepsze, no to ten proces będzie na pewno bardziej krótkoterminowy niż proces, gdzie chcesz przejść na współpracę z zespołem wewnętrznym, ale współpraca z Software House’em się układa, powody to twoje, dlaczego jest zupełnie inne.

Wtedy na pewno warto ten proces wydłużyć, zrobić go bardziej na spokojnie, no i też według tego należy się zastanowić, czy CTO tutaj jest potrzebny. Jeżeli nie masz wizji tego przejścia, tego jak to powinno wyglądać i nie przychodzi ci ona do głowy w ciągu pierwszych pięciu minut myślenia na ten temat, to tutaj faktycznie mógłby ci pomóc CTO, ale może ci też pomóc po prostu doświadczony programista, tak zwany Tech Lead, czyli osoba, która zarządzała do tej pory zespołem programistów, typowo od tej strony technicznej i być może takiej osoby tutaj potrzebujesz. Teraz w sytuacji, w której już współpracujesz z Software House’em, no i chcesz ten zespół wewnętrzny budować na spokojnie, to ja budowę tego zespołu zacząłbym na początek od zatrudnienia Product Owner’a, u ciebie in-house, czyli u ciebie wewnętrznie.

Ta osoba, ten Product Owner powinna na dzień dobry zdjąć z ciebie kwestię przekazywania zadań do firmy programistycznej, co już spowoduje odblokowanie ci czasu. Powinna też przejąć od ciebie taką bieżącą komunikację, potwierdzanie postępów, odbiory zadań w stronę takiej biznesowo-funkcjonalnej. Czyli to powinna być osoba, która będzie łącznikiem między twoimi wizjami, potrzebami, a firmą programistyczną.

I do tego, będąc na tym etapie, że chcesz mieć ten zespół wewnętrzny, zatrudniłbym też programistę, który docelowo miałby pełnić rolę Tech Lead’a, no i ten programista mógłby już zacząć programować zadania z zespołem Software House’u i powoli też przejmować wiedzę techniczną o projekcie. I dzięki takiemu połączeniu masz z jednej strony Product Owner’a, który zaczyna już ci odblokowywać czas, masz programistę, który już zaczyna zdobywać wiedzę o projekcie i długoterminowo przejmujesz sobie utrzymanie i rozwój tego projektu na swój zespół wewnętrzny, którego to zalążek zespołu już masz. I ten zespół już od samego początku jest efektywny, bo masz programistę, który faktycznie realizuje na przykład jakieś nowe feature’y albo coś organizuje w projekcie, dzięki czemu on już zbiera doświadczenia i już zaczyna być tą osobą z twojej firmy, która zaczyna też ten proces lepiej rozumieć ze strony technicznej.

Z drugiej strony masz Product Owner’a, który też już pokrywa taką z reguły największą bolączkę we współpracy z Software House’em, czyli po prostu jest osobą, która u ciebie w firmie za tą współpracę odpowiada, a docelowo ten Product Owner będzie współpracował już z tym zespołem wewnętrznym. W tego typu sytuacjach agencje rekrutacyjne z reguły doradzają właśnie zatrudnienie CTO jako pierwszej takiej osoby technicznej, no ale warto się nad tym zastanowić, tutaj jeszcze raz podkreślam, jakie są twoje główne bolączki obecnej współpracy z tym obecnym Software House’em i tutaj rozwiązanie tych bolączek, zanim zdecydujesz się zatrudnić CTO. To jest na pewno taka pierwsza rzecz.

2. Nie umiem się dogadać z moimi programistami w zespole in-house

Teraz druga sytuacja. Nie umiem się dogadać z moimi programistami w zespole in-house, czy powinienem zatrudnić CTO. I teraz, jeżeli przekazujesz swoje potrzeby biznesowe bezpośrednio do swoich programistów, czyli twój zespół IT składa się głównie bądź tylko z programistów, to trzeba na pewno pomyśleć o kimś, kto będzie takim pośrednikiem, czy będzie właśnie tym Product Ownerem, czy analitykiem, który twoje wizje biznesowe będzie przekazywał na zespół techniczny, czyli ma to służyć temu, że ty swoje wizje i potrzeby biznesowe przekazujesz tej osobie bardziej w formie krótkiej notatki, krótkiej rozmowy, natomiast to ta osoba zastanawia się, jak coś powinno wyglądać dokładnie, i rozpisuje to zespołowi na zadania techniczne.

Jest takim buforem między tobą, a zespołem technicznym. I tutaj bardzo ważne jest to, żeby taka osoba była, więc jeżeli jej nie ma, na pewno warto o niej pomyśleć. Jeżeli już masz Product Ownera, ale nie umiesz się dogadać z programistami co do na przykład terminów, to może być jeszcze kwestia albo rozszerzenia zakresu obowiązków tej osoby o bycie Project Managerem, jeżeli ma ku temu też kompetencje, lub po prostu zatrudnienia Project Managera, który będzie organizował priorytety zadania, organizował listę zadań dla programistów na przykład na dany dzień, czy na dany tydzień.

Tutaj też warto się nad tym zastanowić. Jeżeli się nie umiesz dogadać z kolei z programistami w kwestiach technicznych, czyli programiści przychodzą do ciebie, mówią, że mogą coś zrobić, ale to wymaga zmiany w jakiejś NC, zrobienia jakiegoś repozytorium i jakichś różnych rzeczy, o których kompletnie nie masz pojęcia, czyli są to takie kwestie typowo, typowo techniczne, to możesz zawsze, to jest najprostsza metoda, poprosić kogoś z zespołu, kto z programistów jednak mówi takim najprostszym, najmniej technicznym językiem, czyli takiego mówiącego najbardziej biznesowo z programistów, poprosić o wytłumaczenie tak najprościej jak się da, a idealnie to na przykładach rzeczy, do których nie umiesz podjąć decyzji. To też jest tak, że na przykład zespół mówi, że powinniśmy zmienić technologię z jakiejś na jakąś albo przepisać aplikację na jakąś nową technologię.

Jako osoba biznesowa, skąd masz wiedzieć co wybrać? Ano, musisz poprosić zespołu o to, żeby ci to ktoś wytłumaczył, czyli nie wiem, niech ktoś przygotuje zestawienie obu technologii i wytłumaczy dlaczego to jest potrzebne, co to da biznesowo, jak to będzie wpływało na całość twojej aplikacji, twojego systemu długoterminowo. Jeżeli nie zadasz tych pytań, no to tutaj będzie na pewno trudniej się dogadać no i tobie też trudniej podejmować tego typu decyzje techniczne. Natomiast, jeżeli te wszystkie osoby masz i nadal nie umiecie się dogadać albo próbowałeś, próbowałaś tych metod i to też nie działało, to może być już pora na CTO, czyli już z kolei tutaj na pośrednika między tobą a zespołem technicznym.

Natomiast, czy ten CTO powinien być zatrudniony na pełny etat, na pół etatu, czy w formie takiego CTO doraźnie dostępnego na godzinę, to już zależy tak naprawdę od ilości takich sytuacji, jakie mają miejsce no i też nie ukrywajmy od twojego budżetu, czyli na ile ta osoba wniesie wartość do twojej organizacji, to też trochę zależy od wielkości zespołu, ale o tym sobie powiemy za chwilę.

3. Moje potrzeby biznesowe nie są zrozumiane tak, jakbym tego oczekiwał/-a

Sytuacja trzecia. Moje potrzeby biznesowe nie są zrozumiane tak, jakbym tego oczekiwał, oczekiwała.

Czy to jest sytuacja, w której przychodzisz z tymi potrzebami biznesowymi, ale nie do końca zespół realizuje to tak, jak finalnie byś chciał, chciała. Tutaj jest tak, że często warto jest, jeżeli już te potrzeby zostaną przez ciebie przekazane, czy to do Product Donora, czy jednak bezpośrednio do zespołu, jeżeli takiego Product Donora jeszcze nie masz w zespole, to warto jest poprosić zespół o jakąś wizualizację, o jakiś tak zwany proof of concept, czy jakąś minimalną wersję, taką, która pozwoli już coś przeklikać, już coś zobaczyć. Czyli generalnie, żeby zespół jak najmniej czasu poświęcił na realizację kontra to, żebyś jak najszybciej mógł, mogła po prostu zobaczyć jakieś efekty i zderzyć je z rzeczywistością, czy to o coś takiego ci chodziło.

Dzięki takiemu podejściu, realizując tę pracę etapami, może się okazać, że dużo szybciej urealnicie, jak coś powinno wyglądać biznesowo, lub sobie wytłumaczycie. Jeżeli próbowałeś już tej metody i ona nie działała, no to tutaj może być już to faktycznie moment, kiedy ten CTO po prostu zdjąłby to z ciebie i z twoich barków.

4. Mój projekt jest oddawany z błędami mimo zgłaszanych potrzeb testowych

Sytuacja czwarta.

Mój projekt jest oddawany z błędami. Zgłaszam ludziom potrzeby dodatkowych testów, ale to nie daje żadnych rezultatów. Czyli sytuacja, w której twoje potrzeby biznesowe są rozumiane dobrze, ale otrzymujesz projekt, który nie działa, lub ma jakieś pojedyncze błędy, które nie pozwalają go uznać za zamknięty.

No i teraz tak, tutaj podstawowe pytanie, jakie mi się pojawia, to kto testuje twój projekt? Czy są to programiści, czy to jest już jakiś dedykowany tester? Teraz jeżeli już tester, to czy ma on rozpisane różnego rodzaju scenariusze testowe? Czy dla zadań, dla których ten tester prowadzi właśnie testy, są ustalane kryteria odbioru? Tutaj warto jeszcze o te kwestie zadbać, czyli zadbać o to, żeby projekt nie był testowany przez programistów, tylko przez testera, żeby tester testował według rozpisanych scenariuszy testowych. W ostateczności, jeżeli na to nie ma czasu, to żeby zadania miały bardzo dobrze, dokładnie ustalone kryteria odbioru, również od strony biznesowej. Kryteria odbioru w tym wypadku mają oznaczać, co ty byś zrobił sprawdzając to zadanie, żeby uznać, że ono faktycznie jest zamknięte, zakończone i tak może być uruchomione docelowo.

I teraz jeżeli o te kwestie zadbałeś, zadbałaś i to nadal nie daje rezultatu, to nadal pojawiają się błędy, no i zakłada, że to nie jest kwestia po prostu tego, że ktoś źle testuje, tylko są jakieś inne powody, to warto zasięgnąć porady np. doświadczonego testera z zewnątrz, który sam proces testów poukłada i doradzi jak to w ogóle zrobić, bo tutaj wbrew pozorom to może być dużo bardziej wartościowa usługa niż wsparcie stricte CTO w tym konkretnym wypadku, czyli wsparcie po prostu testera z zewnątrz, który zobaczy jak te testy są realizowane no i pomoże po prostu je realizować lepiej. Tutaj CTO niekoniecznie może dobrze pomóc.

5. Nie mam czasu na przekazywanie zadań Software House’owi

Sytuacja piąta. Prowadzę taką stałą współpracę z Software House’em, z firmą programistyczną, ale nie mam czasu na przekazywanie zadań. Dodatkowo jeszcze Software House chce, żebym rozpisywał, rozpisywała te zadania dokładniej, na co kompletnie nie mam czasu.

I tutaj podpowiedź taka numer jeden, jeszcze przed CTO to na pewno, czy to analityk, czy product owner in-house. Trochę się z tym na dzisiaj powielam, ale powielam się dlatego, że tutaj to często jest mylone jakby z tym, że właśnie myślę sobie o tym, że chcę zatrudnić zespół wewnętrzny, mam już współpracę z Software House’em, więc pierwsza osoba to CTO, ale tak naprawdę czy tutaj potrzebny jest CTO, żeby rozpisywać zadania do Software House’u? No nie, potrzebny jest product owner, czy analityk, który będzie w stanie twoje wizje przekuwać na zadania. I potrzebna jest wizja procesu, jak on w ogóle ten proces komunikacji z danym Software House’em wygląda.

Tu ewentualnie w zakresie tego procesu faktycznie CTO mógłby pomóc, ale dobry product owner też sobie z tym poradzi.

6. Chcę uniezależnić działania IT od firm zewnętrznych

Sytuacja szósta. Chcę uniezależnić swoje działania IT od firm zewnętrznych.

Czyli też z jakiegoś powodu pojawia się sytuacja, że chcesz zbudować zespół wewnętrzny, który spowoduje, że uniezależniasz swoje tematy programistyczne, czy tematy IT od firm zewnętrznych. Na pewno zadaj sobie po pierwsze pytanie, dlaczego? I oceń, na ile ten twój powód jest realnie, obiektywnie racjonalny. Realnie, obiektywnie racjonalny.

Tak, tak to nazwałem. Ale naprawdę tutaj wymaga to podkreślenia, bo czasem okazuje się, że pewne rzeczy można po prostu dogadać z firmą i może być to znacznie prostsze niż budowanie swojego własnego zespołu. Natomiast generalnie, jeżeli czujesz, że twój powód jest faktycznie obiektywny, no to drugi krok, jaki bym w ramach tego punktu uniezależniania swoich działań IT od firm zewnętrznych zrobił, to jest oszacowanie ilu programistów w zespole potrzebujesz.

Czyli na ile faktycznie dużo masz potrzeb. I teraz w zależności od tego, czy masz tutaj potrzebę na większy zespół bądź mniejszy, od tego bym uzależniał, czy potrzebujesz CTO no i na jaki wymiar czasu.

7. Mam duży zespół IT (powyżej 10 osób)

Pytanie siódme.

Mam duży zespół IT, powyżej 10 osób, który muszę sam zarządzać. Jako manager, który niekoniecznie, czy jako właściciel firmy, który niekoniecznie ma czas i też może możliwości do tego, żeby ten zespołem zarządzać. Czy to jest moment na zatrudnienie CTO? Uważam, że tak.

W tym wypadku to jest stanowczo moment na zatrudnienie CTO. Tu jest kwestia tylko do przemyślenia, czy to będzie CTO na godziny, czy CTO już na pełny etat. Ale tak naprawdę to też trochę zależy od tego, na ile dziś tobie zajmuje zarządzanie zespołem, na ile ten zespół samo sobą zarządza, na ile sam ten zespół wypracował sobie jakiś proces, na ile się go trzyma.

No i tutaj na pewno też trzeba się nad tym zastanowić, zobaczyć jak to wygląda. Natomiast przy okazji już takiego zespołu powyżej, około oczywiście powyżej 10 osób, tutaj już stanowczo widziałbym CTO jako osobę, która jest potrzebna, żeby faktycznie tym działem zarządzić.

8. Mam mały zespół IT (do 3-4 osób)

Pytanie, sytuacja numer 8. Mam mały zespół IT, taki powiedzmy kilkuosobowy, no nie wiem, do 3-4 osób i nie mam nim czasu zarządzać jako menadżer, właściciel.

Czy to jest moment, żeby zatrudnić CTO? No i tutaj właśnie bym się zastanowił, bo z reguły w tego typu sytuacjach, kiedy ten zespół IT jest mniejszy i składa się tylko z programistów, to bardziej brakuje tech leada, który pomoże z tymi problemami technicznymi. Często brakuje project managera czy product ownera, którzy zorganizują zadania i przekażą je do zespołu, a także też odbiorą je w twoim imieniu jako przedstawiciela biznesu i często w tych sytuacjach czy w tego typu zespołach brakuje testera, który te zadania też wesprze, jeżeli chodzi o testy, więc szczerze mówiąc przy tego typu zespołach rzadko kiedy jest to moment już na CTO, chyba że na takie krótkoterminowe wsparcie w kontekście poukładania procesu i ustalenia jak ten zespół powinien funkcjonować, ewentualnie kogo w tym zespole brakuje, no chyba, że ten zespół już w ogóle nie ma żadnego procesu i wszystko się dzieje na hura i pojawiają się też trudności w pracach, no to wtedy jak najbardziej rozważyłbym wsparcie w CTO takiego na pół etatu czy po prostu godzinowo, ale dla tak niedużego zespołu na pewno nie zatrudniałbym w CTO na pełny etat.

9. Zespół nie wie, jakie technologie wybrać

Pytanie dziewiąte, mój zespół nie wie z jakich technologii czy z jakich rozwiązań technologicznych skorzystać i czy tutaj jest to moment na zatrudnienie w CTO? Myślę, że tutaj bardziej skupiłbym się, jeżeli to jest mniejszy zespół, to na konsultacjach bądź wsparciu tech leada, czyli takiego programisty, który tym zespołem programistów jest w stanie zarządzić od strony technicznej czy też technologicznej i w tym aspekcie też po prostu doradzić jaką technologię wybrać, czyli stanowczo, jeżeli zespół ma problemy z tym, że nie wie jak coś zrobić do końca technicznie albo na przykład nie wie z jakiej właśnie technologii skorzystać, to tutaj stanowczo tech lead lub rozwiązanie numer dwa w tej sytuacji zamiast zatrudniania CTO to jest po prostu zorganizowanie dodatkowego czasu dla Twoich programistów na research, szkolenie i spisanie też różnych powodów i drogi, jaką oni podjęli do tego, żeby decyzję co do danego rozwiązania technologicznego wybrać.

To nie do końca chodzi o to, że masz się potem z tym zapoznawać i potwierdzać, czy to jest dobra droga czy zła, tylko bardziej danie czasu ludziom na to, żeby faktycznie mogli te rozwiązania technologiczne dobrać do swoich potrzeb. Jeżeli natomiast tego czasu nie ma, potrzebujesz rozwiązań na szybko, to tutaj po pierwsze myślę, że tech lead, po drugie w ostateczności, jeżeli czujesz, że sam tech lead jeszcze też dobierze rozwiązanie tylko od strony technicznej, ale może nie wziąć pod uwagę wielu rzeczy od strony biznesowej, wtedy CTO warto rozważyć.

Podsumowanie - kiedy CTO naprawdę ma sens?

Podsumowując dzisiejszy odcinek, na początek zastanów się przede wszystkim, z jakim obszarem dokładnie jest problem.

Czy jest to problem z zewnętrzną firmą, czy z czymś konkretnym dla twojego zespołu wewnętrznego, czy problem z przekazywaniem zadań, czy problem z ich odbiorem, a następnie zastanów się, czy inny specjalista niż CTO jest w stanie ten obszar zaopiekować. CTO zatrudniałbym raczej później niż wcześniej, chyba że przyświeca mi tutaj taka realna wizja budowy zespołu większego, czyli takiego powyżej 10 osób, z wizją też faktycznie utrzymania takiego zespołu długoterminowo. Ale tu mocno podkreślam, realna wizja faktycznego utrzymania takiego zespołu długoterminowo.

Jeżeli taka wizja jest, zadań jest cała masa i po prostu ciągle tylko musisz się przekazywać kolejne tematy do software house’u i myślisz o tym zespole wewnętrznym tak bardzo na poważnie, no to tutaj ten CTO w przypadku takiego dużego zespołu jak najbardziej może się przydać. No i co do jeszcze takich rzeczy z podsumowań, rozważyłbym w przypadku, kiedy nie byłbym pewny, czy ten CTO to już jest taki moment, czy jeszcze nie, takie wsparcie CTO na godzinę na start w formie takiego interim managera, który zacząłby układanie procesu i po prostu doradził krótkoterminowo, jak podejść do tematu tu i teraz na dzisiaj i rozwiązał takie bieżące bolączki, ale także pomógł ułożyć taką strategię długoterminowego podejścia, jak działać zadaniami, jak po prostu sprawić, żeby IT ten biznes twój faktycznie wspierało. Jeżeli po przesłuchaniu tego odcinka nadal zastanawiasz się, czy to już czas na zatrudnienie CTO i nie widzisz takiej jednoznacznej odpowiedzi, serdecznie zapraszam do kontaktu.

Zapraszam także do subskrypcji mojego podcastu w miejscu, gdzie go aktualnie słuchasz. Serdecznie dziękuję za wysłuchanie dzisiejszego odcinka. W następnym odcinku przeskoczymy do tematu współpracy na linii biznes i firma programistyczna, a mianowicie do etapu odbioru projektu od Software House’u.

Opowiem tutaj o tym, na co zwrócić uwagę przy takich odbiorach, jak to powinno wyglądać i na co się przygotować. Serdecznie dziękuję i do usłyszenia w przyszły wtorek. Cześć!