2014 gründete ich VipKing, eine App zum Einlass in Barcelonas Nachtclubs. Später spannten wir Pictus aus. Keine der beiden machte mich reich. Beide lehrten mich Dinge, die zehn Jahre Engineering-Jobs nicht getan hatten.
Ich erwähne das, weil ich jetzt viel Zeit in Räumen verbringe, in denen Gründer und Engineering-Lead aneinander vorbeireden — und der Grund, warum ich die Lücke normalerweise sehe, ist, dass ich aus beiden Stühlen unrecht gehabt habe.
Fehler eins: Ich optimierte den Teil, der mir Spaß machte
Ich bin ein Engineer. Also baute ich. Die Architektur war sauber, die Animationen waren flüssig, der Release-Prozess war ordentlich. Ich verbrachte Wochen mit Dingen, die kein Nutzer jemals bemerken würde, und ich fühlte mich die ganze Zeit produktiv, weil Bauen messbar ist und Verkaufen nicht.
Währenddessen — werden Clubbesitzer Einlass an Fremde vergeben? — blieb ungetestet für Monate. Es war in zwei Wochen mit einer Tabellenkalkulation und zehn Anrufen zu beantworten.
Dies ist der häufigste Fehler bei technischen Gründern, und es sieht von innen nie wie ein Fehler aus. Es sieht wie Fortschritt aus.
Fehler zwei: Ich verwechselte das Produkt mit dem Geschäft
Die App funktionierte. Nutzer mochten sie. Das fühlte sich nach Traction an. Es war es nicht — Traction war, dass Clubs erneuerten, und Clubs erneuerten aus Gründen, die fast nichts mit der Software zu tun hatten: Beziehungen, Timing, ob der Promoter des Monats uns mochte.
Ich iterierte heftig über eine Variable, die nicht die Einschränkung war. Wenn das Produkt besser wird und nichts ändert sich, verbessern Sie die falsche Sache, und keine noch so gute Engineering-Strenge wird Sie retten.
Fehler drei: Ich behandelte das Geldproblem als Finanzproblem
Es ist ein Entscheidungsgeschwindigkeitsproblem. Jede Woche mit etwas, das eine echte Unsicherheit nicht reduzierte, war eine Woche Runway für nichts. Ich dachte nicht in diesen Begriffen, bis es zu spät war.
Ich lernte diese Denkweise richtig in den zwei Programmen, die ich dieses Jahr absolvierte — Yuzz, Banco Santanders Pre-Accelerator, und NEXT, Powered by Google for Entrepreneurs. Was beide bohrten, war unangenehm: was müsste wahr sein, damit das funktioniert, und wie findet man das am billigsten heraus? Ich habe separaten darüber geschrieben, was diese Programme richtig gemacht haben.
Jede Woche, die keine Unsicherheit reduziert, ist Runway für nichts ausgegeben.
Die Lektion, die mich ein Unternehmen kostete, zu lernen
Was sich daran änderte, wie ich arbeite
Als ich später Technical Lead auf Produkten mit echten Nutzern wurde — eine iOS-App mit über einer Million Downloads — brachte ich drei Gewohnheiten zurück, die kein Engineering-Job mich gelehrt hatte.
- Frag, was passiert, wenn wir uns irren. Bevor ich etwas schätze. Wenn unrecht sein billig ist, Ship und find heraus. Wenn es teuer ist, verlangsamen. Meiste Teams wenden die gleiche Strenge auf beide an, was in einer Richtung Verschwendung ist und in der anderen fahrlässig.
- Sag die Geschäftskonsequenz laut. Nicht »wir sollten den Sync-Layer refaktorieren«, sondern »wenn wir nicht, dauert jeder neue Kunde drei Wochen zum Onboarding statt einen Tag.« Executives ignorieren nicht technische Schulden — ihnen wird in einer Sprache davon erzählt, die ihnen keine Möglichkeit gibt, sie zu priorisieren.
- Schütz die Entscheidung, nicht den Code. Schöner Code, der die falsche Entscheidung umsetzt, ist das Teuerste, das ein Engineering-Team produzieren kann, und es wird jeden Tag von guten Menschen produziert.
Warum das für Sie wichtig ist
Wenn Sie ein Gründer ohne technischen Hintergrund sind, ist die Person, die Sie am meisten brauchen, nicht der beste Engineer, den Sie sich leisten können. Es ist jemand, der Ihnen sagt, dass das Ding, das Sie fragten, nicht wert ist, gebaut zu werden — und das genug Narbengewebe hat, um recht zu haben.
Wenn Sie ein CTO sind, dessen CEO unbegründet wirkt, optimiert sie normalerweise eine Variable, die Sie nicht sehen können, auf einer Uhr, die Ihnen nicht gezeigt wird. Das ist ein Übersetzungsproblem, kein Kompetenzkomproblem.
Ich war der Gründer, der das falsche Ding sorgfältig baute, und der Engineer, der recht über den Code hatte und falsch über das, was zählte. Aus beiden Stühlen unrecht zu haben ist, soweit ich sehen kann, der einzige Weg, um zu lernen, wo die Lücke wirklich ist.