Waarom een CTO in een startup uit de vuurlinie moet blijven

Als Chief Technology Officer (CTO) die met bedrijven heeft gewerkt variërend van jonge startups tot Enterprise Software leveranciers, ben ik het wel gewend vragen te krijgen over wat ik nou precies doe als CTO. Iedere rol in IT heeft zijn specifieke expertise en verantwoordelijkheden, en je kunt nou eenmaal niet verwachten dat iedereen volledig begrijpt wat die van jou zijn.

Laten we eens kijken naar een definitie:

‘A chief technology officer (CTO) […] is an executive-level position in a company or other entity whose occupation is focused on the scientific and technological issues within an organization. […]
A CTO should be aware of new and existing technologies to guide the company’s future endeavours.’ (Wikipedia)

Wat kunnen we hieruit destilleren?
1. Leidinggevende positie (zie de ‘C’ in CTO)
2. Organisatie-breed
3. Toekomstgericht

Hoewel deze definitie te wensen overlaat, ben ik het eens met deze drie punten: een CTO werkt direct met het management team (of de founder/CEO), heeft organisatie-brede scope en is per definitie toekomstgericht.

Mijn persoonlijke definitie zou er ongeveer zo uitzien:

Een CTO zet het beleid uit wat betreft de software-ontwikkeling en heeft een high level, strategische visie op technologie, architectuur, infrastructuur, het software ontwikkelingsproces, compliance en kwaliteitsbewaking.

Operatie versus Strategie

Werken in een beleidspositie, met het management team, of (eerder) met founders of CEO’s betekent dat de rol van CTO strategisch is. Strategisch — dus niet operationeel.

Zo’n zeven jaar geleden, toen ik van Lead Developer & Chief Architect mijn eerste CTO rol aannam, werd van mij verwacht dat ik ook gewoon mijn eerdere rollen bleef vervullen.

Als ik hierop terug kijk kan ik zonder meer zeggen dat dit geen doorslaand succes was. Integendeel, de CTO-rol had zwaar te lijden onder het feit dat ik nog met meer dan één been in een operationele functie stond: Strategisch vooruit kijken is lastig als je operationele verantwoordelijkheden hebt.

Als CTO moet je jezelf de vraag stellen waar je bedrijf in twee tot vijf jaar wil staan, als het gaat om technologie. Als Lead Developer/Architect ben je verantwoordelijk voor de volgende uitrol van de software, en misschien, heel misschien, voor de volgende major release (als dat nog een ding is in tijden van een DevOps-cultuur).

Wat een balanceeract had moeten zijn tussen strategische versus operationele taken werd een reality-check: als je geen ingrijpende maatregelen treft zal je altijd in beslag worden genomen door de waan van de dag.

CTO versus Head of Development/VP of Engineering

De CTO kijkt wel naar operationele zaken, maar heeft er niet de focus op. Terwijl de Head of Development (HoD)- of VP of Engineering (VPE)-rollen volledig bezig zijn met operational excellence, en ervoor zorgen dat zaken op tijd uitgeleverd worden, is de CTO op zoek naar verbeterpunten voor de architectuur, de gebruikte technologie, infrastructuur en processen binnen of een tot vijf jaar.

De HoD/VPE is idealiter een geweldig manager en team builder. ‘On time’ is een lastig concept in een Agile-wereld, maar de HoD/VPE is er verantwoordelijk voor.

De CTO kijkt naar het team (of de teams), maar doet dit meer vanuit een strategisch oogpunt, bijvoorbeeld naar optimalisatie van het agile-proces, het verbeteren van automatische teststraten en continuous delivery, verbetering van de kwaliteit van de code en stimuleren van het delen van technische kennis.

CTO versus Lead Developer

Zoals ik hierboven al uitgelegd heb is het niet handig je Lead Developer de rol van CTO te laten vervullen, behalve misschien in het absolute begin (tijdens ideation- en prototyping fasen) van een startup. De Lead Developer is per definitie volledig gefocust op het issue van de dag, het voorkomen van het introduceren van nog meer technical debt, het volbrengen van de huidige sprint en (junior) developers coachen. Een CTO moet echter zijn of haar betrokkenheid bij operationele zaken beperken, om te voorkomen dat hij in het hogere perspectief verliest.

Bij de vele startups waar ik mee gewerkt heb, heb ik lead devs zien stoeien met CTO-taken als GDPR/AVG, compliance, subsidies, sponsoring, met wisselend succes maar nooit met plezier en betrokkenheid, want lead devs willen code kloppen. Ze zien het onboarden, coachen en helpen van andere devs als noodzakelijk kwaad, want dat haalt ze steeds uit hun flow. Dat geeft hen een gevoel van gemiste productiviteit (of het werkelijk hun productiviteit schaadt is een andere discussie). Dus nog meer niet-code gerelateerde taken erbij hebben maakt de meeste lead devs erg ongelukkig.

Hoe zit het dan met ‘vroege’ startups?

Terwijl ik aan het werk was met mijn ISV Canvas Tech Maturity Survey, is het mij nog eens een stuk duidelijker geworden hoezeer de focus van een CTO varieert in de verschillende stadia van startups (Ideation, Prototyping, MVP, Scaleup en volwassen ISV).

Het is duidelijk dat veel CTO-taken in de vroege fasen minder cruciaal zijn, maar verandert dat de hierboven beschreven situatie als het gaat om jongere startups? Zijn de genoemde issues irrelevant voor early startups?

Ja en nee.

Er spelen andere zaken.

Je lead dev CTO-taken laten vervullen is op de langere duur onhoudbaar. Op een bepaald moment wordt de lead dev zodanig druk, dat de dagelijkse operatie het altijd wint van het strategische. Dat is een wet van Meden en Perzen.

Maar behalve deze glijdende schaal is er nog een andere belangrijke reden om je lead dev niet in eerste instantie in een CTO-rol te zetten: als je je lead dev in eerste instantie laat denken dat hij of zij de CTO is (of in ieder geval de hoogste in rang op technologie) en je besluit later dat je er een CTO boven zet, kan dit tot motivatie- en ergere issues leiden. Ik heb dit meermaals meegemaakt toen ik ingehuurd werd. Mensen houden nou eenmaal niet van het gevoel van degradatie.

Verschillende Belangen

Uit de vuurlinie zijn, en technologie vanuit een wat hoger perspectief bezien, geeft een CTO een betere positie om te kunnen oordelen over wat goed is voor een bedrijf of product. Dit kan bijvoorbeeld te maken hebben met:

• Kosten-efficiëntie
• Toekomstige integraties
• Technologie-trends
• Technische volwassenheid
• Wereldwijde markttrends
• Intellectueel Eigendom

Op al deze terreinen heb ik zaken fout zien lopen bij startups zonder technische co-founders of andere super-seniors, omdat er gewoon niemand was die beslissingen van de lead developer kon challengen.

Oplossingen

Budget is maar al te vaak de hoofdreden voor startups om de rol van CTO in eerste instantie niet te beleggen. De MVP opleveren kost al genoeg, en een dure C-level positie invullen wordt uitgesteld.

De ervaring die een CTO kan inbrengen in een (jonge) startup kan echter niet onderschat worden. Een CTO brengt gemiddeld 15+ jaar ervaring met software-ontwikkeling mee, heeft de verschillende startup-stadia meermaals doorlopen, heeft een goed beeld van (Native) Cloud technologie, en kent de principes als de Lean Startup en Design Thinking.

Ook kan een CTO vaak beter dan anderen afwegingen maken op het gebied van build-or-buy, vanuit het perspectief van intellectueel eigendom (focussend op het opbouwen van waarde in de startup en rekening houdend met je exit strategie).

Strategisch Advies

Als je niet het oneindige geluk hebt een seriële tech co-founder binnengehaald te hebben, en je hebt, zoals de meeste startups, niet het budget om een C-level executive op de loonlijst te kunnen zetten, overweeg dan eens andere opties:

Er is een groeiend aantal parttime CTO-proposities. Ervaren professionals die er hun specialisatie van gemaakt hebben om korte- of middellange termijn strategisch advies aan startups te bieden, Native Cloud-architecturen op te zetten, nearshoring teams in te huren, SaaS best practices kennen, en in principe alles bieden wat een interne CTO zou doen, maar dan als dienstverlening.

Al is het maar voor een paar uur per week, deze extra ervaring van een door de wol geverfde CTO helpt, bijvoorbeeld bij technologische besluitvorming, het vinden en verbeteren van de zwakke plekken in je architectuur, optimaliseren van de Cloud-fit, of op een andere manier de kwaliteit van team, proces en product te verbeteren.

Lees ook: Hoe je als startup een geweldige SaaS-app bouwt met een beperkt budget

Foto: Bongkarn Thanyakij | Pexels