Zewnętrzny CTO (fractional CTO): kiedy się opłaca i czego oczekiwać

Zewnętrzny CTO opłaca się, gdy potrzebujesz decyzji i nadzoru na poziomie dyrektora technologii, ale nie masz dla takiej osoby pracy na pełny etat albo budżetu na nią. Najczęściej korzystają z niego nietechniczni założyciele, firmy współpracujące z software house’em i spółki przygotowujące się do rozmów z inwestorem.

Czym jest zewnętrzny CTO (fractional CTO)

Fractional CTO to doświadczony lider technologiczny, który pełni funkcję CTO w Twojej firmie w niepełnym wymiarze, zwykle równolegle dla kilku organizacji. Nie jest konsultantem, który zostawia raport i znika. Bierze udział w decyzjach, rozmawia z dostawcami i odpowiada za kierunek technologiczny w ustalonym zakresie.

Model „ułamkowych” członków kadry zarządzającej (fractional CFO, CMO, CTO) coraz częściej wybierają startupy oraz małe i średnie firmy. W podcaście Harvard Business Review goście podkreślają, że taka osoba powinna być obecna we wszystkich ważnych momentach firmy, mimo że nie pracuje na etacie. Wśród ryzyk wymieniają rozmywanie się zakresu i relację, która staje się czysto transakcyjna.

Kto potrzebuje zewnętrznego CTO

Nietechniczny założyciel

Masz pomysł na produkt, budżet i wybranego wykonawcę, ale nie potrafisz ocenić, czy architektura ma sens, a estymacja jest realna. Zewnętrzny CTO tłumaczy decyzje techniczne na język ryzyka, czasu i pieniędzy, zanim podpiszesz umowę. Pomoże też zrozumieć, od czego zależy koszt aplikacji i gdzie wycena ma luki.

Firma z zewnętrznym software house’em

Wykonawca pisze kod, raportuje postęp i sam ocenia jakość swojej pracy. Brakuje osoby po Twojej stronie, która przejrzy pull requesty, sprawdzi, czy istnieją testy, i zapyta, dlaczego sprint znów się przesunął. Na etapie wyboru wykonawcy przyda się poradnik jak ocenić ofertę software house’u.

Spółka przed inwestycją lub due diligence

Inwestor zwykle przygląda się kodowi, architekturze, bezpieczeństwu i prawom do oprogramowania. Lepiej, żeby słabe punkty znalazł ktoś po Twojej stronie kilka miesięcy wcześniej, a nie audytor funduszu w trakcie negocjacji.

Firma po nieudanym projekcie

Projekt przekroczył budżet, dostawca zniknął albo aplikacji nie da się dalej rozwijać. Zewnętrzny CTO ocenia, co można uratować, co trzeba przepisać i jak nie powtórzyć tych samych błędów z kolejnym wykonawcą.

Co robi zewnętrzny CTO: zakres obowiązków

Zakres zależy od etapu firmy, ale w praktyce powtarza się kilka obszarów.

• Strategia i roadmapa technologiczna. Co budujesz w najbliższych kwartałach, na jakim stosie technologicznym, co kupujesz jako gotową usługę, a co piszesz sam.
• Nadzór nad dostawcami i zespołami. Przegląd estymacji, udział w planowaniu, odbiory, porównanie fakturowanych godzin z realnym postępem.
• Audyty architektury i kodu. Jakość kodu, dług technologiczny, testy, sposób wdrażania, zależność od konkretnych osób.
• Pomoc w rekrutacji. Opis ról, zadania techniczne, udział w rozmowach z kandydatami na developerów i tech leadów.
• Bezpieczeństwo. Zarządzanie dostępami, kopie zapasowe, plan reakcji na incydenty i decyzja, kiedy zlecić test penetracyjny.
• Budżet i koszty chmury. Przegląd rachunków za infrastrukturę, licencje i narzędzia. Przydaje się tu podejście FinOps, które FinOps Foundation opisuje jako współpracę inżynierii, finansów i biznesu nad wartością wydatków na technologię.

Osobny obszar to sprawy na styku prawa i technologii. Zewnętrzny CTO powinien sprawdzić, czy firma ma prawa do kodu, za który zapłaciła. W Polsce umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53 ustawy o prawie autorskim), więc sama zapłacona faktura nie wystarczy. Treść umów oceni prawnik, ale CTO wie, o co zapytać: repozytoria, konta w sklepach z aplikacjami, domeny, klucze do podpisywania aplikacji.

Czego nie oczekiwać od fractional CTO

Zewnętrzny CTO nie jest darmowym dodatkowym programistą. Jeśli kupujesz kilka dni w miesiącu, a oczekujesz, że w tym czasie napisze moduł płatności, nie dostaniesz ani modułu, ani strategii.

• Nie zastąpi zespołu developerskiego ani administratora z nocnym dyżurem.
• Nie będzie dostępny o każdej porze, chyba że tak ustalicie w umowie i wycenie.
• Nie podejmie decyzji biznesowych za zarząd. Przygotuje opcje, koszty i ryzyka.
• Nie rozwiąże problemu, o którym nie wie. Potrzebuje dostępu do repozytoriów, dokumentacji, umów i ludzi.

Modele współpracy z zewnętrznym CTO

Określona liczba dni w miesiącu

Najprostszy model: stała liczba dni, w które CTO uczestniczy w planowaniu, przegląda pracę dostawców i rozwija roadmapę. Sprawdza się w firmach ze stałym rozwojem produktu, które nie potrzebują lidera technologicznego na co dzień.

Abonament (retainer)

Stała miesięczna opłata za określony zakres i dostępność, np. udział w cotygodniowym spotkaniu, odpowiedzi na pytania w ustalonym czasie i comiesięczny raport. Zapisz, co wchodzi w abonament, a co jest rozliczane osobno.

Audyt projektu lub druga opinia

Jednorazowe zlecenie z konkretnym wynikiem: audyt kodu i architektury, ocena oferty software house’u, przygotowanie do due diligence. Dobry sposób, żeby sprawdzić współpracę przed dłuższą umową.

Ceny tych modeli zależą od doświadczenia osoby, zakresu i wymaganego czasu reakcji. Porównuj oferty po zakresie odpowiedzialności i rezultatach, a nie wyłącznie po stawce dziennej.

Etatowy CTO, fractional CTO czy tech lead software house’u

Te role się nie wykluczają. Często spotykany układ to software house z własnym tech leadem i zewnętrzny CTO po stronie klienta, który pilnuje, żeby decyzje dostawcy służyły firmie. Jeśli kiedyś zatrudnisz etatowego CTO, dobrze udokumentowana praca poprzednika skróci mu start.

Jak zmierzyć, czy zewnętrzny CTO się opłaca

Ustal miary na początku współpracy, a nie po pół roku. Samo wrażenie, że „jest lepiej”, trudno obronić przy przeglądzie budżetu.

• Przewidywalność dostaw. Czy terminy z planu są dotrzymywane częściej niż wcześniej i czy zmiany zakresu są świadomie zatwierdzane.
• Metryki dostarczania oprogramowania. DORA opisuje m.in. czas od commita do wdrożenia, częstotliwość wdrożeń, odsetek wdrożeń wymagających natychmiastowej interwencji i czas przywrócenia działania po nieudanym wdrożeniu. Obserwuj trend, a nie pojedyncze wartości.
• Koszty. Rachunki za chmurę i licencje, liczba godzin dostawcy przy podobnych zadaniach, koszt poprawek po wdrożeniach.
• Zamknięte ryzyka. Lista problemów z audytu i status każdego z nich: MFA, kopie zapasowe, prawa do kodu, dostępy byłych współpracowników.
• Jakość decyzji. Rejestr decyzji architektonicznych z uzasadnieniem. Po roku widać, które się sprawdziły.

Jeśli zespół korzysta z AI przy code review, specyfikacjach czy testach, CTO powinien sprawdzić, czy to realnie skraca cykl dostarczania. Piszemy o tym w tekście o SDLC z AI.

Czerwone flagi przy wyborze zewnętrznego CTO

• Brak konkretnego zakresu. Oferta „wsparcia technologicznego” bez listy zadań, rezultatów i czasu reakcji.
• Jedna ulubiona technologia na każdy problem. Dobry CTO pyta o model biznesowy, zanim zaproponuje stos.
• Konflikt interesów bez jawnych zasad. Prowizje od polecanych dostawców albo sytuacja, w której ta sama firma ocenia projekt i chce go realizować. Jeśli CTO pochodzi z firmy, która też wykonuje projekty, ustalcie na piśmie, czy może składać ofertę.
• Brak doświadczenia wykonawczego. Ktoś, kto nigdy nie odpowiadał za system produkcyjny, łatwo pisze strategie niemożliwe do wdrożenia.
• Niechęć do dokumentowania. Wiedza zostaje w głowie zewnętrznego CTO, a Ty zamieniasz jedną zależność na inną.
• Obietnice przed audytem. Deklaracje przyspieszenia projektu składane, zanim ktoś zobaczył kod i umowy.

Na pierwszej rozmowie poproś o zanonimizowany przykład raportu z audytu i o plan pierwszych 30 dni. Dobra odpowiedź przypomina plan z tekstu o opanowaniu chaosu w IT: najpierw spis i dostępy, potem priorytety. Rolę zewnętrznego CTO pełnimy także u naszych klientów, a zakres tej usługi opisujemy w sekcji usługi.