I 2014 startede jeg VipKing, en app til at komme ind i Barcelona nightclubs. Vi spinnet senere en del af det ud som Pictus. Ingen gjorde mig rig. Begge lærte mig ting som ti år med engineering jobs ikke havde.
Jeg bringer det op fordi jeg nu tilbringer meget tid i rum hvor en founder og en engineering lead taler forbi hinanden, og grunden til at jeg sædvanligvis kan se gabet er at jeg er været forkert fra begge stole.
Fejl et: Jeg optimerede delen som jeg holdt af
Jeg er ingeniør. Så jeg byggede. Arkitekturen var ren, animationerne var glatte, release-processen var ordentlig. Jeg brugte uger på ting som ingen bruger ville nogensinde bemærke, og jeg følte mig produktiv hele tiden, fordi byggeri er måleligt og salg er ikke.
I mellemtiden blev det faktiske spørgsmål — vil clubejere give adgang til fremmede væk? — utestet i måneder. Det var besvarligt på to uger med et regneark og ti telefonopkald.
Dette er den eneste mest almindelige fejl som jeg ser hos tekniske founders, og den ser aldrig ud som fejl indefra. Den ser ud som fremskridt.
Fejl to: Jeg forvirrede produktet med virksomheden
Appen virkede. Brugere holdt af den. Det føltes som traction. Det var ikke — traction var clubs der fornyede, og clubs fornyede af grunde som næsten intet havde at gøre med softwaren: forhold, timing, om promoteren den måned holdt af os.
Jeg itererede hårdt på en variabel som ikke var begrænsningen. Hvis dit produkt forbedres og intet ændrer, forbedrer du den forkerte ting, og ingen mængde af engineering rigor bliver redde dig.
Fejl tre: Jeg behandlede at løbe tør for penge som et finansproblem
Det er et beslutnings-hastighed-problem. Hver uge brugt på noget som ikke reducerede en rigtig usikkerhed var en uge runway brugt til intet. Jeg tænkte ikke i de termer før det var sent.
Jeg lærte den indramning ordentligt i de to programmer jeg gik gennem det år — Yuzz, Banco Santander's pre-accelerator, og NEXT, Powered by Google for Entrepreneurs. Hvad begge borede var ubehageligt: hvad skulle være sandt for dette til at virke, og hvad er den billigste måde at finde ud? Jeg har skrevet særskilt om hvad disse programmer gjorde rigtigt.
Hver uge som ikke reducerer en usikkerhed er runway brugt på intet.
Lektionen som kostede mig et selskab at lære
Hvad det ændrede om hvordan jeg arbejder
Da jeg senere blev technical lead på produkter med rigtige brugere — en iOS app med over en million downloads blandt dem — bragte jeg tilbage tre vaner som intet engineering job havde lært mig.
- Spørg hvad sker hvis vi tager fejl. Før estimering af noget som helst. Hvis at tage fejl er billigt, ship og find ud. Hvis det er dyrt, gå langsommere. De fleste teams gælder samme rigor til begge, hvilket er spilder i en retning og hensynsløs i den anden.
- Sig business-konsekvensen høut. Ikke "vi skulle refaktorere sync layer'et" men "hvis vi ikke gør, tager hver ny kunde tre uger til onboarding i stedet for en dag." Executives ignorerer ikke teknisk gæld — de bliver fortalt om det på et sprog som giver dem ingen måde at prioritere det.
- Beskyt beslutningen, ikke koden. Smuk kode som implementerer den forkerte beslutning er det dyreste som et engineering team kan producere, og det bliver produceret af gode mennesker hver dag.
Hvorfor alt dette betyder noget for dig
Hvis du er founder uden teknisk baggrund, er personen du mest har brug for ikke den bedste ingeniør du kan give dig. Det er nogen som vil sige dig at det som du spurgte efter ikke er værd at bygge — og som har nok arvæv til at have ret om det.
Hvis du er CTO hvis CEO virker urimelig, optimerer de sædvanligvis en variabel du ikke kan se, på et ur du ikke bliver vist. Det er et oversættelses-problem, ikke et kompetence-problem.
Jeg har været den founder som byggede den forkerte ting omhyggeligt, og ingeniøren som havde ret om koden og forkert om hvad betydede. At have ret fra begge stole er, sådan som jeg kan se det, den eneste måde at lære hvor gabet faktisk er.