Hogyan válhat saját technikai társalapítójává - és miért éri meg az idejét

Megjegyzés : ezt a blogot a legutóbbi podcast interjúm inspirálta a freeCodeCamp Quincy Larsonnal, ahol erről beszélünk az elmúlt 15 percben.

Műszaki társalapítót keres? Én is az voltam. Sok éven. Nehéz utazás volt, mert az uralkodó „bölcsesség” az, hogy ki kell mennie és meg kell találnia egy műszaki társalapítót, mert az összes sikeres startupnak megvoltak (nem mellesleg). De mi történik, amikor a kifutópálya végén jár, és a választása az, hogy megtanuljon kódolni vagy abbahagyja?

A műszaki társalapítók állítólag olyan stabilitást, alapvető képességek kiegészítését és elszámoltathatóságot nyújtanak Önnek, amelyek önálló alapítóként nem lehetségesek. Természetesen senki sem követi azt a számtalan példát, amikor egy szeméttársalapítóval rendelkezők mérhetetlenül megnehezítették az utazást, vagy meghiúsították a teljes haladás képességét. De természetesen azt jelentik, hogy „ezek” azt jelentik, hogy nem csak egy műszaki alapítóra van szükség, hanem a megfelelő technikai társalapítóra, huh!

Nos, természetesen.

Ezek egyike sem különösebben hasznos tanács. Ez olyan, mintha azt mondanád, hogy ébren kell lenned, ha jó ötleteid vannak (nyilvánvalónak és intuitívnak tűnik, de nem mindig igaz).

Tapasztalatom nem technikai (szóló) alapítóként

Íme, amit személyesen tapasztaltam a technikai társalapítók keresésével töltött sok év alatt:

  1. Rengeteg időt töltöttem a fórumok, a LinkedIn és a névjegyzékek böngészésével, keresve azokat az embereket, akik megfeleltek a minimumfeltételeknek
  2. Nagyon sok időt töltöttem azzal, hogy nem tudtam sokat érvényesíteni, sokat tesztelni, sokat fejlődni, mert a jól csiszolt pályán kívül nem volt más, amit ellenőriznem, tesztelni vagy haladni.
  3. Sok emberrel találkoztam, és a legtöbbet nem érdekelte a vállalkozói szellem, vagy nem rendelkeztek a szükséges munkamorállal (más néven mazochista csíkkal)
  4. Sok olyan emberrel találkoztam, akik érdeklődtek, de minden rossz motiváció miatt (gyorsan meggazdagodni, dicsőség, hírnév ...)
  5. Találkoztam néhány emberrel, akik megfelelő motivációval és (amennyire meg tudtam mondani) megfelelő képességekkel rendelkeztek, de akiknek nem volt olyan mentalitásuk, hogy ellenálljon az indulás brutalitásának
  6. Nagyon kevés emberrel találkoztam, akik már tapasztalták az indítást és rendelkeztek készségekkel, de egyiküket sem lelkesítette a koncepcióm (statisztikai elkerülhetetlenség)

Tudtam, hogy nagyon guggolt a szoftverekről, bár technológiai céget akartam alapítani. Tehát, itt vannak az akkori hibáim:

  1. Fogalmam sem volt a szoftver alapvető, legalapvetőbb szempontjairól és azok tervezéséről
  2. Durván alábecsültem a bonyolultságot (nem tudtam , mennyit nem tudtam)
  3. Durván alábecsültem az ezzel járó időt
  4. Durván túlbecsültem azokat az embereket, akikhez technikai társalapítóként fordultam
  5. Jelentősen (de nem tudatosan) túlbecsültem a szerepemet a kezdeti időszakban - a „sürgetés” és az „üzletfejlesztés” voltak a képességeim, és nem értékeltem, hogy a legsikeresebb induló vállalkozások egy része idejének egyharmadát ezekre a dolgokra fordította, és a legtöbb időt a termék építésével és az ügyfelek igényeinek kielégítésével

Közel 4 évig azt mondtam magamnak: „ Nem kell megtanulnom kódolni. A tehetségeimet jobban használják másutt ”. Ismerős?  

Csak részben igaz. Nagyon korlátozott erőforrásokkal rendelkező tehetségemet bárhol fel kellett használni, ami a legnagyobb esélyt adta a sikerre . Volt egy kis tartalék készpénzem, amelyet költhettem fejlesztőkre. Volt egy kis időm, amit a kezelésükre fordíthattam, és ez az idő elsősorban a társadalmi aktivitás csökkentése, az alvás és a hétvégék megtagadása volt. Értékes tapasztalatom volt, amelyet felhasználhattam egy üzleti terv összeállításához. Erős társadalmi készségekkel és kommunikációs készségekkel rendelkeztem, amelyeket felhasználhattam a potenciális partnerek és a potenciális társalapítók felé.

Tettem ezeket a dolgokat, és közelebb kerültem a céljaimhoz. De túl sok időbe telt. Természetesen a fejlődés mindig lassú, természetesen lassabb, mint szeretnénk. De csak akkor lassítjuk tovább magunkat, ha nem tárgyilagosan tekintünk a helyzetre. Még akkor is, amikor voltak alapítótársaim (akik végül azért léptek fel, mert túl nehéz volt, vagy megváltoztak az életkörülményeik), azt tapasztaltam, hogy munkamorálom, elvárásaik és hangulataik kezelése nagyon sok időt és energiát igényel. Ez rendben van - de erre senki sem költ.

Látja, hogy törekvő alapítóként a legnagyobb ellenségünk minden, ami időveszteséget okoz nekünk. Minden hét, amely eredmény nélkül telik el, nagyobb valószínűséggel hagyja abba. És soha nem tudjuk igazán, mi az időköltségünk, amikor cselekvési módot választunk. És soha nem tudjuk, mikor vagyunk az elsüllyedt költségek tévedésének áldozatai.

Visszatekintve 4 évembe került és elég sok pénzbe került. És ennek végén az újrakezdés egyetlen módja az volt, hogy megismételte ezt az idő-, erőfeszítés- és pénzkiadást, ugyanazt csinálva - terv összeállítása, majd kétségbeesetten technikai társalapító keresése.

Már megint itt tartunk…

Egy egyszerű idő-matematika

2014-ben olvastam Sam Altman, az YCombinator elnökének blogját. Ebben Sam elmondja a legmélyebb igazságokat, amelyeket valaha sem vettem figyelembe. Itt van a tweet, amelyet szórakozásból ástam ki.

Az első két-három alkalommal, amikor elolvastam a darabját, igazán értelmes hangzatos érveket fogalmaztam meg, hogy miért nem vonatkozik rám. Tévedtem, és pénzembe került, de ami még rosszabb, sok időbe került (visszahoztam a pénzt).

Alapvetően azt állítja, hogy gyorsabb ( sokkal gyorsabb ) megtanulni annyit programozni , hogy elkészítse a prototípust, mint egy megbízható, megbízható társalapítót találni, aki jól illik, és megteszi a távolságot. Nem csak gyorsabban, de a haladás esélye is jóval magasabb.

Ez nyilvánvaló. A jó társ-alapító megtalálása, technikai vagy egyéb szempontból, hosszú lövés - például az élethez megfelelő partner megtalálása - és bizonyos fokú szerencsét igényel. A kódolás egy kicsit gyorsabb elsajátítása, nincs szüksége szerencsére, ezért nagyobb a sikere.

Valójában itt hagyhatja abba a blog olvasását, ha úgy tetszik. Olvassa el az övét. Ez jobb. Az egyetlen ok, amiért az enyémet írom, az a közvetlen, személyes tapasztalatok megosztása, amelyek megerősítik azt, amit mondott. Beszédes, hogy a mai napig blogjának csak ~ 8500 megtekintése volt - ebből egy tucat az enyém. Ez jóval kevesebb, mint a törekvő nem technikai alapítók száma.

Randevú hasonlat

A középiskolában emlékszem, hogy azt mondták nekünk, hogy ha valaki kétségbeesetten szeret valakit, akkor oly módon fog cselekedni, amely kompromittálja önmagát - a normáit, az értékeit és az érdekeit. Megelégedsz azokkal az emberekkel, viselkedéssel és helyzetekkel, amelyek nem felelnek meg neked.

Pontosan ugyanez van a társalapítók keresésével is. Ahogy telt az idő, és félelmem és kétségbeesésem fokozódott, azt tapasztaltam, hogy kompromisszumot kötöttem - csökkentve a normáimat. Tárgyalás magam ellen. Mentséget keresni mások számára. Beépül.

Idővel rossz döntéseket és rossz kompromisszumokat hoztam. Szerencsére e rossz döntések egyike sem eredményezett tényleges társalapító kapcsolatokat.

Az a véleményem, hogy rossz kompromisszumokra készültem, csak előrelépésre. Ez rossz kezdet valaminek, amire életének következő 10–20 évét el kell töltenie.

A műszaki dolgok nem érnek véget az indításkor

Csábító, ha taktikázom, és azt mondom, hogy csak el kell indulnom. Ez nem fenntartható terv. Van-e különbség a tervezés , hogy „hogy fel mikor jut el, hogy a híd”, és amelynek csinálni, mert az élet elhagyott nincs más választása.

Megtanultam azt a nehéz utat, hogy az indulás után megnőtt a műszaki segítség iránti igényem. Azt hittem, a kemény udvarok indulnak. Fiú, tévedtem A dolgok megtörnek. Hibák jelennek meg. A funkciók nem a várt módon működnek. A felhasználóknak erős a véleményük a dolgokról. Az iteráció a termék-piaci illeszkedés elérésének módja. Ennek gyorsnak, jól koordináltnak és szisztematikusnak kell lennie. Az adatok segítenek, és sok értékes adat érkezik az indítás után!

Éppen ezért a fejlesztőkért történő fizetés nem fenntartható, kivéve, ha rengeteg támogatást kap. És valószínűleg nem kap sok támogatást, mielőtt még terméke lenne. Lehetséges, de a legtöbb alapító számára nem.

Tehát mit fog tenni, amikor az indítás után 4 héttel megszakadnak a dolgok, a felhasználók váratlan hibákról számolnak be, és a szerver összeomlott, vagy az alkalmazásbolt megváltoztatott valamilyen irányelvet? Több pénzt költ. És kérje a fejlesztőket, siessenek. Eközben a legmerészebb a felhasználói felkutatás, az eladás, az eladás stb. Érdekében.

Biztosan dolgokra fordítja az idejét, és ezek fontosak. De ha választani lehet egy hiba kijavítása / egy olyan funkció hozzáadása között, amelyért a felhasználók kiabálnak, és az üzleti tervet átadja egy potenciális vetőmag-finanszírozónak, idejének legjobb felhasználása a termék, nem pedig a hangmagasság. És nem teheti meg, mert nem tudja, hogyan. Tehát másodrendű következményekkel járó dolgokkal foglalkozol, mert nem tudsz kiemelkedően fontos dolgokkal foglalkozni .

A technikai empátia fejlesztése

Amint a podcaston említettem, (morfikusan) azon emberek közé tartoztam, akik ragaszkodtak ahhoz, hogy „ez egy egyszerű, gyors prototípus”. Teljesen, teljesen, sajnálatosan hiányzott minden koncepció arról, hogy milyen a fejlesztési folyamat.

Quincy, az freeCodeCamp alapítója és a podcastot üzemeltető nagyon jól összefoglalta:

Ez empátiát ad a fejlesztői tapasztalatok iránt, és segít értelmes időbecslést készíteni, nemcsak a lehetséges, hanem az egyszerű és a bonyolult szempontjából is. [átfogalmazva]

Képzelje el, ha valaki, akinek fogalma sincs a munkájáról, odajön hozzád, és ragaszkodik ahhoz, hogy egy hétig tartó dolognak 2 napig kellene eltelnie - nem akarná fejbe csapni, és undorral elfordulni?

Komolyan zavarban vagyok mindannyiszor, amikor ezt csináltam (ragaszkodom hozzá, hogy ez egy egyszerű alkalmazás, ne fejet kopogtassak valakinek).

Még rosszabb, miért vennének komolyan? Valóban megmutattam nekik tiszteletet és elkötelezettséget, ha legalább megpróbáltam megtanulni egy kicsit a mesterségükből? Az ő szemszögükből rejtőzködtem a képességeim és az ésszerű kifogás mögött, hogy a kódolás „ nem a legjobb időm .”

Itt van egy másik baljós mellékhatás, ha nem ismerünk eléggé a technikai dolgokban. Soha nem tudtam értékelni azoknak az embereknek a relatív képességeit, akikkel beszéltem. Hitre, bizalomra vagy ajánlásokra kellett mennem. Nem volt módom felmérni a megfelelőségüket arra a célra, amelyre szükségem volt.

Visszatekintve rengeteg pénzt és hónapokig tartó erőfeszítéseket spórolhattam volna meg magamnak, miközben olyan képességeket építettem ki, amelyek szinte végtelenségig meghosszabbítják a kifutópályámat - ha korábban megtanultam volna kódolni.

Ahogy Sam Altman mondja:

"Amikor az ilyen emberek azt mondják, hogy" mindent megteszek az üzleti siker érdekében "(amit szinte mindig mondanak), akkor valami olyasmit mondok, hogy" Miért ne tanulnánk meg hackelni? "

Miért nem. Bármit megtesz. Különösen, ha ez segít a startupnak „nem meghalni”.

A mérnöki munka nem minden vége

Egy pillanatig sem gondolom, hogy a kódolás a válasz mindenre. Ha azok közé tartozik, akik érdeklődő és teljesen megbízható technikai társalapítóval, osztálytárssal, kollégával, testvérrel stb. Rendelkeznek , akkor igen, ez nem a legjobb idejét használja - miért? Mert remek erőforrásod van abban a másik emberben. Ezután a kódolás megtanulása a készségek másolása.

De amikor még nincs ilyen készségeid, akkor egy kis tanulás abból a legjobb időd, ha hosszú távon sok időt takarít meg. Itt van a matematika, amelyet alkalmazok:

prioritás = az eredmény valószínűsége egy adott időegységben

Így:

Találjon társalapítót 6 hónap múlva, és kezdje el az építést a 7. hónapban: 50% a valószínűsége

Tanuljon meg elegendő mennyiségű kódot 6 hónap alatt, és a 7. hónapban kezdje el az építést: 90%

Ez az egész cikk teljesen nyilvánvaló lenne, ha azt mondaná, hogy a kódolóknak marketing és kommunikációs készségeket kell megtanulniuk a hangmagasság növeléséhez. A kódolóknak ki kell menniük az épületből, és beszélniük kell ügyfeleikkel, és nem csak kódolniuk. Ezt ma „kézenfekvő” tanácsnak tekintik.

Akkor miért nem éppen annyira nyilvánvaló a fordítottja?

Adjon magának hitelességet

A mérnökök olyanok, mint az igazán jóképű lányok a bárban. Folyamatosan „ütnek”. Folyamatosan megkeresik őket. Nem tudom közvetlenül, de feltételezem, hogy ez gyorsan elfárad, és a cinizmus csak egy újabb „imádni fogod az indítási ötletemet”.

Tudod, mi frissítő annak, akivel beszélgetsz egy bárban? Érdeklődés és tudatosság velük kapcsolatban. Ugyanez vonatkozik a kódolókra is. Ha eléggé tisztában vagy a világukkal, és eléggé érdekel a képességeik részleteiben, akkor válaszolni fognak, és legalább segítenek.

Ezt a kicsit személyes tapasztalatból tudom. Amióta megtanultam kódolni, sokkal több mérnök van, aki szívesen ad nekem tanácsot, útmutatást, helyesbítést és még az ötleteimbe is belemerül. Nem egyszerűbb megtalálni a megfelelő társalapítót, de ennek semmi köze a szakértelemhez, és még inkább az érdekeikhez, prioritásaikhoz és életkörülményeikhez.

Na és most?

És most életemben először vagyok abban a helyzetben, hogy kísérletezhessek ötleteimmel. Korábban időmbe és pénzembe került. Most egy kis időbe, és akkor is kevesebb időbe kerül, mint a fejlesztők megkeresése, a hatókör tárgyalása, a munka felügyelete, a munka ellenőrzése, a tesztelés. És ez az idő befektetés, mivel folyamatosan fejlesztem a készségeket, még akkor is, ha az ötlet kereskedelmi szempontból életképtelen.

Nem vagyok nagy kódoló. Szerintem nem kell (talán 5 év múlva felülvizsgálom ezt a nézetet). De elég sokat tudok a saját prototípusaim elkészítéséhez, és megértem, mi jár egy életképes termék felépítésével. És eleget tudok ahhoz, hogy felhívjam, mely biteket kell kiszervezni, hogyan írjam le, mit akarok, ne vigyenek el egy kört, értékeljem a kimenetet, és más hackerekkel álljak össze, hogy eredményeket érjünk el. Lehet, hogy soha nem leszek szakmai fejlesztő, és ez rendben van. Nem erről van szó.

De a saját műszaki társalapítóm lettem. Eljöhet egy nap, amikor időm legjobb kihasználása a nem technikai dolgok. De eljön az a nap, ha felépítek valamit, ami növekszik. Úgy gondolom, hogy megnőtt az esélyem arra, hogy találok valamit, egyszerűen azért, mert még sok olcsó, alacsony stresszt igénylő kísérletet futtathatok, amelyek nem járnak pénzköltéssel vagy mások segítségének könyörgésével.

Mindezt kevesebb, mint 12 hónap alatt. Gondolkodj el rajta. Lehet, hogy ez valóban a legjobb időd, ha alapító akarsz lenni.

Utóirat FreeCodeCamp hallgatók számára

Nagyon, igazán hiszem, hogy a legértékesebb erőforrásai az idő, a fáradság és a pénz. Ezek közül az egyetlen legfontosabb erőforrás az idő, mert a másik kettő megújítható és helyreállítható. Tehát, ha valamire szánsz időt, győződjön meg arról, hogy ez közelebb visz e célhoz.

Ezt szem előtt tartva, ha 3 órát szeretne velem fektetni, hogy megtalálja a legrövidebb utat a kód megtanulásához (különösen, ha elindulni szeretne), akkor menjen a kurzusom webhelyére, és használja az ott található űrlapot a felugró ablak!). Ha hozzáadja az üzenethez az „INGYENES IDŐM” szavakat, megtudom, hogy Ön egy freeCodeCamp olvasó, és elküldöm neked egy promóciós kódot, mert csakúgy, mint te, a freeCodeCamp is stabil kezdéssel járt nekem.

Nézze meg az újraindított freeCodeCamp podcastot, ahol Quincy és Abbey hihetetlen tapasztalataikat oktatóként használják fel arra, hogy olyan tartalmakat gyűjtsenek össze, amelyek segítenek az utazásban. Nemrég voltam az 53. részen, és ebben a bejegyzésben szereplő néhány dolgot ott részletesebben tárgyalok. Hozzáférhet a podcasthoz az iTunes, a Stitcher és a Spotify alkalmazásban, vagy közvetlenül erről az oldalról.

A Twitteren lehet megkeresni: @ZubinPratap