Come diventare il tuo co-fondatore tecnico e perché vale la pena dedicare il tuo tempo

Nota : questo blog si ispira alla mia recente intervista podcast con Quincy Larson di freeCodeCamp, di cui parliamo negli ultimi 15 minuti circa.

Cerchi un co-fondatore tecnico? Anch'io lo ero. Per molti anni. È stato un viaggio difficile, perché la "saggezza" prevalente è che devi uscire e trovare un co-fondatore tecnico perché tutte le startup di successo li avevano (non vero, tra l'altro). Ma cosa succede quando sei alla fine della tua passerella e la tua scelta è imparare a programmare o smettere?

I co-fondatori tecnici dovrebbero darti la stabilità, il complemento di abilità essenziali e la responsabilità che non sono possibili essendo un fondatore solista. Naturalmente, nessuno sta monitorando gli innumerevoli esempi in cui avere un co-fondatore di spazzatura ha reso il tuo viaggio incommensurabilmente più difficile o ostacolato la tua capacità di progredire del tutto. Ma ovviamente, ciò che "loro" significano è che non hai bisogno solo di un co-fondatore tecnico, hai bisogno del giusto co-fondatore tecnico, duh!

Beh, certo.

Nessuno di questi è un consiglio particolarmente utile. È come dire che devi essere sveglio per avere buone idee (sembra ovvio e intuitivo, ma non sempre vero).

La mia esperienza come fondatore (solista) non tecnico

Ecco cosa ho vissuto personalmente nei tanti anni passati alla ricerca di co-fondatori tecnici:

  1. Ho passato un sacco di tempo a sfogliare forum, LinkedIn e elenchi di contatti alla ricerca di persone che soddisfacessero i criteri minimi
  2. Ho passato molto tempo a non essere in grado di convalidare molto, testare molto, progredire molto perché non avevo nulla da convalidare, testare o progredire se non un passo ben affinato
  3. Ho incontrato molte persone e la maggior parte non era interessata all'imprenditorialità, o non aveva la necessaria etica del lavoro (aka vena masochista)
  4. Ho incontrato molte persone interessate ma per tutte le motivazioni sbagliate (arricchirsi velocemente, gloria, fama ...)
  5. Ho incontrato alcune persone che avevano le giuste motivazioni e (per quanto ne sapevo) le giuste capacità, ma che non avevano la mentalità per sopportare la brutalità dell'avvio
  6. Ho incontrato pochissime persone che avevano sperimentato l'avvio e avevano le capacità, ma nessuna di loro era entusiasta dei miei concetti (inevitabilità statistica)

Sapevo perfettamente che si occupava di software, anche se volevo avviare un'azienda tecnologica. Quindi, ecco i miei errori di allora:

  1. Non avevo idea degli aspetti fondamentali e più basilari del software e del suo design
  2. Ho grossolanamente sottovalutato la complessità coinvolta (non sapevo quanto non sapessi)
  3. Ho grossolanamente sottovalutato il tempo impiegato
  4. Ho grossolanamente sopravvalutato le persone che ho contattato per essere co-fondatori tecnici
  5. Ho notevolmente (ma non consapevolmente) sopravvalutato il mio ruolo nel periodo iniziale: "spacciare" e "sviluppo del business" erano le mie capacità, e non ho apprezzato il fatto che alcune delle startup di maggior successo trascorressero un terzo del loro tempo su queste cose, e la maggior parte del loro tempo costruiscono il prodotto e rispondono alle esigenze dei clienti

Per quasi 4 anni mi sono detto: “ Non ho bisogno di imparare a programmare. I miei talenti si usano meglio altrove ”. Suona familiare?  

È vero solo in parte. Essendo una persona con risorse molto limitate, i miei talenti dovevano essere usati in qualsiasi cosa mi desse le migliori possibilità di successo . Avevo un po 'di soldi da spendere per gli sviluppatori. Avevo del tempo da dedicare alla loro gestione, e quel tempo è stato creato principalmente riducendo l'attività sociale, il sonno e impedendomi i fine settimana. Avevo una preziosa esperienza che potevo usare per mettere insieme un business plan. Avevo forti abilità sociali e capacità di comunicazione che potevo usare per presentare ai potenziali clienti e anche ai potenziali co-fondatori.

Ho fatto tutte queste cose e mi sono avvicinato ai miei obiettivi. Ma ci è voluto troppo tempo. Ovviamente il progresso è sempre lento, sicuramente più lento di quanto vorremmo. Ma rallentiamo ulteriormente noi stessi solo non guardando la situazione in modo obiettivo. Anche quando ho avuto co-fondatori (che alla fine hanno lasciato perché era troppo difficile o le loro circostanze di vita sono cambiate) ho scoperto che la gestione della loro etica lavorativa, delle aspettative e degli stati d'animo richiedeva molto tempo ed energia. Va bene, ma nessuno ha un budget per questo.

Vedete, come aspiranti fondatori, il nostro più grande nemico è tutto ciò che ci fa perdere tempo. Ogni settimana che passa senza risultati, è più probabile che tu smetta. E non sappiamo mai veramente quale sia il nostro costo in termini di tempo quando scegliamo una linea di condotta. E non sappiamo mai quando siamo vittime dell'errore del costo irrecuperabile.

Guardando indietro, mi è costato 4 anni e un bel po 'di soldi. E alla fine, l'unico modo per ricominciare era ripetere quella spesa di tempo, impegno e denaro, facendo la stessa cosa: mettere insieme un piano e poi cercare disperatamente un co-fondatore tecnico.

Ci risiamo…

Una semplice matematica del tempo

Nel 2014 ho letto un blog di Sam Altman, il presidente di YCombinator. In esso, Sam dice alcune delle verità più profonde che abbia mai ignorato. Ecco il tweet che ho scovato per divertimento.

Le prime due o tre volte che ho letto il suo pezzo ho formulato argomentazioni molto sensate sul motivo per cui non si applicava a me. Ho sbagliato e mi è costato dei soldi, ma peggio, mi è costato molto tempo (ho recuperato i soldi).

Fondamentalmente postula che è più veloce ( molto più veloce ) imparare a programmare abbastanza per costruire il tuo prototipo piuttosto che trovare un co-fondatore affidabile e affidabile che sia una buona scelta e andrà lontano. Non solo più veloce, ma le probabilità di progresso sono notevolmente più alte.

È ovvio. Trovare un buon co-fondatore, tecnico o meno, è un compito lungo - come trovare il partner giusto per la vita - e richiede un certo grado di fortuna. Imparare a programmare un po 'è più veloce, non ha bisogno di fortuna e quindi ha una maggiore percentuale di successo.

In effetti puoi smettere di leggere questo blog proprio qui se vuoi. Leggi il suo. È meglio. L'unico motivo per cui scrivo il mio è condividere esperienze dirette e personali che confermano ciò che ha detto. Significa che fino ad oggi il suo blog ha avuto solo ~ 8.500 visualizzazioni, di cui una dozzina sono mie. Questo è molto meno del numero di aspiranti fondatori non tecnici là fuori.

Un'analogia con gli appuntamenti

Al liceo, ricordo che mi è stato detto che se sei disperato per l'affetto di qualcuno, agirai in modi che ti compromettono: i tuoi standard, i tuoi valori e i tuoi migliori interessi. Ti accontenterai di persone, comportamenti e situazioni che non sono giuste per te.

È esattamente lo stesso con la ricerca di co-fondatori. Col passare del tempo e la mia paura e la mia disperazione aumentarono, mi ritrovai a scendere a compromessi, riducendo i miei standard. Negoziare contro me stesso. Trovare scuse per gli altri. Assestamento.

Nel tempo ho preso decisioni sbagliate e compromessi sbagliati. Fortunatamente, nessuna di queste decisioni sbagliate ha portato a rapporti di co-fondazione reali.

Il punto è che ero pronto a fare cattivi compromessi, solo per fare progressi. Questo è un brutto inizio per qualcosa su cui potresti dover trascorrere i prossimi 10-20 anni della tua vita.

Le cose tecniche non finiscono al lancio

È allettante essere tattico e dire che devo solo arrivare al lancio. Questo non è un piano sostenibile. C'è una differenza tra la pianificazione di "rimediare quando arrivo a quel ponte" e il doverlo fare perché la vita non ti ha lasciato scelta.

Ho imparato a mie spese che il mio bisogno di assistenza tecnica è cresciuto dopo il lancio. Pensavo che i cantieri difficili stessero per decollare. Ragazzo, mi sbagliavo. Le cose si rompono. Emergono bug. Le funzionalità non funzionano come previsto. Gli utenti hanno una visione chiara delle cose. L'iterazione è il modo per ottenere l'adattamento al mercato del prodotto. E deve essere rapido, ben coordinato e sistematico. I dati aiutano e molti dati preziosi arrivano dopo il lancio!

Ecco perché pagare per gli sviluppatori non è sostenibile a meno che non si ottengano molti fondi. E non è probabile che tu riceva molti finanziamenti prima ancora di avere un prodotto. È possibile, ma non per la maggior parte dei fondatori.

Quindi cosa farai quando 4 settimane dopo il lancio le cose si rompono, gli utenti segnalano bug imprevisti e il server si arresta in modo anomalo o l'app store ha modificato alcuni criteri? Spendi più soldi. E supplica gli sviluppatori di sbrigarsi. Nel frattempo stai facendo del tuo meglio per trovare utenti, lanciare, vendere, ecc.

Stai spendendo il tuo tempo su cose, di sicuro, e sono importanti. Ma se puoi scegliere tra correggere un bug / aggiungere una funzionalità che i tuoi utenti chiedono a gran voce e presentare il tuo piano aziendale a un potenziale finanziatore di semi, il miglior uso del tuo tempo è il prodotto, non la presentazione. E non puoi farlo perché non sai come. Quindi ti eserciti su cose di secondo ordine perché non puoi esercitarti su cose di fondamentale importanza .

Sviluppare l'empatia tecnica

Come ho detto nel podcast, ero (mortificante) una di quelle persone che ha insistito sul fatto che "è un prototipo semplice e veloce". Mi mancava totalmente, completamente, deplorevolmente, qualsiasi idea di come fosse il processo di sviluppo.

Quincy, il fondatore di freeCodeCamp e colui che gestisce il podcast, lo ha riassunto molto bene:

Ti dà empatia per l'esperienza dello sviluppatore e ti aiuta a fare stime di tempo significative, non solo in termini di ciò che è possibile, ma anche di ciò che è semplice e di ciò che è complesso. [parafrasato]

Immagina se qualcuno che non ha idea del tuo lavoro venga da te e insiste sul fatto che qualcosa che richiede una settimana dovrebbe richiedere 2 giorni - non vorresti dargli una botta in testa e voltare le spalle con disgusto?

Sono seriamente imbarazzato da tutte le volte che l'ho fatto (insisto sul fatto che è una semplice app, non picchiare qualcuno in testa).

Peggio ancora, perché mi avrebbero preso sul serio? Avevo davvero mostrato loro rispetto e impegno cercando almeno di imparare un po 'del loro mestiere? Dal loro punto di vista, mi stavo nascondendo dietro le mie capacità e la ragionevole scusa che la programmazione " non è il miglior uso del mio tempo ".

Ecco un altro sinistro effetto collaterale di non essere abbastanza informato sulle cose tecniche. Non ho mai potuto valutare le capacità relative delle persone con cui ho parlato. Dovevo andare sulla fede, fiducia o raccomandazioni. Non avevo modo di valutare la loro idoneità per lo scopo che avevo bisogno di loro per soddisfare.

Guardando indietro, avrei potuto risparmiare un sacco di soldi e mesi di sforzi, mentre sviluppavo un'abilità che estende la mia pista quasi indefinitamente - se avessi imparato a programmare prima.

Come dice Sam Altman:

"Quando persone come questa dicono" Farò tutto il necessario per rendere questo business di successo "(cosa che dicono quasi sempre), io dico qualcosa come" Perché non imparare a hackerare? "

Perché no davvero. Fa tutto ciò che serve. Soprattutto se aiuta la tua startup a "non morire".

L'ingegneria non è l'essenziale

Nemmeno per un momento penso che la codifica sia la risposta a tutto. Se sei tra coloro che hanno un co-fondatore tecnico, un compagno di classe, un collega, un fratello, ecc. Interessato e totalmente affidabile, allora sì, non è il miglior uso del tuo tempo, perché? Perché hai una grande risorsa in quell'altra persona. Quindi imparare a programmare significa duplicare gli skillset.

Ma quando non hai quella capacità, impararne un po 'è il miglior uso del tuo tempo, se ti fa risparmiare molto tempo a lungo termine. Ecco la matematica che applico:

priorità = probabilità di esito in una data unità di tempo

Così:

Trova un co-fondatore in 6 mesi e inizia a costruire nel 7 ° mese: 50% di probabilità

Impara abbastanza codice in 6 mesi e inizia a costruire nel 7 ° mese: 90%

L'intero articolo sarebbe del tutto ovvio se dicesse che i programmatori devono apprendere le capacità di marketing e comunicazione per lanciare. I programmatori devono uscire dall'edificio e parlare con i propri clienti e non solo con il codice. Questo è ora considerato un consiglio "ovvio".

Allora perché il contrario non è altrettanto ovvio?

Concediti credibilità

Gli ingegneri sono come le ragazze davvero belle al bar. Ottengono "colpiti" tutto il tempo. Vengono contattati tutto il tempo. Non lo so direttamente, ma immagino che si stancherà velocemente, e il cinismo è solo un altro "adorerai la mia idea di avvio".

Sai cosa è rinfrescante per qualcuno con cui chiacchieri in un bar? Interesse e consapevolezza su di loro. Lo stesso vale per i programmatori. Se sei abbastanza consapevole del loro mondo e abbastanza interessato ai dettagli delle loro abilità, risponderanno e, per lo meno, ti aiuteranno.

Questo lo so per esperienza personale. Da quando ho imparato a programmare, ho molti più ingegneri felici di darmi consigli, guidarmi, correggermi e persino immergermi nelle mie idee con me. Non è più facile trovare il co-fondatore giusto , ma questo non ha nulla a che fare con l'esperienza e più a che fare con i loro interessi, priorità e circostanze della vita.

E adesso?

E ora, per la prima volta nella mia vita, sono in una posizione in cui posso sperimentare le mie idee. Prima mi costava tempo e denaro. Ora mi costa un po 'di tempo, e anche allora meno tempo che trovare sviluppatori, negoziare l'ambito, supervisionare il lavoro, rivedere il lavoro, testare il lavoro. E quel tempo è un investimento poiché continuo a migliorare le abilità anche se l'idea si rivela commercialmente non redditizia.

Non sono un grande programmatore. Non credo di aver bisogno di esserlo (forse tra 5 anni rivedrò questa visione). Ma ne so abbastanza per costruire i miei prototipi e capire cosa è coinvolto nella costruzione di un prodotto valido. E ne so abbastanza per rispondere a una chiamata su quali bit esternalizzare, come descrivere ciò che voglio, non farmi prendere per un giro, valutare l'output e collaborare con altri hacker per ottenere risultati. Potrei non essere mai uno sviluppatore professionista, e va bene. Non è di questo che si tratta.

Ma sono diventato il mio co-fondatore tecnico. Potrebbe venire un giorno in cui il miglior uso del mio tempo sono davvero le cose non tecniche. Ma quel giorno verrà quando avrò costruito qualcosa che sta crescendo. Credo di aver aumentato le mie possibilità di trovare quel qualcosa semplicemente perché posso eseguire molti esperimenti più economici, a basso stress, che non mi comportano spendere soldi o chiedere aiuto ad altri.

Tutto questo in meno di 12 mesi. Pensaci. Forse è davvero il miglior uso del tuo tempo se vuoi essere un fondatore.

Postscript Per studenti freeCodeCamp

Credo davvero che le tue risorse più preziose siano il tuo tempo, impegno e denaro. Di queste, l'unica risorsa più importante è il tempo, perché le altre due possono essere rinnovate e recuperate. Quindi, se hai intenzione di dedicare del tempo a qualcosa, assicurati che ti avvicini a questo obiettivo.

Con questo in mente, se vuoi investire 3 ore con me per trovare il tuo percorso più breve per imparare a programmare (specialmente se stai cercando di iniziare), allora vai al mio sito del corso e usa il modulo lì iscriviti (non il popup!). Se aggiungi le parole "FREE MY TIME" al messaggio, saprò che sei un lettore di freeCodeCamp e ti invierò un codice promozionale, perché proprio come te, freeCodeCamp mi ha dato un buon inizio.

Dai un'occhiata al podcast freeCodeCamp rilanciato, in cui Quincy e Abbey usano la loro incredibile esperienza come educatori per mettere insieme contenuti che ti aiuteranno nel tuo viaggio. Recentemente ero all'episodio 53 e alcune delle cose in questo post sono trattate in maggiore dettaglio lì. Puoi anche accedere al podcast su iTunes, Stitcher e Spotify o direttamente da questa pagina.

Posso essere contattato su Twitter: @ZubinPratap