Cómo convertirse en su propio cofundador técnico y por qué vale la pena su tiempo

Nota : este blog está inspirado en mi reciente entrevista de podcast con Quincy Larson de freeCodeCamp, donde hablamos de esto en los últimos 15 minutos más o menos.

¿Busca un cofundador técnico? Yo fui también. Durante muchos años. Fue un viaje difícil, porque la “sabiduría” predominante es que necesitas salir y encontrar un cofundador técnico porque todas las startups exitosas los tenían (no es cierto, por cierto). Pero, ¿qué sucede cuando estás al final de tu pasarela y tu elección es aprender a programar o salir?

Se supone que los cofundadores técnicos te brindan la estabilidad, el complemento de habilidades esenciales y la responsabilidad que no es posible ser un fundador en solitario. Por supuesto, nadie está rastreando los innumerables ejemplos en los que tener un cofundador de basura hizo que su viaje fuera inmensamente más difícil o frustró su capacidad para progresar por completo. Pero, por supuesto, lo que "ellos" significan es que no se necesita solo un cofundador técnico, se necesita el cofundador técnico adecuado , ¡duh!

Bueno, por supuesto.

Nada de esto es un consejo particularmente útil. Es como decir que necesitas estar despierto para tener buenas ideas (parece obvio e intuitivo, pero no siempre es cierto).

Mi experiencia como fundador no técnico (en solitario)

Esto es lo que he experimentado personalmente en los muchos años que pasé buscando cofundadores técnicos:

  1. Pasé mucho tiempo navegando en foros, LinkedIn y listas de contactos en busca de personas que cumplieran con los criterios mínimos.
  2. Pasé mucho tiempo sin poder validar mucho, probar mucho, progresar mucho porque no tenía nada que validar, probar o progresar más que un lanzamiento bien perfeccionado.
  3. Conocí a mucha gente, y la mayoría no estaba interesada en el espíritu empresarial o no tenía la ética de trabajo necesaria (también conocida como racha masoquista).
  4. Conocí a mucha gente que estaba interesada pero por todas las motivaciones equivocadas (hacerse rico rápido, gloria, fama…)
  5. Conocí a algunas personas que tenían las motivaciones adecuadas y (hasta donde yo sabía) las habilidades adecuadas, pero que no tenían la mentalidad para resistir la brutalidad de comenzar.
  6. Conocí a muy pocas personas que habían experimentado la puesta en marcha y tenían las habilidades, pero ninguna de ellas estaba entusiasmada con mis conceptos (inevitabilidad estadística)

Sabía poco sobre software, aunque quería iniciar una empresa de tecnología. Entonces, aquí están mis errores de entonces:

  1. No tenía ni idea de los aspectos fundamentales y más básicos del software y su diseño.
  2. Subestimé enormemente la complejidad involucrada (no sabía cuánto no sabía)
  3. Subestimé enormemente el tiempo involucrado
  4. Sobreestimé enormemente a las personas a las que me acerqué para ser cofundadores técnicos
  5. Exageré significativamente (pero sin saberlo) mi papel en el período inicial: "apresurar" y "desarrollo comercial" eran mis habilidades, y no aprecié que algunas de las empresas emergentes más exitosas dedicaran un tercio de su tiempo a esas cosas, y la mayor parte de su tiempo construye el producto y responde a las necesidades del cliente.

Durante cerca de 4 años me dije a mí mismo “ No necesito aprender a codificar. Mis talentos se utilizan mejor en otros lugares ”. ¿Suena familiar?  

Es solo parcialmente cierto. Como alguien con recursos muy limitados, mis talentos debían usarse en cualquier cosa que me diera la mejor oportunidad de tener éxito . Tenía algo de dinero extra que podía gastar en desarrolladores. Tenía algo de tiempo que podía dedicar a gestionarlos, y ese tiempo se creó principalmente reduciendo la actividad social, el sueño y no permitiéndome los fines de semana. Tenía una experiencia valiosa que podía utilizar para elaborar un plan de negocios. Tenía sólidas habilidades sociales y de comunicación que podía usar para presentarles a los prospectos y también a los posibles cofundadores.

Hice todas estas cosas y me acerqué un poco más a mis metas. Pero tomó demasiado tiempo. Por supuesto, el progreso siempre es lento, ciertamente más lento de lo que nos gustaría. Pero solo nos ralentizamos aún más al no mirar la situación objetivamente. Incluso cuando tuve cofundadores (que finalmente renunciaron porque era demasiado difícil o porque sus circunstancias de vida cambiaron), descubrí que administrar su ética de trabajo, expectativas y estados de ánimo requería una gran cantidad de mi tiempo y energía. Está bien, pero nadie tiene un presupuesto para eso.

Verá, como aspirantes a fundadores, nuestro mayor enemigo es cualquier cosa que nos haga perder el tiempo. Con cada semana que pasa sin resultados, es más probable que deje de fumar. Y nunca sabemos realmente cuál es nuestro costo de tiempo cuando elegimos un curso de acción. Y nunca sabemos cuándo somos víctimas de la falacia del costo hundido.

Mirando hacia atrás, me costó 4 años y bastante dinero. Y al final de eso, la única forma de empezar de nuevo era repetir ese gasto de tiempo, esfuerzo y dinero, hacer lo mismo: armar un plan y luego buscar desesperadamente un cofundador técnico.

Aquí vamos de nuevo…

Una simple matemática de tiempo

En 2014 leí un blog de Sam Altman, presidente de YCombinator. En él, Sam dice algunas de las verdades más profundas que he ignorado. Aquí está el tweet que desenterré para divertirme.

Las primeras 2 o tres veces que leí su artículo hice argumentos que sonaban muy sensatos sobre por qué no se aplicaba a mí. Me equivoqué y me costó dinero, pero peor aún, me costó mucho tiempo (recuperé el dinero).

Básicamente, postula que es más rápido ( mucho más rápido ) aprender a programar lo suficiente para construir su prototipo que encontrar un cofundador confiable que se ajuste bien y que llegue hasta el final. No solo más rápido, sino que las probabilidades de progreso son mucho mayores.

Es obvio. Encontrar un buen cofundador, técnico o de otro tipo, es una posibilidad remota, como encontrar el socio adecuado de por vida, y requiere cierto grado de suerte. Aprender a codificar un poco es más rápido, no necesita suerte y, por lo tanto, tiene una mayor tasa de éxito.

De hecho, puedes dejar de leer este blog aquí mismo si quieres. Lea el suyo. Es mejor. La única razón por la que escribo el mío es para compartir experiencias personales directas que confirmen lo que dijo. Es revelador que hasta la fecha su blog solo haya tenido ~ 8.500 visitas, de las cuales una docena son mías. Eso es mucho menos que el número de aspirantes a fundadores no técnicos que existen.

Una analogía de citas

En la escuela secundaria, recuerdo que me dijeron que si estás desesperado por el afecto de alguien, actuarás de manera que comprometas tus estándares, tus valores y tus mejores intereses. Te conformarás con personas, comportamientos y situaciones que no son adecuados para ti.

Es exactamente lo mismo con la búsqueda de cofundadores. A medida que pasaba el tiempo y aumentaba mi miedo y desesperación, me encontré comprometiéndome, reduciendo mis estándares. Negociando contra mí mismo. Poniendo excusas a los demás. Asentamiento.

Con el tiempo tomé malas decisiones y malos compromisos. Afortunadamente, ninguna de esas malas decisiones resultó en relaciones reales de cofundación.

Mi punto es que estaba dispuesto a hacer malos compromisos, solo para progresar. Ese es un mal comienzo para algo en lo que quizás tenga que dedicar los próximos 10 a 20 años de su vida.

Las cosas técnicas no terminan en el lanzamiento

Es tentador ser táctico y decir que solo necesito llegar al lanzamiento. Ese no es un plan sostenible. Hay una diferencia entre planear "recuperarlo cuando llegue a ese puente" y tener que hacerlo porque la vida no te dejó otra opción.

Aprendí por las malas que mi necesidad de ayuda técnica creció después del lanzamiento. Pensé que las yardas duras estaban comenzando a despegar. Chico, estaba equivocado. Las cosas se rompen. Surgen errores. Las funciones no funcionan como se esperaba. Los usuarios tienen opiniones sólidas sobre las cosas. La iteración es la forma de lograr un ajuste entre el producto y el mercado. Y tiene que ser rápido, bien coordinado y sistemático. Los datos ayudan, ¡y muchos datos valiosos llegan después del lanzamiento!

Es por eso que pagar por los desarrolladores no es sostenible a menos que tenga muchos fondos. Y no es probable que obtenga muchos fondos antes de tener un producto. Es posible, pero no para la mayoría de los fundadores.

Entonces, ¿qué vas a hacer cuando 4 semanas después del lanzamiento, las cosas se rompen, los usuarios informan errores inesperados y el servidor falla o la tienda de aplicaciones ha cambiado alguna política? Gastas más dinero. Y ruega a los desarrolladores que se den prisa. Mientras tanto, haces todo lo posible para encontrar usuarios, lanzar, vender, etc.

Estás gastando tu tiempo en cosas, seguro, y son importantes. Pero dada la opción entre corregir un error / agregar una característica que sus usuarios están pidiendo a gritos y presentar su plan de negocios a un posible financiador inicial, el mejor uso de su tiempo es el producto, no la propuesta. Y no puedes hacerlo porque no sabes cómo. De modo que se esfuerza en cosas de importancia secundaria porque no puede esforzarse en cosas de suma importancia .

Desarrollar empatía técnica

Como mencioné en el podcast, yo era (vergonzosamente) una de esas personas que insistía en que “es un prototipo simple y rápido”. Total, absoluta, lamentablemente, carecía de cualquier concepto de cómo es el proceso de desarrollo.

Quincy, el fundador de freeCodeCamp y quien dirige el podcast, lo resumió muy bien:

Le brinda empatía por la experiencia del desarrollador y lo ayuda a realizar estimaciones de tiempo significativas, no solo en términos de lo que es posible, sino también de lo que es sencillo y lo que es complejo. [parafraseado]

Imagínese si alguien que no tiene ni idea de su trabajo se le acerca e insiste en que algo que toma una semana debería tomar 2 días, ¿no le gustaría golpearlo en la cabeza y simplemente darse la vuelta con disgusto?

Estoy muy avergonzado por todas las veces que hice esto (insisto en que es una aplicación simple, no golpear a alguien en la cabeza).

Peor aún, ¿por qué me tomarían en serio? ¿Realmente les había mostrado respeto y compromiso al menos tratando de aprender un poco de su oficio? Desde su punto de vista, me escondía detrás de mis habilidades y la excusa razonable de que la codificación " no es el mejor uso de mi tiempo ".

Aquí hay otro efecto secundario siniestro de no estar lo suficientemente informado sobre las cuestiones técnicas. Nunca pude evaluar las habilidades relativas de las personas con las que hablé. Tenía que ir por fe, confianza o recomendaciones. No tenía forma de evaluar su aptitud para el propósito que necesitaba que cumplieran.

Mirando hacia atrás, podría haberme ahorrado una tonelada de dinero y meses de esfuerzo, mientras desarrollaba una habilidad que extiende mi pista de aterrizaje casi indefinidamente, si hubiera aprendido a codificar antes.

Como dice Sam Altman:

"Cuando personas como esta dicen" Haré lo que sea necesario para que este negocio sea exitoso "(lo que casi siempre dicen), yo digo algo como" ¿Por qué no aprender a piratear? "

¿Por qué no? Haz lo que sea necesario. Especialmente si ayuda a que su startup "no muera".

La ingeniería no es el fin de todo

Ni por un momento creo que la codificación sea la respuesta a todo. Si está entre los que tienen un cofundador técnico, compañero de clase, colega, hermano, etc. interesado y totalmente confiable, entonces sí, no es la mejor manera de aprovechar su tiempo, ¿por qué? Porque tienes un gran recurso en esa otra persona. Entonces, aprender a codificar es duplicar conjuntos de habilidades.

Pero cuando no tiene ese conjunto de habilidades, aprender un poco es el mejor uso de su tiempo, si le ahorra mucho tiempo a largo plazo. Aquí están las matemáticas que aplico:

prioridad = probabilidad de resultado en una unidad de tiempo determinada

Entonces:

Encuentre un cofundador en 6 meses y comience a construir en el séptimo mes: 50% de probabilidad

Aprenda suficiente código en 6 meses y comience a compilar en el séptimo mes: 90%

Todo este artículo sería totalmente obvio si dijera que los programadores necesitan aprender habilidades de marketing y comunicación para lanzar. Los codificadores necesitan salir del edificio y hablar con sus clientes y no solo codificar. Esto ahora se considera un consejo "obvio".

Entonces, ¿por qué lo contrario no es tan obvio?

Date credibilidad

Los ingenieros son como la chica guapa del bar. Se les "coquetea" todo el tiempo. Se les acercan todo el tiempo. No lo sé directamente, pero supongo que eso se cansa rápidamente, y el cinismo es solo otro "te va a encantar mi idea de inicio".

¿Sabes lo que es refrescante para alguien con quien estás charlando en un bar? Interés y conciencia sobre ellos. Lo mismo ocurre con los codificadores. Si eres lo suficientemente consciente de su mundo y lo suficientemente interesado en los detalles de sus habilidades, responderán y, como mínimo, te ayudarán.

Este poco lo sé por experiencia personal. Desde que aprendí a codificar, tengo muchos más ingenieros felices de darme consejos, guiarme, corregirme e incluso sumergirme en mis ideas. No es más fácil encontrar al cofundador adecuado , pero eso no tiene nada que ver con la experiencia y más con sus intereses, prioridades y circunstancias de vida.

¿Y ahora qué?

Y ahora, por primera vez en mi vida, estoy en una posición en la que puedo experimentar con mis ideas. Antes me costaba tiempo y dinero. Ahora me cuesta un poco de tiempo, e incluso entonces menos tiempo que encontrar desarrolladores, negociar el alcance, supervisar el trabajo, revisar el trabajo, probar el trabajo. Y ese tiempo es una inversión, ya que sigo mejorando la habilidad incluso si la idea resulta comercialmente inviable.

No soy un gran programador. No creo que deba serlo (tal vez en 5 años revise esta vista). Pero sé lo suficiente para construir mis propios prototipos y entiendo lo que implica construir un producto viable. Y sé lo suficiente para responder a una llamada sobre qué partes subcontratar, cómo describir lo que quiero, no dejarme engañar, evaluar el resultado y formar equipo con otros piratas informáticos para obtener resultados. Puede que nunca sea un desarrollador profesional, y eso está bien. No se trata de eso.

Pero me he convertido en mi propio cofundador técnico. Puede llegar el día en que el mejor uso de mi tiempo sea en las cosas no técnicas. Pero ese día llegará una vez que haya construido algo que está creciendo. Creo que he aumentado mis posibilidades de encontrar algo simplemente porque puedo realizar muchos más experimentos baratos y sin estrés que no me impliquen gastar dinero o pedir ayuda a otros.

Todo esto en menos de 12 meses. Piénsalo. Quizás realmente sea el mejor uso de tu tiempo si quieres ser un fundador.

Postdata Gratis para estudiantes de CodeCamp

Realmente creo que sus recursos más preciados son su tiempo, esfuerzo y dinero. De estos, el recurso más importante es el tiempo, porque los otros dos pueden renovarse y recuperarse. Entonces, si vas a dedicar tiempo a algo, asegúrate de que te acerque a este objetivo.

Con eso en mente, si desea invertir 3 horas conmigo para encontrar su camino más corto para aprender a codificar (especialmente si está buscando comenzar), diríjase al sitio de mi curso y use el formulario para registrarse (no la ventana emergente!). Si agrega las palabras “GRATIS MI TIEMPO” al mensaje, sabré que es un lector de freeCodeCamp y le enviaré un código de promoción, porque al igual que usted, freeCodeCamp me dio un buen comienzo.

Echa un vistazo al podcast freeCodeCamp relanzado, donde Quincy y Abbey utilizan su increíble experiencia como educadores para reunir contenido que te ayudará en tu viaje. Recientemente estuve en el episodio 53 y algunas de las cosas en esta publicación están cubiertas con mayor detalle allí. También puede acceder al podcast en iTunes, Stitcher y Spotify o directamente desde esta página.

Me pueden contactar en Twitter: @ZubinPratap