7 valkuilen voor een CTO

Een goede software engineer zijn is één ding, een goede CTO zijn een ander.

Dat gaat niet alleen over het feit dat een CTO wat meer "soft skills" nodig heeft, maar ook de technische kant van de job van CTO is anders dan die van een software engineer. Waar een software engineer graag naar de technische perfectie streeft, is het aan de CTO om een balans te vinden tussen die technische perfectie en de resources (tijd en geld) die daarvoor nodig zijn.

Bij mijn opdrachten bij groeiende techbedrijven heb ik bijvoorbeeld volgende valkuilen al mogen meemaken. Valkuilen die vanuit een technisch oogpunt perfect verdedigbaar zijn, maar die onzinnig zijn als je rekening houdt met de beperkingen die er zijn. Daarbij vind je ook wat tips om die valkuilen te vermijden.

1. Alles automatiseren van de eerste keer

De software moet het werk doen. Dan is het toch logisch dat je voor alles software schrijft?

Sommige techbedrijven zijn zo overtuigd dat (zelf geschreven) software de oplossing voor alles is, dat ze het grote plaatje vergeten. Zo heb ik al productbedrijven gezien die het absoluut noodzakelijk vonden dat hun systeem van bij de launch de facturen naar hun klanten automatisch zouden gegenereerd en verstuurd worden. Tot ze bij de launch merkten dat ze ... twee klanten per maand hadden. Die twee facturen hadden ze echt wel met Word kunnen aanmaken. Zo hadden ze drie maanden eerder kunnen lanceren.

Een nog schrijnender voorbeeld was een marktplaats-platform: aanbieders en afnemers moesten elkaar vinden op dat platform, om zo met elkaar zaken te doen. De startup had een heel algoritme uitgewerkt om de matching tussen die twee partijen te doen, zodat elke afnemer zeker met de juiste aanbieder in contact zou komen. Daar werkten ze zes maanden aan. Een maand na hun lancering hadden ze ... één aanbieder en drie afnemers. Wellicht hadden ze beter wat vroeger gelanceerd, en meer nagedacht over hoe ze mensen naar hun platform konden trekken.

Wat kan je hieruit leren? Valideer eerst de user-facing delen. Alles wat backoffice is, kan je met de hand doen tot het pijn doet. Dit heeft als groot voordeel dat je ook goed weet wààr het pijn doet, en dat je weet waar je eerst moet gaan automatiseren. De tijdsbesparing die dit oplevert, maakt dat je veel vroeger van je klanten gaat leren waar het bij hén pijn doet, en welk probleem je bij hen moet oplossen.

2. Alles in één keer specifiëren, en denken "als dat er is, is het af"

Wat is er zaliger voor een software engineer om te kunnen werken aan software die van naaldje tot draadje gespecifieerd is? Je moet niet meer nadenken over wat je doet of waarom je doet - alles staat in dat prachtige document dat je product manager geschreven heeft.

Helaas: zo'n document heeft nog nooit bestaan, en zal ook nooit bestaan. Tijdens het ontwikkelen van software moet je duizenden beslissingen nemen; daarvoor moet je weten waarom je aan het maken bent wat je maakt. Bovendien is die product manager ook God niet; zij zal ook foute veronderstellingen maken, die pas kunnen afgetoetst worden door de software in de handen van gebruikers te geven. De software die je bouwt, gaat dus voortdurend aangepast worden aan de nieuwe inzichten die je bedrijf opbouwt. En dan hebben we het nog niet eens over de externe omstandigheden: de situatie op de markt verandert, je klanten vragen plots dingen waar je nooit aan gedacht had, ...

Als CTO weet je dat je software nooit "af" is. Ook Facebook programmeert nog elke dag aan haar software, en meer dan ooit tevoren.

3. Alles geheim houden "tot het klaar is"

"We gaan nu nog niemand vertellen waar we mee bezig zijn, want wie weet kopieert onze concurrent dat dan wel." De waarheid is dat, als die concurrent steeds alles van jullie kopieert, hij altijd tweedes komt. En de tweede kan nooit de marktleider zijn :)

Een jammerlijk gevolg van deze houding is echter dat je ook geen feedback krijgt van je klanten tot het "af" is (en software is nooit "af", zie hierboven). Dat maakt dat je pas heel laat weet of die feature waar je maanden aan gezwoegd hebt, wel iets waard is voor je klanten. Misschien heb je net heel veel tijd en geld gespendeerd aan iets waar niemand op zat te wachten!

4. Niets door gebruikers laten testen

Dit is soms – maar niet altijd – het gevolg van de vorige valkuil. Sommige CTOs denken dat ze hun gebruikers door en door kennen - met soms desastreuze gevolgen.

Weet je nog, dat marktplaats-platform van hierboven? Zij die zes maanden gespendeerd hadden aan het schrijven van een matching algoritme? Toen ze merkten dat ze weinig registraties op hun platform kregen, voerden ze toch eens gebruikerstesten uit. Tien mensen werden uitgenodigd om hun platform te gebruiken. Wat bleek? Van die tien waren er ... nul die door het registratieproces geraakten. Een proces dat heel simpel leek voor een software engineer, bleek onoverkomelijk ingewikkeld voor hun doorsnee gebruikers.

In een techbedrijf is gebruikersfeedback goud. Zorg dat je hun feedback krijgt.

5. Bouwen voor 1 miljoen gebruikers wanneer je er nog geen 10 hebt

Ik spreek wel eens met een CEO van een techbedrijf. Een veel gehoorde verzuchting is "alles duurt toch altijd zo lang. We zijn helemaal nog niet zo groot, en toch duren simpele aanpassingen weken. Hoe komt dat toch?" Wanneer ik dan met de CTO ga praten, verzucht ie "De CEO denkt dat alles zo simpel is. Maar zo simpel is het allemaal niet. We moeten er rekening mee houden dat we over vijf jaar 1 miljoen gebruikers zullen hebben. Het feit dat we op dit moment maar 10 gebruikers hebben, mag ons niet verblinden."

Eh... Het is natuurlijk mooi om te dromen van 1 miljoen gebruikers. Maar als je er nu maar 10 hebt, kan je dan niet beter je energie steken in het zoeken naar manieren om van die 10 20 te maken?

Een goede CTO is in staat om continu de afweging te maken tussen quick-and-dirty en perfect-en-nooit-af.

6. Outsourcen naar een agency zonder dat je iemand hebt die het software development proces kent en kan opvolgen

Voor sommige startups is het moeilijk tot onmogelijk om zelf een software-team uit te bouwen. Wanneer je bedrijf begint door te groeien, ga je hier toch werk van moeten maken (de software zijn de kroonjuwelen van je bedrijf - die besteed je niet uit!), maar het kan gebeuren dat je in de beginfase met een extern agency werkt.

Eén van de grootste fouten die je kan maken, is alle beslissingen rond software over te laten aan het agency. Een agency kent je business niet door en door. Daardoor is een agency niet in staat om de afweging tussen quick-and-dirty en perfect-en-nooit-af te maken.

Zorg dat je iemand "aan jouw kant" hebt die technisch genoeg onderlegd is om het agency op te volgen en uit te dagen. Om eens een analogie uit de bouwsector te gebruiken: ook een bouwheer gebruikt een architect om de aannemer op te volgen.

7. Analysis paralysis

Ik heb al menig beginnend CTO in deze val weten trappen. Om toch maar zeker de juiste keuze te maken, worden heel veel alternatieven naast elkaar gelegd en bestudeerd. Elk alternatief blijkt voor- en nadelen te hebben, en dus wordt er verder gezocht naar een oplossing die enkel voordelen heeft. Die oplossing blijkt dan toch weer nadelen te hebben, die een andere oplossing niet heeft... Je ziet een CTO zo vaak in een vicieuze cirkel van onbeslistheid terecht komen.

Een goede CTO weet: elke beslissing heeft voor- en nadelen. Je moet natuurlijk een afweging maken, maar ga niet op zoek naar de perfecte oplossing. Die bestaat immers niet – en hoe langer je ernaar op zoek gaat, hoe langer het duurt voor je gebruikers je product kunnen uitproberen. Durf te beslissen. Misschien moet je die beslissing later bijsturen, maar dat is vaak beter dan niet te beslissen.

Het draait allemaal om evenwicht

Zoals je ziet, de job van CTO draait niet enkel om technische perfectie. Ze draait om het vinden van een evenwicht tussen technische perfectie en gebruik van middelen. Dat is het verschil tussen een goede software engineer en een goede CTO. Train jezelf om dat onder de knie te krijgen.