Prvih 90 dni Fractional CTO sodelovanja

Večina ustanoviteljev, ko prvič vpraša o fractional CTO sodelovanju, postavi isto vprašanje na dva načina. Najprej: “ali ga sploh potrebujem?” — na kar sem ločeno odgovoril v fractional CTO ali redno zaposlen CTO. Skoraj takoj zatem pa: “v redu, ampak kaj pa dejansko POČNEŠ?”

Na drugo vprašanje je težje odgovoriti abstraktno. Zato sem nehal poskušati. Najbolj iskren način, kako lahko opišem vlogo, je, da pokažem, kako se prvih 90 dni dejansko odvija, kajti 90-dnevni onboarding je trenutek, ko delo postane konkretno. Vidiš codebase. Sediš z ekipo. Dotakneš se cloud računa. Do konca tega obdobja ustanovitelj diagnozi ali zaupa dovolj, da gremo naprej, ali pa ne — in oba izida sta koristna.

Tukaj je grobi prerez tistih 90 dni.

1.–2. teden: Audit, ne nasveti

Največja napaka, ki jo lahko naredi nov fractional CTO, je, da se v prvem tednu pojavi z mnenji. Še nisi jih zaslužil. Ne veš, o katerih kompromisih je obstoječa ekipa že debatirala, katere omejitve so prišle iz klica z investitorjem, na katerem te ni bilo, ali katero ključno odločitev je sprejel nekdo, ki je odšel.

Zato sta prva dva tedna diagnostična, ne preskriptivna. Prosim za read-only dostop do repozitorija, read dostop do cloud konzole, seznam vendorjev in koledar. Sedim na standupih, ne da bi govoril. Naredim 1:1 z vsakim inženirjem — običajno 30 minut, včasih dlje, če želijo izpustiti paro — in vsem postavim ista tri vprašanja: kaj te muči že mesece?, kaj bi popravil, če te nihče ne bi gledal? in kaj si želiš, da bi ustanovitelj razumel o codebasu?

Vmes berem. Sprehod skozi codebase: kako je repozitorij strukturiran, kakšen je deploy pipeline, kje so očitne pasti. Infra: koliko okolij, kaj se auto-scala, kaj je single point of failure. Seznam vendorjev: vsak ponavljajoči se strošek, kaj počne, kdo se je nanj naročil.

Pri CryptoUnity je audit faza razkrila 32 varnostnih problemov, ki jih je bilo treba rešiti pred lansiranjem — nobenega ekipa ni skrivala, vsi pa so bili nevidni od zunaj. To je vrednost prvih dveh tednov: najdeš stvari, o katerih nihče ne govori, ker danes ne gorijo. Deliverable ob koncu drugega tedna ni strateški deck. Je pisna diagnoza. Točke. Brutalno iskrene.

3.–4. teden: Kam gre denar

Ko diagnoza obstaja, je druga stvar, ki jo pogledam, poraba. Skoraj vsak startup, ki sem ga auditiral, je imel 30–60 % izgube pri razvojnih orodjih, cloudu in SaaS naročninah. Ne zato, ker bi bil kdorkoli neodgovoren — ker nihče ni imel časa pogledati vsega skupaj naenkrat, posamezne postavke pa vedno izgledajo razumne v izolaciji.

Taktika je nezanimiva: ena sama preglednica vsakega mesečnega ponavljajočega se stroška, označenega na enega od treh načinov. Critical — če bi se to jutri izklopilo, se produkt zlomi. Nice-to-have — uporabno, a bi preživeli brez njega. Cancelled — plačujemo, a dejansko ne uporabljamo, ali pa nadomestljivo z nečim, kar je že na critical seznamu.

To običajno vzame eno delovno sejo z ustanoviteljem in glavnim inženirjem, ker ustanovitelj ve, kaj je bilo komercialno obljubljeno, inženir pa, kaj je dejansko priklopljeno. Output je številka: koliko mesečnega burna lahko vrnemo v naslednjih 30 dneh, ne da bi karkoli zlomili.

Majhen primer: pri Adriatic Investors smo med sodelovanjem konsolidirali dve spletni mesti na enega gostitelja. Nobena junaška arhitekturna sprememba — samo ena tistih stvari, ki je bila očitno pravilna, ko je obe strani imela ista ekipa, in ki je takoj znižala mesečni račun. Dolgočasno. Resničen denar.

5.–8. teden: Arhitekturni pogovor

Do 5. tedna imam dovolj konteksta, da imam dejansko mnenje. To je del sodelovanja, kjer si zaslužim plačo, in zelo namenoma se trudim biti previden, ker so arhitekturne odločitve, sprejete v pre-seed ali seed fazi, tiste, ki jih ustanovitelji boleče refaktorirajo v Series A.

Pogovori v tem oknu so tisti, zaradi katerih izgubljam spanec:

• Monolit vs servisi. V tvoji fazi skoraj vedno monolit. Ekipa ni dovolj velika, da bi plačala operacijski davek servisov, in domnevni scaling problem ni tvoje pravo ozko grlo.
• Build vs buy. Auth, plačila, email, iskanje — buy. Stvari, ki so tvoj moat — build. Ustanovitelji to dosledno postavljajo narobe in gradijo dolgočasne stvari, ker se zdijo kot “pravi engineering”.
• Kaj migrirati zdaj in kaj pustiti pri miru. Skušnjava po prepisovanju je vedno tu. Najpogosteje je odgovor: pusti, instrumentaliziraj, dotikaj se le delov, ki blokirajo naslednjih 12–18 mesecev produkta.
• Odločitve o podatkovnem modelu. Najtežja kategorija za razveljavitev. Če bomo sprejeli odločitev, ki je čez dve leti ne bom obžaloval, je to tu.

Pri GetThrivin je bil vstop v scaling fazi, kar je pomenilo, da arhitekturne odločitve niso bile teoretične — že so se izvajale pod resnično obremenitvijo. To je drugačen okus istega pogovora: manj “ali bi?” in več “zdaj, ko se je zlomilo pod prometom, kakšen je najmanjši pravilen popravek?”. Ne glede na okus je deliverable v tem oknu enak: pisni arhitekturni memo z odločitvijo, kompromisom in alternativami, ki sem jih zavrnil, in razlogom zakaj. Ustanovitelji bi morali ta memo lahko predali naslednjemu CTO-ju, ta pa razumeti klic.

9.–12. teden: Pripravljenost na zaposlovanje in plan predaje

Do tretjega meseca se je oblika sodelovanja razkrila in običajno je ena od dveh oblik.

Bridge sodelovanje. Fractional je začasna zapolnitev za rednega CTO-ja, ki še ni bil zaposlen. V tem primeru v 9.–12. tednu pišem JD za bodočega rednega, oblikujem interview rubric in pripravim 30/60/90 plan, ki ga bo izvedel, ko se priključi. Običajno z ustanoviteljem peljem prvi dve rundi rekrutacijskega loopa, nato se umaknem, ko gre ponudba ven.

Stalni fractional. Ustanovitelj se je odločil, da rednega še ne potrebuje, in sodelovanje se nadaljuje v četrtletnem ritmu. V tem primeru v 9.–12. tednu zaklenemo OKR-je za naslednje četrtletje, se dogovorimo za tedenski ritem (prisotnost na standupih, kadenca arhitekturnih pregledov, board prep) in postavimo pravila eskalacije — kaj gre kot Slack sporočilo, kaj kot klic isti dan.

Obe obliki sta veljavni. Ustanovitelj izbere glede na to, kaj dejansko potrebuje, ne glede na to, kar zveni bolj impresivno. Imam rahel nagib k bridge modelu, ker so čiste predaje bolj zdrave od odprtih retainerjev, vendar sem peljal veliko stalnih fractional sodelovanj, kjer matematika preprosto ni opravičila rednega zaposlovanja.

Česar NI v prvih 90 dneh

Vredno je biti glede tega eksplicitno jasen, ker se pričakovanja postavljajo narobe.

• Ne: pisanje produkcijske kode. Včasih to počnem, če obstaja zelo specifična vrzel in je hitreje, kot bi nekoga informiral. Ampak to ni delo, in če kodiram več kot nekaj ur na teden, je nekaj narobe zastavljeno.
• Ne: zamenjava tvojega senior inženirja. Dober fractional naredi tvojega senior inženirja bolj učinkovitega, ne odvečnega. Če se počuti spodkopanega, bo sodelovanje propadlo, ne glede na to, kaj dostavim.
• Ne: strateški prezentacijski deck. Pišem memote. Medij je pomemben — deck je za prodajo, memo je za odločanje.
• Ne: brezplačni nasveti na discovery klicu. Sodelovanje se začne s pogodbo, scopeom in osnovno tedensko obvezo ur. Z veseljem opravim brezplačni diagnostični klic, a v trenutku, ko dejansko delamo, je plačano.

Zaključek

90 dni je pravi format za to vrsto sodelovanja, ker je dovolj dolgo, da se dejansko diagnosticira — ekipa pride mimo vljudne faze, cloud račun pride dvakrat, arhitektura se sama stress-testira ob resničnem sprintu — in dovolj kratko, da je reverzibilno, če fit ni pravi. Oba se lahko na koncu poslovita brez ran.

Če razmišljaš o fractional CTO sodelovanju, rezerviraj brezplačen 30-minutni diagnostični klic. Brez pitch decka.