Prezes spółki z dwudziestoma pracownikami wraca ze spotkania z inwestorem z listą pytań, na które nie umie odpowiedzieć. Czy architektura udźwignie wejście na drugi rynek? Ile kosztuje utrzymanie platformy i dlaczego rachunek za chmurę urósł o połowę w pół roku? Czy software house, który od dwóch lat rozwija produkt, pracuje dobrze, czy tylko wystawia faktury? Kto odpowiada za bezpieczeństwo danych klientów? Prezes zna rynek i klientów, ale nie jest inżynierem. Najbliższa osoba techniczna to senior developer, który świetnie pisze kod, ale nigdy nie budował budżetu ani nie negocjował umowy z dostawcą.
Pierwszy odruch to „potrzebujemy CTO”. Drugi, po przejrzeniu ogłoszeń i rozmowie z rekruterem, to wątpliwość: pełny etat doświadczonego lidera technologicznego to jeden z najdroższych etatów w firmie, rekrutacja trwa miesiącami, a połowy jego tygodnia na tym etapie nie byłoby czym wypełnić. Pojawia się trzecia opcja, o której coraz częściej słychać: CTO na część etatu, czyli fractional CTO.
Ten artykuł jest dla prezesa albo właściciela, który rozważa taką współpracę. Wyjaśniamy, co taki CTO realnie robi, a czego nie zrobi, jak wycenić jego czas, jakie modele rozliczenia mają sens, co zapisać w umowie, po czym poznać, że część etatu przestała wystarczać, i gdzie w tej układance mieszczą się usługi takie jak niezależny audyt kodu. Uczciwie od razu: ARDURA Consulting nie sprzedaje pakietu „fractional CTO”. Piszemy o nim, bo regularnie rozmawiamy z firmami, które stoją przed tą decyzją, a część z nich potrzebuje czegoś innego, niż sądzi.
Czym właściwie jest CTO na część etatu?
CTO na część etatu to doświadczony lider technologiczny, który przez ustaloną liczbę dni w miesiącu pełni w Twojej firmie funkcję dyrektora technicznego. Nie jest konsultantem od jednego projektu i nie jest programistą dorabiającym po godzinach. Ma te same obowiązki co CTO na etacie, tylko w mniejszym wymiarze: odpowiada za kierunek technologiczny, za jakość decyzji architektonicznych, za relację z zespołem lub dostawcą i za to, żeby zarząd rozumiał, na co wydaje pieniądze.
Najczęstszy wymiar to od jednego do dwóch dni w tygodniu, czasem pół etatu. Poniżej jednego dnia w tygodniu trudno mówić o roli CTO, bo taka osoba nie nadąża za tym, co dzieje się w firmie, i zamienia się w doradcę na telefon. Powyżej trzech dni w tygodniu różnica w koszcie wobec pełnego etatu jest już niewielka, a firma traci to, co w modelu częściowym najcenniejsze: dostęp do kogoś, kto widzi wiele firm naraz i nie jest uwikłany w codzienne bieżączki.
Warto odróżnić trzy pokrewne role, które w rozmowach się mieszają. CTO na część etatu zostaje w firmie na dłużej, zwykle na rok lub dłużej, i bierze odpowiedzialność za decyzje. CTO tymczasowy (interim) wchodzi na pełen etat na kilka miesięcy, najczęściej na czas kryzysu albo rekrutacji następcy. Doradca technologiczny odpowiada na pytania, ale nie podejmuje decyzji i nie odpowiada za ich skutki. Jeśli w umowie nie ma ani jednej decyzji, za którą ta osoba odpowiada, to kupujesz doradztwo, a nie CTO, i warto to nazwać wprost, bo od tego zależy cena i oczekiwania.
Ostatnia uwaga definicyjna: CTO na część etatu nie musi być osobą fizyczną zatrudnioną bezpośrednio. Często jest to przedsiębiorca na umowie B2B albo osoba delegowana przez firmę doradczą. To zmienia sposób rozliczenia i zapisy umowy, o czym niżej, ale nie zmienia samej roli.
Jakie zadania CTO na część etatu wykonuje w praktyce?
Dobrze ustawiona współpraca ma krótką listę obowiązków, którą da się sprawdzić po kwartale. Zwykle obejmuje sześć obszarów.
Kierunek technologiczny i architektura. CTO decyduje albo zatwierdza kluczowe wybory: monolit czy usługi, jaka chmura, budować czy kupić, kiedy płacić dług technologiczny. Nie rysuje każdego diagramu, ale pilnuje, żeby decyzje miały uzasadnienie i były zapisane. Praktyczne narzędzie to rejestr decyzji architektonicznych (ADR) w formacie, który Michael Nygard opisał w 2011 roku: kontekst, decyzja, status, konsekwencje. Dzięki temu po roku wiadomo, dlaczego system wygląda tak, a nie inaczej, nawet jeśli CTO już w firmie nie ma. Podstawy pojęciowe znajdziesz w haśle słownikowym o architekturze oprogramowania.
Nadzór nad zespołem albo dostawcą. Jeśli produkt rozwija software house, CTO jest po Twojej stronie stołu: czyta estymacje, zadaje pytania o jakość, sprawdza, czy praca idzie zgodnie z umową. Jeśli masz własny zespół, CTO ustawia sposób pracy, przegląda kluczowe zmiany i pomaga liderom zespołów, ale nie zarządza każdym programistą osobiście.
Budżet technologiczny. Koszty chmury, licencji, narzędzi, ludzi i dostawców w jednym miejscu, z planem na rok i z wyjaśnieniem, co się zmieni, jeśli firma urośnie dwa razy. To często pierwszy dokument, który CTO na część etatu przygotowuje, i pierwszy, którego zarząd naprawdę potrzebuje.
Rekrutacja i struktura zespołu. CTO pisze profile ról technicznych, prowadzi rozmowy techniczne z kandydatami na kluczowe stanowiska i decyduje, które kompetencje zatrudnić na stałe, a które uzupełnić z zewnątrz. Na tym etapie wiele firm odkrywa, że nie potrzebuje kolejnych pięciu programistów, tylko jednego doświadczonego architekta i lepszego procesu.
Bezpieczeństwo i zgodność. Nie chodzi o to, żeby CTO osobiście konfigurował zapory, tylko o to, żeby ktoś odpowiadał za listę ryzyk: kto ma dostęp do produkcji, gdzie są kopie zapasowe i czy ktoś je kiedyś odtworzył, jakie dane osobowe przetwarza system, kiedy był ostatni test bezpieczeństwa.
Rozmowy z inwestorami i klientami. Inwestor przed rundą, klient korporacyjny przed podpisaniem umowy, audytor bezpieczeństwa klienta: wszyscy chcą rozmawiać z kimś, kto odpowiada za technologię. CTO na część etatu jest tą osobą, przygotowuje materiały i odpowiada na pytania techniczne.
Czego w tej liście brakuje? Pisania kodu. To nie przypadek i wracamy do tego niżej.
Kiedy CTO na część etatu wystarczy, a kiedy potrzebny jest pełny etat?
To najważniejsze pytanie w tym artykule i odpowiedź zależy mniej od wielkości firmy, a bardziej od tego, jak często zapadają decyzje techniczne, które blokują pracę, jeśli nikt ich nie podejmie od razu.
Część etatu zwykle wystarczy, gdy spełnione są trzy warunki. Po pierwsze, zespół techniczny jest mały, mniej więcej do kilkunastu osób, albo produkt rozwija zewnętrzny dostawca. Po drugie, firma ma jeden główny produkt i stabilny kierunek, a nie pięć eksperymentów naraz. Po trzecie, istnieje ktoś, kto prowadzi bieżącą pracę zespołu, na przykład lider techniczny albo kierownik projektu po stronie dostawcy, więc CTO nie musi być dostępny w każdej godzinie dnia.
Pełny etat staje się konieczny, gdy któryś z tych warunków przestaje obowiązywać. Zespół rośnie powyżej kilkunastu osób i potrzebuje codziennego przywództwa, nie cotygodniowego. Technologia staje się głównym źródłem przewagi konkurencyjnej, na przykład firma buduje własne modele, platformę dla innych firm albo produkt, który sprzedaje się przez API. Albo decyzje techniczne zapadają codziennie i każdy dzień czekania na CTO kosztuje zespół realny czas.
Jest też sygnał, który łatwo przeoczyć: CTO na część etatu regularnie pracuje więcej, niż przewiduje umowa. Jeśli przez trzy miesiące z rzędu dwa dni w tygodniu zamieniają się w cztery, to nie jest dowód zaangażowania, tylko dowód, że firma potrzebuje pełnego etatu. Najlepsi CTO na część etatu sami to mówią i pomagają zrekrutować następcę.
Jedno zastrzeżenie od strony przeciwnej. Zdarza się, że firma zatrudnia CTO na część etatu, bo „i tak potrzebujemy kogoś technicznego”, choć jej realny problem jest węższy: nie wie, czy dostawca dobrze pracuje, albo nie wie, co jest w kodzie, który kupuje. Takie pytanie ma zamkniętą odpowiedź i nie wymaga rocznej umowy. Opisujemy to w osobnej sekcji niżej.
Jak dobrać liczbę dni w miesiącu do etapu firmy?
Wymiar powinien wynikać z listy zadań, a nie z budżetu, który „jakoś się zmieści”. Dobra praktyka to policzyć powtarzalne obowiązki i dodać rezerwę na zdarzenia.
W firmie z zewnętrznym dostawcą i jednym produktem powtarzalne obowiązki to zwykle: cotygodniowe spotkanie z dostawcą i przegląd postępu, comiesięczny przegląd kosztów i ryzyk, udział w planowaniu kwartału, przegląd kluczowych zmian architektonicznych. To mieści się w czterech do sześciu dni w miesiącu, czyli w okolicy jednego dnia w tygodniu, plus kilka godzin dostępności na pilne pytania.
W firmie z własnym zespołem od pięciu do kilkunastu osób dochodzi rekrutacja, rozwój liderów, ustawianie procesu wytwarzania i częstsze decyzje architektoniczne. Tu realny wymiar to raczej osiem do dziesięciu dni w miesiącu, czyli dwa dni w tygodniu.
Pierwsze trzy miesiące są wyjątkiem. CTO musi poznać system, ludzi, umowy i koszty, a często też naprawić to, co zaniedbano. Rozsądnie jest zaplanować na ten okres większy wymiar, na przykład dwa dni w tygodniu, i zejść do docelowego poziomu od czwartego miesiąca. Jeśli Twój kandydat proponuje stały wymiar od pierwszego dnia, zapytaj, kiedy zamierza przeczytać kod i umowy.
Na koniec rezerwa. Incydent produkcyjny, pytanie inwestora z terminem na jutro, nagłe odejście kluczowej osoby: takie zdarzenia się zdarzają. Umowa powinna przewidywać, ile dodatkowych godzin w miesiącu jest dostępnych i po jakiej stawce, zamiast udawać, że ich nie będzie.
Ile kosztuje CTO na część etatu i od czego zależy cena?
Nie ma jednego cennika rynkowego tej usługi, który dałoby się uczciwie zacytować. Ceny ustalane są indywidualnie, często jako miesięczny abonament, i rzadko publikowane. Dlatego zamiast podawać widełki bez źródła, proponujemy prostą metodę: koszt to stawka dzienna doświadczonego lidera technicznego razy liczba dni w miesiącu, plus rezerwa na godziny ponadplanowe.
Punkt odniesienia dla stawki dziennej da się sprawdzić. W cenniku ARDURA Consulting stawki ról na poziomie architekta lub leada (8+ lat doświadczenia) mieszczą się zwykle w przedziale 2 080–2 800 PLN netto za dzień, a dla architekta chmury 2 800–3 600 PLN. To nie są ceny usługi fractional CTO, której nie mamy w ofercie, tylko stawki za role o podobnym poziomie doświadczenia, przydatne jako kotwica do rozmowy z kandydatem. Przy takim przedziale arytmetyka wygląda tak:
- jeden dzień w tygodniu (ok. 4,3 dnia w miesiącu): około 9–12 tys. PLN netto miesięcznie;
- dwa dni w tygodniu (ok. 8,7 dnia w miesiącu): około 18–24 tys. PLN netto miesięcznie;
- pół etatu (ok. 10–11 dni w miesiącu): około 21–31 tys. PLN netto miesięcznie.
To szacunek, a nie fakt rynkowy. Cenę w górę przesuwają: doświadczenie w Twojej branży (systemy finansowe, medyczne, przemysłowe), wcześniejsze zbudowanie zespołu od zera, udział w rundach finansowania, dostępność poza ustalonymi dniami i odpowiedzialność za zgodność z regulacjami. W dół: krótszy horyzont odpowiedzialności, jasno ograniczony zakres i elastyczność co do dni pracy.
Porównując z pełnym etatem, nie porównuj samych stawek. Pełnoetatowy CTO to wynagrodzenie, koszty pracodawcy, często udziały w firmie i kilka miesięcy rekrutacji, w czasie których decyzje dalej zapadają bez niego. CTO na część etatu nie ma okresu rozruchu rekrutacyjnego i nie wymaga udziałów, ale jego dzień kosztuje więcej niż dzień pracownika etatowego. Sensowne porównanie to łączny koszt roczny przy realnej liczbie dni, a nie stawka za dzień. Jeśli chcesz zobaczyć, jak całkowity koszt zatrudnienia wygląda w różnych formach, pomocny jest nasz przegląd modeli rozliczeń: abonament zespołu, time and materials i fixed price.
Jakie modele rozliczenia mają sens?
W praktyce spotkasz trzy modele i każdy przenosi ryzyko w inne miejsce.
Miesięczny abonament za ustaloną liczbę dni. Najczęstszy i zwykle najlepszy. Płacisz stałą kwotę za, powiedzmy, osiem dni w miesiącu i za ustaloną dostępność na pilne sprawy. Masz przewidywalny koszt, a CTO ma przewidywalny przychód, co sprzyja zaangażowaniu. Kluczowe zapisy to: co się dzieje z niewykorzystanymi dniami (przepadają, przechodzą na następny miesiąc w ograniczonym limicie, czy obniżają fakturę) i ile kosztują dni ponad limit.
Stawka dzienna lub godzinowa, rozliczana z faktycznego czasu. Elastyczna, ale ma wadę: CTO nie ma powodu, żeby zgłaszać się z własnej inicjatywy, a Ty masz powód, żeby oszczędzać na kontakcie. W rezultacie rola CTO rozmywa się w rolę konsultanta na wezwanie. Ten model sprawdza się w okresie próbnym albo przy bardzo nieregularnych potrzebach.
Abonament plus składnik uzależniony od wyników albo udziały. Spotykany w startupach, które nie mają gotówki na pełną stawkę. Może działać, ale wymaga precyzji: za co dokładnie jest premia, kto mierzy wynik, co się dzieje z udziałami przy rozstaniu. Nieprecyzyjne zapisy o udziałach to częsta przyczyna sporów, które ciągną się dłużej niż sama współpraca. Jeśli idziesz w tę stronę, zaangażuj prawnika od prawa spółek, a nie tylko księgową.
W Polsce CTO na część etatu najczęściej pracuje na umowie B2B. Pamiętaj jednak, że według art. 22 § 1¹ Kodeksu pracy o istnieniu stosunku pracy decydują warunki wykonywania pracy, a nie nazwa umowy. Jeśli osoba pracuje pod Twoim kierownictwem, w miejscu i czasie wyznaczonym przez Ciebie, za stałe wynagrodzenie i bez ryzyka gospodarczego, umowa B2B może zostać uznana za stosunek pracy. Dla CTO, który z definicji samodzielnie podejmuje decyzje w ramach ustalonego zakresu, to ryzyko jest zwykle mniejsze niż dla programisty, ale warto, żeby umowa opisywała rezultaty i obszary odpowiedzialności, a nie godziny obecności.
Co zapisać w umowie z CTO na część etatu?
Umowa powinna odpowiadać na pytania, które pojawią się dopiero wtedy, gdy coś pójdzie źle. Oto lista zapisów, które warto mieć przed podpisem.
Zakres odpowiedzialności, nie lista czynności. Zapis „uczestniczy w spotkaniach zespołu” nic nie znaczy. Zapis „zatwierdza decyzje architektoniczne o koszcie lub skutkach powyżej ustalonego progu i prowadzi ich rejestr” znaczy dużo. Wypisz decyzje, za które CTO odpowiada, i te, które zostają przy zarządzie.
Wymiar, dostępność i rezerwa. Liczba dni w miesiącu, dni lub godziny stałej obecności, czas reakcji na pilne sprawy, limit godzin ponadplanowych i ich stawka.
Uprawnienia. Do czego CTO ma dostęp (repozytoria, chmura, umowy z dostawcami, budżet), czy może podpisywać zamówienia i do jakiej kwoty, czy może zatrudniać i zwalniać, czy reprezentuje firmę wobec dostawców.
Konflikt interesów. CTO na część etatu pracuje zwykle dla kilku firm. Umowa powinna wykluczać pracę dla bezpośredniej konkurencji i zobowiązywać do ujawnienia powiązań z dostawcami. Jeśli CTO poleca software house, w którym ma udziały albo od którego dostaje prowizję, musisz o tym wiedzieć przed decyzją, nie po niej.
Poufność i prawa do rezultatów. Dokumenty, decyzje, diagramy i kod, jeśli powstanie, należą do firmy. Przeniesienie autorskich praw majątkowych z wyszczególnieniem pól eksploatacji, zgodnie z polskim prawem autorskim, a nie ogólnik „wszystkie prawa przechodzą na zamawiającego”.
Przekazanie przy rozstaniu. Okres wypowiedzenia, który pozwala znaleźć następcę, obowiązek przekazania dostępów, rejestru decyzji, dokumentacji i listy otwartych ryzyk. Bez tego zapisu wiedza odchodzi razem z osobą, a firma zostaje dokładnie tam, gdzie była przed współpracą, tylko z mniejszym budżetem.
Mierzalne cele na pierwszy kwartał. O tym w następnej sekcji.
Jak mierzyć, czy CTO na część etatu dowozi wartość?
Rola przywódcza jest trudna do zmierzenia, ale nie niemożliwa. Najlepiej łączyć trzy rodzaje miar.
Rezultaty pierwszego kwartału. Zanim zacznie, ustal z CTO, co ma powstać w pierwszych 90 dniach. Typowa lista: ocena stanu systemu i zespołu z listą głównych ryzyk, budżet technologiczny na rok, rejestr kluczowych decyzji architektonicznych, plan rekrutacji albo zmiany modelu współpracy z dostawcą, plan działań na kolejne dwa kwartały. Jeśli po trzech miesiącach tych dokumentów nie ma, rozmowa o przedłużeniu jest łatwa.
Wskaźniki dostarczania oprogramowania. Program badawczy DORA (Google Cloud) opisuje pięć miar wydajności dostarczania: czas realizacji zmiany, częstotliwość wdrożeń, czas odtworzenia po nieudanym wdrożeniu, odsetek zmian kończących się awarią i odsetek wdrożeń wymagających poprawek. Nie musisz ich wszystkich mierzyć od pierwszego dnia, ale dobry CTO powinien umieć powiedzieć, które z nich mierzy, jaki jest punkt startowy i jak zamierza je poprawić. Opis miar znajdziesz w przewodniku DORA o metrykach dostarczania.
Jakość decyzji w oczach zarządu. Czy zarząd rozumie, na co wydaje pieniądze na technologię? Czy pytania inwestorów przestały zaskakiwać? Czy relacja z dostawcą stała się przewidywalna? To miękkie miary, ale prezes zna na nie odpowiedź po kwartale. Jeśli odpowiedź brzmi „nie wiem, co on właściwie robi”, problem jest albo w CTO, albo w komunikacji, i obie wersje trzeba rozwiązać.
Dobra praktyka to krótki miesięczny raport od CTO: co zdecydowano, co zmierzono, jakie są trzy największe ryzyka i czego potrzebuje od zarządu. Jedna strona wystarczy. Raport, którego nie da się przeczytać w pięć minut, jest napisany dla autora, nie dla prezesa. Szerzej o tym, jak nietechniczny lider może mądrze prowadzić zespoły techniczne, piszemy w przewodniku dla nietechnicznego lidera.
Jakie są czerwone flagi przy wyborze kandydata?
Kilka sygnałów powinno zapalić lampkę ostrzegawczą jeszcze przed podpisaniem umowy.
Kandydat od razu wie, jaką technologię wybrać. Zanim zobaczył system, zespół i budżet, już ma odpowiedź: „przepiszemy na mikroserwisy”, „przenosimy wszystko do chmury X”. Dobry CTO najpierw zadaje pytania, potem rekomenduje. Gotowe odpowiedzi zwykle oznaczają, że kandydat sprzedaje swoje ulubione rozwiązanie.
Powiązania z dostawcą, które wychodzą przypadkiem. Kandydat poleca konkretny software house i dopiero na trzecim spotkaniu okazuje się, że jest jego wspólnikiem albo dostaje od niego prowizję. Takie powiązanie nie musi dyskwalifikować, ale nieujawnione dyskwalifikuje.
Brak historii odpowiedzialności. Kandydat był konsultantem w wielu projektach, ale nigdy nie odpowiadał za budżet, zespół ani skutki decyzji. To może być świetny doradca, ale nie CTO.
Zbyt wiele równoległych firm. CTO na część etatu pracuje dla kilku firm, to normalne. Ale jeśli kandydat ma ich osiem, Twoja firma dostanie zmęczoną uwagę w przerwach między spotkaniami. Zapytaj wprost, dla ilu firm pracuje i ile dni w tygodniu każdej poświęca.
Niechęć do pisania czegokolwiek. Jeśli kandydat uważa, że dokumentowanie decyzji to biurokracja, po jego odejściu zostanie po nim tylko wspomnienie. W roli częściowej, gdzie CTO nie jest dostępny codziennie, pisemne decyzje są jedynym sposobem, żeby zespół wiedział, co ustalono.
Chęć pisania kodu w projekcie. O tym w następnej sekcji.
Dlaczego CTO na część etatu nie powinien pisać kodu w projekcie?
Pokusa jest zrozumiała. Doświadczony inżynier, i tak opłacany, mógłby „przy okazji” dopisać kluczową funkcję, poprawić błąd, zrobić przegląd i od razu naprawić. Na krótką metę to wygląda jak oszczędność. Na dłuższą tworzy trzy problemy.
Pierwszy to utrata niezależności. Jeśli CTO pisze kod, przestaje być osobą, która obiektywnie ocenia jakość pracy zespołu albo dostawcy. Trudno krytykować architekturę, którą się współtworzyło, i trudno rozliczać dostawcę z błędów w module, który się samemu poprawiało.
Drugi to czas. W modelu jednego czy dwóch dni w tygodniu każda godzina implementacji to godzina mniej na decyzje, budżet, rekrutację i rozmowy z zarządem. Implementacja zawsze wygrywa w walce o czas, bo daje szybki, widoczny efekt. Decyzje przegrywają, bo ich skutek widać po kwartale.
Trzeci to wąskie gardło. Kod napisany przez osobę obecną w firmie dwa dni w tygodniu jest kodem, którego nikt inny dobrze nie zna i który czeka na autora, gdy coś trzeba zmienić.
Rozwiązanie jest proste: rozdziel role. CTO ustawia standardy, zatwierdza kluczowe decyzje i kontroluje jakość. Kod piszą programiści: Twój zespół, dostawca albo specjaliści dołączeni do zespołu w modelu body leasingu, jeśli brakuje konkretnych kompetencji. Jeśli w pewnym momencie firma potrzebuje doświadczonego architekta na co dzień, to jest osobna rola z osobnym budżetem, a nie rozszerzenie zakresu CTO.
Kiedy zamiast CTO na część etatu wystarczy jednorazowy audyt?
Wiele rozmów o CTO na część etatu zaczyna się od pytania, które ma krótką, zamkniętą odpowiedź. Typowe przykłady: „Czy nasz dostawca dobrze pracuje?”, „Co jest w kodzie, który przejmujemy od poprzedniego software house’u?”, „Czy ta architektura udźwignie dziesięć razy więcej klientów?”, „Co powiemy inwestorowi o technologii?”. Na każde z nich da się odpowiedzieć w ciągu kilku tygodni pracy niezależnego zespołu, bez rocznej umowy.
To jest miejsce, w którym ARDURA Consulting może realnie pomóc. Prowadzimy dwa pakiety o stałym zakresie. Audyt kondycji kodu (Code Health Audit) trwa od tygodnia do dwóch, kosztuje od 18 000 PLN i obejmuje przegląd kodu i analizę statyczną, ocenę architektury, profilowanie wydajności, przegląd bezpieczeństwa kodu i zależności oraz oszacowanie długu technologicznego. Rezultatem jest raport z mapą ryzyk i priorytetowym planem naprawczym. Technical Due Diligence trwa od dwóch do trzech tygodni, kosztuje od 35 000 PLN i dodaje ocenę zespołu i procesu wytwarzania, skalowalności i infrastruktury, zgodności licencji open source oraz ryzyk istotnych dla inwestora albo kupującego, z raportem pisanym dla decydentów bez przygotowania technicznego.
Jak to się ma do CTO na część etatu? Na trzy sposoby. Po pierwsze, audyt może zastąpić CTO, jeśli Twój problem był jednorazowy: dostajesz odpowiedź i plan, a realizację powierzasz zespołowi lub dostawcy. Po drugie, audyt może poprzedzić CTO: nowy CTO, zamiast spędzać pierwsze tygodnie na czytaniu kodu, zaczyna od niezależnego raportu i od razu przechodzi do decyzji. Po trzecie, audyt może uzupełnić CTO, gdy ten potrzebuje niezależnej opinii z zewnątrz, na przykład przed rozmową z inwestorem albo przed zmianą dostawcy. Szczegółowy przebieg takiego audytu, także w wariancie dla kodu pisanego z asystentami AI, opisaliśmy w artykule audyt kodu z AI w 2 tygodnie.
Dobry test: zapisz pytanie, na które szukasz odpowiedzi. Jeśli da się je zapisać jednym zdaniem i ma termin, zacznij od audytu. Jeśli pytań jest wiele, zmieniają się co miesiąc i dotyczą przyszłych decyzji, potrzebujesz kogoś na stałe.
Jak porównać opcje: CTO na część etatu, pełny etat, audyt i doradca?
Poniższa tabela zbiera opisane wyżej kryteria w jednym miejscu. Traktuj ją jako punkt wyjścia do rozmowy w zarządzie, nie jako algorytm.
| Sytuacja firmy | Najlepsza opcja | Dlaczego | Typowy horyzont | Na co uważać |
|---|---|---|---|---|
| Jedno konkretne pytanie o kod, architekturę albo dostawcę, z terminem | Jednorazowy audyt (np. Code Health Audit lub Technical Due Diligence) | Zamknięta odpowiedź, stały zakres i cena, niezależność od zespołu | 1–3 tygodnie | Ktoś musi być właścicielem planu działań po raporcie |
| Mały zespół lub zewnętrzny dostawca, jeden produkt, decyzje co kilka tygodni | CTO na część etatu, ok. 1 dzień w tygodniu | Kierunek, nadzór nad dostawcą i budżet bez kosztu pełnego etatu | 6–18 miesięcy | Niejasny zakres odpowiedzialności, ukryte powiązania z dostawcą |
| Własny zespół 5–15 osób, rekrutacja, ustawianie procesu | CTO na część etatu, 2 dni w tygodniu lub pół etatu | Wystarczająco dużo czasu na ludzi i proces, wciąż taniej niż pełny etat | 12–24 miesiące | Regularne przekraczanie wymiaru to sygnał przejścia na pełny etat |
| Zespół powyżej kilkunastu osób, technologia jako główna przewaga | CTO na pełen etat | Codzienne decyzje i przywództwo, długoterminowa odpowiedzialność | bezterminowo | Długa rekrutacja; na ten czas rozważ CTO tymczasowego |
| Kryzys: odejście CTO, awarie, konflikt z dostawcą | CTO tymczasowy, często razem z audytem | Szybka stabilizacja i przygotowanie następcy | 3–6 miesięcy | Plan przekazania wpisany do umowy od pierwszego dnia |
| Potrzebujesz tylko odpowiedzi na pytania, decyzje zostają przy zarządzie | Doradca technologiczny | Najtańsza forma dostępu do wiedzy | doraźnie | Doradca nie odpowiada za skutki; nie nazywaj go CTO |
Zauważ, że dwa wiersze można łączyć. Firma, która zatrudnia CTO na część etatu, często na starcie zamawia też audyt, żeby nowy CTO miał niezależny punkt odniesienia. Firma, która rekrutuje CTO na pełen etat, może na czas rekrutacji skorzystać z CTO tymczasowego. Najdroższą opcją jest zwykle brak decyzji: miesiące, w których nikt nie odpowiada za technologię, a dług technologiczny i koszty rosną bez nadzoru.
Jak wygląda dobry pierwszy kwartał współpracy?
Jeśli zdecydujesz się na CTO na część etatu, pierwsze 90 dni decyduje o tym, czy współpraca da wartość. Oto plan, który warto uzgodnić przed startem.
Tygodnie 1–4: poznanie. CTO dostaje dostęp do repozytoriów, chmury, umów z dostawcami i budżetu. Rozmawia z zarządem, z kluczowymi osobami w zespole i z dostawcą. Czyta kod w ścieżkach krytycznych albo korzysta z gotowego raportu z audytu, jeśli go zamówiłeś. Na koniec miesiąca przedstawia zarządowi stan obecny: co działa, co jest ryzykiem, czego nie wiemy.
Tygodnie 5–8: decyzje. Na podstawie stanu obecnego CTO proponuje trzy do pięciu najważniejszych decyzji na kolejne pół roku: co naprawić, co zbudować, co kupić, kogo zatrudnić, co zmienić w relacji z dostawcą. Każda decyzja ma uzasadnienie, koszt i właściciela. Zarząd je zatwierdza albo odrzuca z uzasadnieniem.
Tygodnie 9–12: rytm. CTO ustawia stały rytm pracy: cotygodniowy przegląd z zespołem lub dostawcą, miesięczny raport dla zarządu, kwartalny przegląd budżetu i ryzyk. Na koniec kwartału zarząd ocenia współpracę według rezultatów uzgodnionych na starcie i decyduje o kolejnym okresie i wymiarze.
Jeśli po pierwszym kwartale okaże się, że potrzebujesz więcej rąk do pracy niż decyzji, możesz uzupełnić zespół o specjalistów. W naszym serwisie dostępnych ekspertów jako modele współpracy wymieniamy pełen etat, część etatu i pracę projektową, a usługa tworzenia oprogramowania na zamówienie obejmuje realizację całych projektów, od fazy discovery po wdrożenie. Więcej o samej roli lidera technologicznego w firmie przeczytasz w artykule o CTO jako architekcie wartości biznesowej, a przegląd tematów z obszaru wytwarzania oprogramowania zebraliśmy w hubie software development.
Podsumowanie: od czego zacząć decyzję?
CTO na część etatu to rozsądna odpowiedź na realny problem: firma potrzebuje odpowiedzialności za technologię, ale nie potrzebuje jeszcze, albo nie stać jej na, pełnoetatowego lidera. Działa, gdy ma jasny zakres odpowiedzialności, wymiar dobrany do listy zadań, umowę, która przewiduje konflikt interesów i rozstanie, oraz mierzalne rezultaty pierwszego kwartału. Przestaje działać, gdy zespół rośnie, technologia staje się główną przewagą albo CTO regularnie pracuje więcej, niż przewiduje umowa.
Zapamiętaj pięć rzeczy. Po pierwsze, zacznij od zapisania pytań, na które szukasz odpowiedzi: jedno pytanie z terminem to audyt, wiele zmieniających się pytań to CTO. Po drugie, licz koszt jako stawkę dzienną razy realną liczbę dni plus rezerwę, a porównuj łączny koszt roczny, nie stawki. Po trzecie, w umowie zapisuj odpowiedzialność, uprawnienia, konflikt interesów i przekazanie wiedzy, a nie godziny obecności. Po czwarte, nie pozwól, żeby CTO na część etatu stał się najlepiej opłacanym programistą w zespole. Po piąte, mierz rezultaty po kwartale i nie bój się zmienić modelu, gdy firma urośnie.
Jeśli Twoje pierwsze pytanie brzmi „co właściwie mamy w kodzie i czy dostawca dobrze pracuje”, nie potrzebujesz od razu rocznej umowy. Sprawdź pakiety audytu kodu i Technical Due Diligence albo umów krótką rozmowę: powiemy, czy w Twojej sytuacji wystarczy audyt, czy rzeczywiście potrzebujesz kogoś na stałe.