In 2014 startte ik VipKing, een app voor het krijgen van toegang tot Barcelona nachtclubs. Later spinde we een stuk ervan uit als Pictus. Geen van beide maakte me rijk. Beiden leerden me dingen die tien jaar engineering jobs niet hadden.
Ik breng het ter sprake omdat ik nu veel tijd in kamers zit waar een founder en een engineering lead langs elkaar heen praten, en de reden dat ik de gap meestal kan zien is dat ik van beide zetels verkeerd ben geweest.
Fout één: ik optimaliseerde het deel dat ik leuk vond
Ik ben een ingenieur. Dus ik bouwde. De architectuur was schoon, de animaties waren glad, het release process was netjes. Ik besteedde weken aan dingen die geen gebruiker ooit zou zien, en ik voelde me de hele tijd productief, omdat bouwen meetbaar is en verkopen niet.
Ondertussen ging de echte vraag — zullen clubeigenaren entree weggeven aan vreemdelingen? — maanden ongetest. Het was beantwoordbaar in twee weken met een spreadsheet en tien telefoongesprekken.
Dit is de meest voorkomende fout die ik bij technical founders zie, en het ziet er van binnenuit nooit uit als een fout. Het ziet er uit als vooruitgang.
Fout twee: ik verwarder het product met het business
De app werkte. Gebruikers houden ervan. Dat voelde als traction. Het was niet — traction was clubs die vernieuwen, en clubs vernieuwen om redenen die bijna niets met de software te maken hebben: relaties, timing, of de promoter die maand ons mocht.
Ik itereerde hard op een variabel die niet de constraint was. Als je product verbetert en niets verandert, verbeter je het verkeerde ding, en geen hoeveelheid engineering rigour zal je redden.
Fout drie: ik behandelde geldlopers als een finance probleem
Het is een decision-speed probleem. Elke week besteed aan iets dat geen echte onzekerheid reduceerde was een week runway voor niets. Ik dacht niet in die termen tot het laat was.
Ik leerde die framing correct in de twee programma's die ik dat jaar doorging — Yuzz, Banco Santander's pre-accelerator, en NEXT, Powered by Google for Entrepreneurs. Wat beide drilden was oncomfortabel: wat zou waar moeten zijn voor dit om te werken, en wat is de goedkoopste manier om het uit te zoeken? Ik heb apart geschreven over wat die programma's goed deden.
Elke week die geen onzekerheid reduceert is runway verspild aan niets.
De les die me een bedrijf kostte om te leren
Wat het veranderde over hoe ik werk
Toen ik later de technical lead werd op producten met echte gebruikers — een iOS app met over een miljoen downloads onder hen — bracht ik drie gewoonten mee die geen engineering job me had geleerd.
- Vraag wat er gebeurt als we het fout hebben. Voor je iets schat. Als het fout hebben goedkoop is, ship en zoek het uit. Als het duur is, zorg dat je langzaam gaat. De meeste teams passen dezelfde rigour op beide toe, wat verspillend is in één richting en rokeloos in de ander.
- Zeg de business consequence hardop. Niet "we zouden de sync laag moeten refactoriseren" maar "als we het niet doen, duurt onboarding van elke nieuwe klant drie weken in plaats van één dag." Executives negeren technische schuld niet — het wordt hun in een taal verteld die geen manier geeft om het prioriteit te geven.
- Bescherm de beslissing, niet de code. Mooie code die de verkeerde beslissing implementeert is het duurste wat een engineering team kan produceren, en het wordt elke dag door goede mensen geproduceerd.
Waarom dit allemaal voor jou relevant is
Als je een founder bent zonder technical background, is de persoon die je het meest nodig hebt niet de beste ingenieur die je je kunt veroorloven. Het is iemand die je zal zeggen dat het ding dat je vroeg niet de moeite waard is om te bouwen — en die genoeg littekens weefsel heeft om gelijk te hebben.
Als je een CTO bent wiens CEO onredelijk lijkt, optimaliseren ze meestal een variabel die je niet kunt zien, op een klok die je niet wordt getoond. Dat is een vertaal probleem, niet een competentie probleem.
Ik ben de founder geweest die voorzichtig het verkeerde ding bouwde, en de ingenieur die gelijk had over de code en fout over wat ertoe deed. Van beide zetels fout zijn is, voor zover ik kan zien, de enige manier om te leren waar de gap eigenlijk is.