Sådan bliver du din egen tekniske medstifter - og hvorfor det er din tid værd

Bemærk : denne blog er inspireret af mit nylige podcast-interview med freeCodeCamps Quincy Larson, hvor vi taler om dette i de sidste 15 minutter eller deromkring.

Leder du efter en teknisk medstifter? Jeg var også. I mange år. Det var en vanskelig rejse, fordi den fremherskende “visdom” er, at du skal ud og finde en teknisk medstifter, fordi alle de succesrige startups havde dem (forresten ikke sandt). Men hvad sker der, når du er ved enden af ​​din landingsbane, og dit valg er at lære at kode eller afslutte?

Tekniske medstiftere formodes at give dig stabilitet, supplement til vigtige færdigheder og ansvarlighed, der ikke er mulig at være en solo-grundlægger. Selvfølgelig er der ingen, der sporer de utallige eksempler, hvor det at have en affalds medstifter gjorde din rejse umådeligt sværere eller modvirket din evne til at komme videre. Men selvfølgelig, hvad "de" betyder er, at du ikke behøver bare en teknisk medstifter, du har brug for den rigtige tekniske medstifter, duh!

Jamen selvfølgelig.

Intet af dette er særlig nyttigt råd. Det er som at sige, at du skal være vågen for at have gode ideer (synes åbenlyst og intuitivt, men ikke altid sandt).

Min erfaring som ikke-teknisk (solo) grundlægger

Her er hvad jeg personligt har oplevet i de mange år, jeg brugte på at lede efter tekniske medstiftere:

  1. Jeg brugte masser af tid på at søge på fora, LinkedIn og kontaktlister på udkig efter folk, der opfyldte minimumskriterierne
  2. Jeg brugte meget tid på ikke at være i stand til at validere meget, teste meget, gå meget, fordi jeg ikke havde noget at validere, teste eller udvikle andet end en veludviklet tonehøjde
  3. Jeg mødte mange mennesker, og de fleste var ikke interesserede i iværksætteri eller havde ikke den nødvendige arbejdsmoral (aka masochistisk stribe)
  4. Jeg mødte en masse mennesker, der var interesserede, men for alle de forkerte motiver (bliv rig hurtig, ære, berømmelse ...)
  5. Jeg mødte et par mennesker, der havde de rigtige motiver og (så vidt jeg kunne fortælle) de rigtige færdigheder, men som ikke havde mentaliteten til at modstå brutaliteten ved opstart
  6. Jeg mødte meget få mennesker, der havde oplevet opstart og havde færdighederne, men ingen af ​​dem var begejstrede for mine begreber (statistisk uundgåelighed)

Jeg vidste diddly squat om software, selvom jeg ville starte et teknologivirksomhed. Så her er mine fejl fra dengang:

  1. Jeg havde ingen anelse om de grundlæggende, mest basale aspekter af software og dets design
  2. Jeg undervurderede groft den involverede kompleksitet (vidste ikke hvor meget jeg ikke vidste)
  3. Jeg undervurderede den involverede tid groft
  4. Jeg overvurderede groft de mennesker, jeg henvendte mig til for at være tekniske medstiftere
  5. Jeg overvurderede markant (men ikke bevidst) min rolle i den indledende periode - "hustling" og "forretningsudvikling" var mine færdigheder, og jeg værdsatte ikke, at nogle af de mest succesrige startup-virksomheder brugte en tredjedel af deres tid på disse ting, og det meste af deres tid med at opbygge produktet og reagere på kundernes behov

I næsten 4 år fortalte jeg mig selv ” Jeg har ikke brug for at lære at kode. Mine talenter bruges bedre andre steder ”. Lyder det velkendt?  

Det er kun delvist sandt. Som en person med meget begrænsede ressourcer skulle mine talenter bruges på det, der gav mig den bedste chance for at få succes . Jeg havde nogle ekstra kontanter, jeg kunne bruge på udviklere. Jeg havde noget tid, jeg kunne bruge til at styre dem, og den tid blev hovedsageligt skabt ved at skære ned på social aktivitet, sove og ikke tillade mig selv weekender. Jeg havde værdifuld erfaring, jeg kunne bruge til at sammensætte en forretningsplan. Jeg havde stærke sociale færdigheder og kommunikationsevner, som jeg kunne bruge til at opsige til potentielle kunder og også til potentielle medstiftere.

Jeg gjorde alle disse ting og kom tættere på mine mål. Men det tog alt for meget tid. Selvfølgelig går fremskridt altid langsomt, bestemt langsommere, end vi gerne vil. Men vi sænker os kun yderligere ved ikke at se på situationen objektivt. Selv da jeg havde medstiftere (som til sidst stoppede, fordi det var for svært eller deres livsforhold ændrede sig), fandt jeg, at det at tage deres arbejdsmoral, forventninger og stemninger tog meget af min tid og energi. Det er ok - men ingen budgetterer for det.

Du ser, som håbefulde grundlæggere, at vores største fjende er noget, der får os til at miste tid. Med hver uge, der går uden resultater, er du mere tilbøjelig til at holde op. Og vi ved aldrig rigtig, hvad vores tidsomkostninger er, når vi vælger et handlingsforløb. Og vi ved aldrig, hvornår vi er ofre for den mistænkte fejl.

Når jeg ser tilbage, kostede det mig 4 år og en hel del penge. Og i slutningen af ​​det var den eneste måde at starte på igen at gentage udgifterne til tid, kræfter og penge, ved at gøre det samme - sammensætte en plan og derefter desperat på udkig efter en teknisk medstifter.

Så går det løs igen…

En simpel tidsmatematik

I 2014 læste jeg en blog af Sam Altman, præsident for YCombinator. I det siger Sam nogle af de mest dybe sandheder, jeg nogensinde har ignoreret. Her er det tweet, som jeg gravede for sjov.

De første to eller tre gange, jeg læste hans stykke, fremsatte jeg virkelig fornuftige klangende argumenter for, hvorfor det ikke gjaldt mig. Jeg tog fejl, og det kostede mig penge, men værre, det kostede mig meget tid (jeg tjente pengene tilbage).

Han hævder dybest set, at det er hurtigere ( meget hurtigere ) at lære at programmere nok til at opbygge din prototype, end det er at finde en pålidelig, pålidelig medstifter, der passer godt og vil gå afstanden. Ikke bare hurtigere, men oddsene for fremskridt er langt højere.

Det er klart. At finde en god medstifter, teknisk eller på anden måde, er et langskud - som at finde den rigtige partner for livet - og kræver en vis grad af held. At lære at kode lidt er hurtigere, behøver ikke held og har derfor en højere succesrate.

Faktisk kan du stoppe med at læse denne blog lige her, hvis du vil. Læs hans. Det er bedre. Den eneste grund til, at jeg skriver min, er at dele direkte, personlige oplevelser, der bekræfter, hvad han sagde. Det fortæller, at hans blog til dato kun har haft ~ 8.500 visninger - hvoraf et dusin er mine. Det er meget mindre end antallet af håbefulde ikke-tekniske grundlæggere derude.

En dating-analogi

I gymnasiet husker jeg, at jeg fik at vide, at hvis du er desperat efter andres følelser, vil du handle på måder, der kompromitterer dig selv - dine standarder, dine værdier og dine bedste interesser. Du vil nøjes med mennesker, adfærd og situationer, der ikke passer til dig.

Det er nøjagtigt det samme med at lede efter medstiftere. Efterhånden som tiden gik, og min frygt og desperation steg, fandt jeg mig selv at gå på kompromis - reducere mine standarder. Forhandler mod mig selv. Undskyldninger for andre. Afregning.

Over tid tog jeg dårlige beslutninger og dårlige kompromiser. Heldigvis resulterede ingen af ​​disse dårlige beslutninger i faktiske medstifterforhold.

Min pointe er, at jeg var parat til at indgå dårlige kompromiser, bare for at gøre fremskridt. Det er en dårlig start på noget, som du muligvis skal bruge de næste 10-20 år af dit liv på.

De tekniske ting slutter ikke ved lanceringen

Det er fristende at være taktisk og sige, at jeg bare skal komme i gang. Det er ikke en bæredygtig plan. Der er forskel på at planlægge at "gøre det op, når jeg kommer til broen", og at skulle gøre det, fordi livet efterlod dig intet valg.

Jeg lærte på den hårde måde, at mit behov for teknisk hjælp voksede efter lanceringen. Jeg troede, at de hårde værfter kom i gang. Dreng, tog jeg fejl. Ting går i stykker. Bugs dukker op. Funktioner fungerer ikke som forventet. Brugere har stærke synspunkter på tingene. Iteration er måden at opnå produkt-markedstilpasning. Og det skal være hurtigt, velkoordineret og systematisk. Data hjælper, og mange værdifulde data kommer efter lanceringen!

Det er derfor, at betale for udviklere ikke er bæredygtigt, medmindre du har masser af finansiering. Og du vil sandsynligvis ikke få masser af finansiering, før du endda har et produkt. Det er muligt, men ikke for de fleste grundlæggere.

Så hvad skal du gøre, når 4 uger efter lanceringen går tingene i stykker, brugerne rapporterer om uventede fejl, og serveren styrtede ned, eller hvis appbutikken har ændret en eller anden politik? Du bruger flere penge. Og bed udviklerne om at skynde sig. I mellemtiden gør du dit bedst for at finde brugere, pitch, sælge osv.

Du bruger helt sikkert din tid på ting, og de er vigtige. Men givet et valg mellem at rette en fejl / tilføje en funktion, som dine brugere klager på, og at kaste din forretningsplan til en potentiel frøfinansierer, er den bedste brug af din tid produkt, ikke tonehøjden. Og du kan ikke gøre det, fordi du ikke ved hvordan. Så du anstrenger dig for ting af andenordens konsekvens, fordi du ikke kan anstrenge dig for ting af altafgørende betydning .

Udvikling af teknisk empati

Som jeg nævnte på podcasten, var jeg (mortifyingly) en af ​​de mennesker, der insisterede på, at "det er en simpel, hurtig prototype". Jeg manglede totalt, fuldstændig, sørgeligt noget koncept for, hvordan udviklingsprocessen er.

Quincy, grundlæggeren af ​​freeCodeCamp og den, der driver podcasten, opsummerede det meget godt:

Det giver dig empati for udvikleroplevelsen og hjælper dig med at foretage meningsfulde tidsestimater, ikke kun med hensyn til hvad der er muligt, men også hvad der er ligetil og hvad der er komplekst. [omskrevet]

Forestil dig, at hvis nogen, der ikke har nogen anelse om dit arbejde, kommer til dig og insisterer på, at noget, der tager en uge, skal tage 2 dage - ville du ikke banke dem i hovedet og bare vende dig væk med afsky?

Jeg er alvorligt flov over alle de gange, jeg gjorde dette (insisterer på, at det er en simpel app, ikke banke nogen i hovedet).

Endnu værre, hvorfor skulle de tage mig alvorligt? Havde jeg virkelig vist dem respekt og engagement ved i det mindste at prøve at lære lidt af deres håndværk? Fra deres synspunkt gemte jeg mig bag mine færdigheder og den rimelige undskyldning for, at kodning " ikke er den bedste brug af min tid ".

Her er en anden uhyggelig bivirkning ved ikke at være vidende nok om de tekniske ting. Jeg kunne aldrig evaluere de relative færdigheder hos de mennesker, jeg talte med. Jeg var nødt til at fortsætte med tro, tillid eller anbefalinger. Jeg havde ingen måde at vurdere deres egnethed til netop det formål, jeg havde brug for, at de skulle opfylde.

Når jeg ser tilbage, kunne jeg have sparet mig masser af penge og måneders indsats, mens jeg byggede en færdighed, der udvider min landingsbane næsten uendeligt - havde jeg lært at kode tidligere.

Som Sam Altman siger:

"Når folk som dette siger" Jeg vil gøre alt, hvad der kræves for at gøre denne forretning vellykket "(som de næsten altid siger), siger jeg noget som" Hvorfor ikke lære at hacke? "

Hvorfor ikke? Gør hvad det kræver. Især hvis det hjælper din opstart med "ikke at dø".

Ingeniørarbejde er ikke alt for alt

Ikke et øjeblik tror jeg kodning er svaret på alt. Hvis du er blandt dem, der har en interesseret og fuldstændig pålidelig teknisk medstifter, klassekammerat, kollega, søskende osv., Så ja, det er ikke den bedste brug af din tid - hvorfor? Fordi du har en stor ressource i den anden person. Så at lære at kode er at duplikere skillsets.

Men når du ikke har den dygtighed, er det den bedste udnyttelse af din tid at lære lidt af det, hvis det sparer dig meget tid i det lange løb. Her er den matematik, jeg anvender:

prioritet = sandsynlighed for resultat i en given tidsenhed

Så:

Find en medstifter om 6 måneder, og start byggeriet i 7. måned: 50% sandsynlighed

Lær nok kode om 6 måneder og start build i 7. måned: 90%

Hele denne artikel ville være helt indlysende, hvis den sagde, at kodere har brug for at lære marketing og kommunikationsevner til at tonehøjde. Kodere har brug for at komme ud af bygningen og tale med deres kunder og ikke bare kode. Dette betragtes nu som "indlysende" råd.

Så hvorfor er ikke det modsatte lige så indlysende?

Giv dig selv troværdighed

Ingeniører er som den rigtig flinke pige i baren. De bliver "ramt" hele tiden. De bliver kontaktet hele tiden. Jeg ved det ikke direkte, men jeg gætter på, at det bliver hurtigt træt, og kynisme bare er endnu et "du vil elske min opstartside" væk.

Ved du, hvad der er forfriskende for nogen, du chatter med på en bar? Interesse og opmærksomhed omkring dem. Det samme gælder for kodere. Hvis du er opmærksom nok på deres verden og er interesseret nok i detaljerne i deres færdigheder, vil de reagere og i det mindste hjælpe.

Denne bit kender jeg fra personlig erfaring. Lige siden jeg har lært at kode, har jeg mange flere ingeniører, der er glade for at give mig råd, guide mig, rette mig og endda dykke ned i mine ideer med mig. Det er ikke lettere at finde den rigtige medstifter, men det har intet at gøre med ekspertise og mere at gøre med deres interesser, prioriteter og livsforhold.

Og hvad nu?

Og nu er jeg for første gang i mit liv i en position, hvor jeg kan eksperimentere med mine ideer. Tidligere kostede det mig tid og penge. Nu koster det mig lidt tid og endda mindre tid end at finde udviklere, forhandle omfang, overvåge arbejde, gennemgå arbejde, testarbejde. Og den tid er en investering, da jeg bliver ved med at forbedre dygtigheden, selvom ideen går ud som kommercielt ustabil.

Jeg er ikke en god kode. Jeg tror ikke, jeg har brug for det (måske om 5 år vil jeg revidere denne opfattelse). Men jeg ved nok til at bygge mine egne prototyper og forstå, hvad der er involveret i opbygningen af ​​et levedygtigt produkt. Og jeg ved nok til at ringe til, hvilke bits der skal outsource, hvordan man beskriver, hvad jeg vil, ikke bliver taget med på en tur, vurderer output og går sammen med andre hackere for at få resultater. Jeg kan aldrig være en professionel udvikler, og det er fint. Det er ikke det, det drejer sig om.

Men jeg er blevet min egen tekniske medstifter. Der kan komme en dag, hvor den bedste brug af min tid virkelig er de ikke-tekniske ting. Men den dag kommer, når jeg først har bygget noget, der vokser. Jeg tror, ​​at jeg har øget mine chancer for at finde det noget, simpelthen fordi jeg kan køre mange flere billige eksperimenter med lav stress, der ikke involverer mig i at bruge penge eller tigge andre om hjælp.

Alt dette på mindre end 12 måneder. Tænk over det. Måske er det virkelig den bedste brug af din tid, hvis du vil være en grundlægger.

Efterskrift For freeCodeCamp-studerende

Jeg tror virkelig, at dine mest dyrebare ressourcer er din tid, kræfter og penge. Af disse er tiden den vigtigste ressource, fordi de to andre kan fornyes og gendannes. Så hvis du vil bruge tid på noget, skal du sørge for, at det kommer dig tættere på dette mål.

Med det i tankerne, hvis du vil investere 3 timer med mig for at finde din korteste vej til at lære at kode (især hvis du ønsker at starte op), så gå til mit kursussted og brug formularen der tilmeld dig (ikke pop op!). Hvis du tilføjer ordene "FRI MIN TID" til meddelelsen, ved jeg, at du er en freeCodeCamp-læser, og jeg sender dig en promo-kode, for ligesom dig gav freeCodeCamp mig en solid start.

Tjek den genstartede gratisCodeCamp podcast, hvor Quincy og Abbey bruger deres utrolige oplevelse som undervisere til at samle indhold, der hjælper dig på din rejse. Jeg var for nylig på episode 53, og nogle af tingene i dette indlæg er dækket mere detaljeret der. Du kan også få adgang til podcasten på iTunes, Stitcher og Spotify eller direkte fra denne side.

Jeg kan kontaktes på Twitter: @ZubinPratap