Se ha escrito mucho sobre la importancia del autodesarrollo del fundador en las startups de rápido crecimiento. Por regla general, los textos sobre estos temas están dedicados al papel del director ejecutivo. Los consejos generales de liderazgo también pueden ser útiles para otros roles, pero no he podido encontrar ningún material para ayudar a los fundadores de tecnología. Después de leer un montón de formularios S-1, quedó claro que es muy difícil encontrar CTO desde cero que hayan pasado de MVP a OPI (mientras que con los fundadores-CEO, la situación es exactamente la opuesta). Este hecho me pareció intrigante: decidí profundizar más. Quería llegar al fondo de la esencia y las razones de este estado de cosas. También me molesta un poco: ¿qué pasa si no puedo crecer rápidamente? ¡Debería resolverlo antes de que surjan problemas reales! ¡Quiero ser el CTO que haga de RevenueCat una empresa pública! (uno)
¿Es más difícil para los fundadores que no son directores ejecutivos crecer rápidamente? ¿Será que el CEO suele contar con un apoyo significativo? Sea como fuere, todo tiene sus propias razones. Quizás simplemente hice la pregunta mal. Después de hablar con muchos de los fundadores de CTO, quedó claro que no existe una definición estándar de CTO. Las responsabilidades de una persona en este puesto pueden cambiar por completo según la empresa y su etapa de desarrollo. El CTO probablemente hará muchas aportaciones personales al principio, pero esto podría cambiar pronto. La experiencia de diferentes personas puede ser muy diferente. Desafortunadamente, no tengo respuestas para los fundadores que no sean CEO. Quizás tampoco tenga respuestas para aquellos que se convirtieron en CTO por primera vez. Sea como fuere, pensé que sería útil reflexionar sobre lo que he aprendidoy cómo han cambiado mis responsabilidades en 3 años en RevenueCat.
Dilema: CTO vs. VP de Ingeniería
En pocas palabras, el rol de CTO está más cerca de la arquitectura y el código, mientras que el VPE estará a cargo del proceso y la administración. Una analogía sería comparar el camino de un ingeniero senior / de tiempo completo y un gerente de ingeniería.
Al principio, necesita un CTO que pueda reunir y organizar a los artistas que crean el MVP. En esta etapa, el fundador puede ser de gran ayuda ya que es necesario definir la visión del producto y la cultura de los procesos técnicos. Idealmente, un CTO debería entender el problema que resolverá su startup.
¿Y si el producto tiene éxito? ¿Y si el producto ocupa su lugar en el mercado? En este caso, deberá contratar más ingenieros para satisfacer la demanda de los consumidores. Este es un desafío maravilloso. Quizás tenga suerte y encuentre financiación, o puede que ya esté generando beneficios. Pero cuanto mayor sea su personal, mayores serán los requisitos para la excelencia del proceso. Inevitablemente, llegará el momento en que alguien deba convertirse en vicepresidente de ingeniería. El inicio de este momento se hará evidente tan pronto como los procesos existentes (o ausentes) dejen de funcionar. En tal situación, tiene varias opciones. El director de tecnología puede asumir el cargo de vicepresidente de ingeniería o la empresa puede contratar empleados adicionales. Es probable que esta decisión sea una cuestión de preferencia personal y experiencia administrativa.Abordar este tipo de desafíos requiere un conjunto de habilidades completamente diferente, y puede ser difícil adquirir estas habilidades en un entorno en el que necesita crecer muy rápidamente. Es por eso que el CTO generalmente se subcontrata.
El fundador puede ser flexible. Él puede tener la autoridad para determinar el camino que tomará la empresa. Tal vez odie la gestión de personas y desee continuar con sus habilidades y conocimientos para trabajar directamente con la tecnología. O tal vez desee mejorar sus habilidades de gestión. El primer tipo es generalmente más indulgente con los defectos de gestión de los fundadores. Se unieron al equipo porque confiaban en los fundadores, creían en sus ideas y confiaban en que tenían buenas intenciones. Al principio, es posible que prefieran trabajar directamente con usted en lugar de con una persona externa. En cualquier caso, en el futuro la empresa tendrá varios niveles de gestión, por lo que si quieres seguir este camino y no tienes experiencia, debes aprender y aprender rápidamente.
Brian Helmig, cofundador y CTO de Zapier dice que necesitas encontrar lo que te da la dopamina. Personalmente, siempre me ha resultado más fácil comunicarme con computadoras que con personas. No estaba seguro de la elección del camino de desarrollo, pero preferí hacer cosas relacionadas con las computadoras. Siempre me ha gustado trabajar con ellos y puedo decir que soy más eficiente como ingeniero que como gerente. Después de integrar la nueva función, me siento con más energía que después de reunirme en persona.
Sin embargo, como fundador, obtengo altas dosis de dopamina cuando a la empresa le va bien. Cuando los compradores recomiendan nuestro producto. Cuando alcancemos nuestros objetivos de ingresos. Cuando contratamos ingenieros mejores que yo. Cuando estos ingenieros están contentos con todo y resuelven con éxito tareas ambiciosas. Cuando la revisión del código es agotadora, pero ocurre en una atmósfera de colaboración, no de ira.
Entonces, al final, decidí no solo seguir mis preferencias, sino hacer lo que sea más efectivo para la empresa en las diferentes etapas de su desarrollo. Después de todo, puedo resolver problemas. Así es como hablé de mi rol. Mis cualidades como fundador son más importantes que mi posición como CTO. Desde una perspectiva a largo plazo, como accionista principal, debo hacer lo que sea mejor para la empresa.
Por lo general, una fractura ocurre cuando tiene de 8 a 12 ingenieros en su equipo. Sin embargo, puede ocurrir en otro momento, todo depende del producto y del medio ambiente. Como empresa totalmente distribuida, enfrentamos varios puntos de inflexión a medida que construíamos nuevas zonas horarias en nuestros flujos de trabajo. En ese momento, muchos tuvieron que asumir las funciones de CTO y VP de Ingeniería al mismo tiempo. Traté de asumir un trabajo para el que otros no tenían recursos (lo hice temporalmente y no muy bien). Me ayudó a encontrar puntos débiles, establecer procesos y contratar a alguien que pueda asumir estas tareas.
Cuando supe cómo otros fundadores administran su tiempo en diferentes etapas del trabajo, pude navegar mejor en mi rol. Desde la fundación de la empresa, llevo un diario. En base a estas notas, hablaré sobre las tareas en las que me enfoqué y cómo ha evolucionado mi rol.
2018: YC, MVP y primeros empleados
Cuando llegamos a YCombinator, éramos solo Jacob y yo. Jacob trabajó en el SDK y el frontend, y yo trabajé en el backend. Después de YC, contratamos a los dos primeros ingenieros para que se hicieran cargo de las responsabilidades de Jacob y trabajaran a tiempo completo. Todos vivíamos en San Francisco y ya conocíamos a estas personas. Teníamos controles simples (y casi completos). No había gastos generales, teníamos sprints semanales y nos movíamos muy rápido.
Estos días fueron intensos pero muy divertidos. Pusimos las bases para una cultura de ingeniería y vimos cómo los clientes entraban uno tras otro. La mayor parte del tiempo lo dediqué a desarrollar las primeras versiones de las funciones de las que hablaron los clientes. Cumplimos con sus solicitudes lo más rápido posible. La mayoría de las solicitudes se procesaron el mismo día.
Lo que más dudaba entonces era que estábamos creando un producto que la gente realmente necesitaba y que podría desarrollar y justificar nuestra ronda de semillas de $ 1.5 millones.
Las principales conclusiones: hay demasiadas, es demasiado difícil generalizar. Aprendimos mucho cuando pasamos por YCombinator. Probablemente, cabe destacar la comunicación con los clientes, la capacidad de crear aquello que les haga felices y satisfaga sus necesidades. Esto y una entrega muy rápida se han convertido en nuestros valores fundamentales.
2019: Seguimos el ritmo de los clientes y desarrollamos tecnologías
Parece que hemos tomado nuestro nicho en el mercado. Los clientes vinieron a nosotros, las solicitudes de soporte comenzaron a acumularse y el rendimiento de nuestra API creció cada día. El primer ingeniero remoto de Taiwán se unió al equipo. En un principio, la diferencia de husos horarios provocó ciertas dificultades, fue necesario adecuar los procesos de trabajo. Sin embargo, todo salió bien. Hicimos un buen trabajo con las consultas y el seguimiento de los clientes.
La adaptación fue un proceso simple y único. Hice reuniones cara a cara (no muy a menudo, aproximadamente una vez al mes), pero la gestión fue bastante fácil. La mayoría de las conversaciones seguían siendo técnicas. Seguía contribuyendo como un intérprete ordinario. También he asistido a varias conferencias.
En ese momento, tenía preocupaciones principalmente técnicas. Principalmente pensé en la escalabilidad de nuestros sistemas. Todos nuestros ingenieros tenían experiencia con el producto y teníamos claros puntos de falla. Constantemente pensaba en no romper nada. La báscula estaba constantemente fuera de mi zona de confort. Hemos afrontado bien la optimización de los escenarios más habituales, la migración de infraestructuras y los puntos críticos evitados. También pagamos la deuda técnica acumulada durante el año pasado.
De hecho, hasta el cuarto trimestre, fui ingeniero de llamadas. No quería molestar a otros miembros del equipo fuera del horario comercial y sentía que, como fundador del departamento técnico, era mi responsabilidad proporcionar la máxima fiabilidad. Llevaba mi computadora portátil conmigo literalmente a todas partes. Al final, aseguramos la rotación. Mirando hacia atrás, entiendo que debería haberse hecho antes.
Conclusión clave: no se centre en la escalabilidad, pero no se olvide de la supervisión. Esté atento a posibles cuellos de botella y puntos de falla. Estos problemas son estresantes, pero lidiar con ellos no es tan malo. Contrate y capacite a ingenieros de llamadas lo antes posible, documente soluciones para incidentes conocidos. Confíe en su equipo. No hay nada de malo en la deuda tecnológica si la aborda de manera responsable y trata de encontrar el producto que tendrá demanda en el mercado.
2020: Delegación y planificación de la futura organización
En 2020, nuestro equipo se ha duplicado nuevamente. Contratamos ingenieros de Europa y Latinoamérica. Al final del año, teníamos varios empleados en cada uno de los equipos (SDK, frontend, frontend, ...). Logramos trabajar en varios proyectos y, finalmente, asumimos tareas más ambiciosas. Sin embargo, necesitábamos mejorar la coordinación. En esta etapa, no se pudo evitar el trabajo sobre la estructura de gobierno.
Durante el primer y segundo trimestre, pasé la mayor parte de mi tiempo revisando el código, proporcionando pautas arquitectónicas y escribiendo algo de código en el lateral. Seguía siendo la persona que comprende nuestros sistemas. A mediados de año, se hizo evidente que yo era el cuello de botella para lanzar nuevas funciones. También mantuve reuniones individuales, participé en discusiones de lluvia de ideas y ya no tuve tiempo para escribir código e implementarlo a tiempo.
Dejé de programar completamente. En cambio, encomendé mis tareas a otros ingenieros y comencé a dedicar más tiempo a transferir conocimientos. Al principio parecía que estaba tomando mucho tiempo, pero la delegación hizo despegar muchos proyectos y dio a muchos ingenieros un fuerte sentido de propiedad. Fue muy extraño no escribir el código al principio. Sentí que no estaba haciendo mi trabajo (o que estaba trabajando de manera improductiva). Este es un sentimiento completamente natural. Pronto me di cuenta de que me había liberado de la programación y ahora puedo ver el panorama general. Pude pensar en el futuro de la estructura de ingeniería.
En términos de gestión, comencé a dedicar más tiempo a hablar sobre el crecimiento profesional y comencé a trabajar con ingenieros para crecer y desarrollarme. Por el lado del producto, carecíamos de los recursos para priorizar, planificar y coordinar los sprints de manera adecuada. Hice todo lo posible para liberar a la gente y establecer comunicación.
También pasamos por la Ronda de Financiamiento A y comenzamos a realizar reuniones de la junta. También comencé a dedicar mucho tiempo a la contratación.
Conclusión clave: las nuevas zonas horarias se volvieron más fáciles de implementar cuando se superponen. Disminuir el factor de bus es muy importante para escalar el equipo de ingeniería. Una vez que haya verificado sus flujos de trabajo y estén funcionando, automatícelos tanto como sea posible. Si no ve el bosque para los árboles, salga de la programación y delegue.
Futuro
El año que viene planeamos duplicar nuestro equipo nuevamente. Parece que pasar de 20 a 40 empleados es más difícil que pasar de 10 a 20. A finales de 2021, la empresa cambiará significativamente.
Creo que me concentraré en la escalabilidad del equipo. No me malinterpreten, por supuesto que enfrentaremos serios problemas técnicos, y tenemos muchas tareas muy ambiciosas en nuestros planes. En los últimos años, hemos aprendido mucho sobre nuestros clientes, los problemas y el conjunto técnico que subyace a nuestra solución. Trabajar con ingenieros talentosos que tienen las habilidades y el entusiasmo para resolver problemas es una parte importante para mí.
Quiero seguir contratando a los mejores talentos y mantener una cultura de ingeniería saludable. No sera facil. Tendré que trabajar en estrecha colaboración con el gerente de recursos humanos para optimizar y automatizar los procesos de abastecimiento, contratación, incorporación y comunicación. Las referencias ayudaron a acelerar el desarrollo del equipo, pero es hora de centrarse en la diversidad en los equipos. Creo que tendremos oportunidades para contratar jóvenes, me gustaría ayudarlos a alcanzar su máximo potencial.
Necesitaremos mejorar nuestra gestión de ingeniería para hacer felices a los ingenieros y empoderarlos. Además, si queremos abordar tareas ambiciosas, necesitaremos invertir en procesos de planificación. desarrollo y lanzamiento de productos.
Estoy muy emocionado por lo que sucederá el próximo año. Por supuesto, además de los problemas existentes, vendrán otros nuevos. Pero nunca sucede de otra manera. ¡No será más fácil!
Espero que este texto haya sido interesante y útil. Planeo volver a esta publicación y complementarla con nuevos conocimientos. Si esta es su primera vez como CTO, estaré encantado de ayudar en todo lo que pueda. No dudes en enviarme un tweet o un correo electrónico.
Un agradecimiento especial a Alex Plugar, Calvin French-Owen, Xavi Santana, Adam Houghton, Sam Lown, Saul Diez y Will Larson por sus consejos y por tomarse el tiempo para compartir sus experiencias. Y, por supuesto, a todo el equipo de ingeniería de RevenueCat por permitirme experimentar con ellos, por aceptar mis defectos y sus francos comentarios.
(1) Con el tiempo, aprendí que la ansiedad y el miedo son causados principalmente por el síndrome del impostor y que son infundados. Si la empresa te supera, no es necesariamente algo malo. De hecho, ¡este es un problema grave! El fundador debería afrontarlo. Concéntrese en contratar personas que sean mejores que usted, que lo ayudarán a crecer y a mejorar su empresa. Todavía quiero ayudar a que RevenueCat se haga público, y si eso tiene éxito, mis responsabilidades y mi puesto serán menos importantes.
- Discusión sobre HackerNews
- Canal de Telegram "HackerNews en ruso"