Manual del CTO de startups

Manual del CTO de startups

Habilidades esenciales y mejores prácticas para equipos de ingeniería de alto rendimiento

Introducción

• Aprender siempre: El autor ha tenido pasión por las computadoras y la programación de software desde pequeño, y a través de ello comprendió la importancia del aprendizaje continuo. Para tener éxito como líder técnico, es importante aprender y crecer de manera constante.
• El dilema del líder técnico en una startup: La mayoría de las startups tienen un cofundador técnico, y estas personas escriben la base de código inicial y contratan a los primeros ingenieros. Sin embargo, a medida que el equipo crece, el líder técnico debe pasar a un rol de gestión, y en ese proceso puede carecer de habilidades de liderazgo.

Sobre el autor

• El autor ha acumulado experiencia en varias startups y ha desempeñado funciones como líder técnico. Gracias a su experiencia en distintas startups, llegó a comprender las diversas habilidades y desafíos necesarios para el liderazgo técnico.

Cómo usar este libro

• Este libro es una referencia para líderes que gestionan equipos de ingeniería de software, y aborda diversos temas en capítulos independientes. Cada capítulo presenta el tema, ofrece una visión general y propone mejores prácticas.

Procesos de negocio

• Explica los procesos de negocio para ofrecer un punto de partida para resolver problemas. Es necesario ajustar y escalar los procesos según el tamaño del equipo y de la empresa.

Personas y cultura

Principios básicos de gestión

• La regla de oro de la gestión: El desempeño del equipo es el criterio para medir el desempeño del gerente. Hay que apoyar a los miembros del equipo para que puedan dar lo mejor de sí.
• Árbol de habilidades profesionales: Para el liderazgo técnico, es necesario invertir no solo en habilidades técnicas, sino también en habilidades de gestión.

Mejora continua

• Kaizen: Tanto el equipo como cada persona deben buscar la mejora continua. Hay que convertir los errores en oportunidades de mejora.

Coaching

• El gerente debe cumplir el papel de coach para ayudar a los miembros del equipo a rendir al máximo.

Encontrar un mentor de gestión

• Para hacer la transición al liderazgo, es importante encontrar un mentor de gestión. Con el mentor adecuado, se pueden mejorar las habilidades de liderazgo.

Reuniones 1:1

• Las reuniones 1:1 son una oportunidad para construir una relación con cada integrante del equipo, identificar sus fortalezas y debilidades, y ayudarle a dar lo mejor de sí.

Reuniones skip-level

• Al reunirse periódicamente con los reportes directos de los gerentes, se pueden recopilar distintas perspectivas y, con ello, mejorar el negocio.

Coaching para gerentes

• El desempeño de los mandos medios es importante para el desempeño de la organización. Hay que desarrollar a los gerentes mediante capacitación y apoyo continuos.

Reuniones 1:1 con ingenieros

• Las reuniones 1:1 con ingenieros son una oportunidad para escuchar los problemas que enfrentan y ayudarles a encontrar soluciones. Hay que dejar claro el propósito de la reunión y conducir una conversación productiva.

[GN⁺]

Opiniones en Hacker News

• Cuando veo este tipo de documentos, suelo ir primero a las partes que conozco a fondo para revisar qué dicen. Aquí dice que prepararse y ejecutar auditorías de PCI DSS o SOC 2 normalmente toma de 6 a 12 meses, así que no hay que intentar certificarse a último momento, pero a una startup casi le aconsejaría lo contrario
  En especial, obtener una atestación SOC 2 es fácil, y gastar dinero de forma proactiva antes de que una orden de compra dependa de eso es un desperdicio. Claro que conviene configurar pronto cosas que más adelante sirvan como base para la atestación, como el inicio de sesión único o ramas de Git protegidas, pero son más bien buenas prácticas básicas que de todos modos deberían hacerse aunque no haya planes de obtener SOC 2. Si un cliente grande no lo exige, creo que no hace falta hacer SOC 2. Estaría bien que alguien revisara también otras partes de este documento

  • Buen enfoque. Busqué la parte de bases de datos y en general estaba bien. Pero en 2025 no parece necesario que una startup se concentre en SQL vs NoSQL. Las bases de datos SQL populares tienen buen soporte para JSON, así que basta con usar PostgreSQL o MySQL, con los que los ingenieros están más familiarizados, y CloudSQL o RDS para encargarse de backups y replicación
    Con una réplica de lectura para BI y una herramienta de visualización decente, se puede aguantar bastante tiempo, y es suficiente antes de gastar montos de 5 o 6 cifras en algo como Snowflake
  • En mi experiencia, las empresas que están dispuestas a trabajar con startups en etapa temprana y piden un informe SOC 2, por lo general no tienen problema en avanzar poniendo en el contrato la obtención de SOC 2 Type 1 en un plazo de 6 meses, siempre que la persona técnica pueda hablar con el equipo de IT del otro lado y convencerlos de que la capacidad es adecuada
  • Discrepo respetuosamente solo en los casos en que los procesos contables y de cadena de suministro están dentro de un ERP empresarial. Revertir más adelante procesos que no son auditables cuesta demasiado tiempo y dinero, y mientras tanto el negocio tiene que seguir funcionando, así que en este caso específico creo que es más barato y mejor hacerlos auditables desde el primer día
  • La aplicabilidad de este consejo puede variar bastante según el sector. Si vendes un producto B2B que maneja información de identificación personal, SOC 2 es prácticamente necesario para que no se rían de ti en una reunión de pitch
    Según tu situación financiera, el costo de usar un servicio automatizado de checklist de cumplimiento SOC 2 como Secureframe puede ser de unos cuantos miles de dólares, y no solo te ayuda a seguir buenas prácticas, sino que también organiza todo de la manera particular que encaja con SOC 2, lo que facilita la auditoría. Comparado con las horas de desarrollo y gestión de proyecto que cuesta encaminar hacia SOC 2 a una organización donde ya están profundamente arraigados procesos no conformes, no es una gran inversión
  • No sé mucho de cumplimiento normativo, pero esto suena bastante raro. Leyendo por encima SOC 2, parece que se necesita una enorme recolección de evidencia durante varios meses antes de la auditoría; si no dedicaste tiempo de antemano, no entiendo cómo sabrías qué debes tener listo después
    La idea de que se puede obtener fácilmente una atestación SOC 2 también es justo lo contrario de lo que he oído de otras personas sobre este tema. Normalmente he escuchado que es muy difícil y consume mucho tiempo, así que me intriga qué me estoy perdiendo. Si realmente es fácil, ojalá esté equivocado

• Veo seguido la idea de que, al convertirse en VP o CTO, uno deja de programar. Entiendo que la capacidad de gestión no es lo mismo que la capacidad de programar, pero me cuesta entender por qué la gente suelta el teclado y desperdicia su primera superpotencia
  Se puede seguir siendo un CTO técnico de principio a fin. Hay que tratar al equipo y a la empresa como un servicio que requiere contribución activa, mantenimiento y soporte on-call, y al mismo tiempo ensuciarse las manos construyendo cosas tanto solo como junto con el equipo

  • A nivel VP/CTO no hay tiempo para contribuir al código y mantenerlo. Si lo hay, probablemente ese cargo sea simbólico. Por ejemplo, el “CTO” de un equipo de startup de 3 personas
    El verdadero problema es asumir temprano en la carrera un rol en el que no hay tiempo para programar. Como aceptar un rol de arquitecto que solo dibuja cajas en pizarras y va de reunión en reunión, o un rol que en la práctica es de management pero lleva la etiqueta de “tech lead”. Te acostumbras a no escribir código y, cuando pasan unos años y tienes que buscar un nuevo trabajo, terminas enfrentando entrevistas para puestos de programación con el hecho de que pasaste una parte considerable de tu carrera de programador sin escribir código. A mucha gente no le vuelve rápido la práctica
  • En mi experiencia, el problema era que el día solo tiene tantas horas. Durante 7 años tuve responsabilidad directa o indirecta sobre unas 20 a 25 personas, y realmente me faltaba tiempo para hacer algo útil en el código
    Era mucho mejor usar mi tiempo para resolver problemas que otras personas no podían resolver. De vez en cuando tomaba un cambio muy simple para pasar personalmente por nuestro proceso y ver dónde podíamos mejorar. Seguía programando de noche o los fines de semana, pero no se siente igual y, con el tiempo, uno inevitablemente se oxida un poco. Aun así, durante un período sabático disfruté muchísimo volver a ensuciarme las manos programando todo el día
  • Si no eres simplemente un contribuidor individual, aparecen otras prioridades. Por eso el trabajo de contribución individual puede interrumpirse en cualquier momento. Entonces no puedes tomar tareas cercanas a la ruta crítica, porque si lo haces terminarás bloqueando a otros o teniendo que traspasarlas
    Puedes hacer revisiones o reuniones de diseño, pero si tomas trabajo central, tarde o temprano habrá problemas
  • No creo que haya una única respuesta correcta, pero a partir de cierto punto contratar al próximo ingeniero clave, crear una hoja de ruta tecnológica para adelantarse a la competencia, o alinear la organización de ingeniería con el resto de la empresa tiene mucho más apalancamiento que las contribuciones de código de un VP/CTO
    El código que puede escribir un VP/CTO también lo puede escribir otra persona del equipo, y quizá incluso mejor. En cambio, es probable que las otras tareas mencionadas sean las que mejor puede hacer el VP/CTO dentro de la empresa. Dejar de lado la mayor parte del trabajo técnico práctico para enfocarse en lo que es más importante para el equipo y la empresa es una decisión bastante razonable
  • Mi último rol de CTO fue con un equipo de 40 personas y estuve completamente sobrecargado desde el primer día. Eso pese a que me considero bastante bueno gestionando el tiempo. Si hubiera podido, habría querido dedicar el 50% de mi tiempo a programar, pero no había tiempo para eso ni una estructura de apoyo a la que pudiera delegar, así que tuve que construirla yo mismo con mucho esfuerzo. Eso, a su vez, era otra razón por la que no tenía tiempo
    La idea de seguir programando es buena, pero normalmente no es por eso que te pagan. Me considero un desarrollador muy fuerte, pero se puede contratar a alguien así por menos que el salario de un CTO. Que un CTO más caro haga ese trabajo es ineficiente. Como referencia, unos años después volví a ser contribuidor individual, y pienso seguir así el resto de mi carrera

• Quiero decir que no existe tal cosa como un chat sincrónico
  Si tiene que ser sincrónico, no debería hacerse en una ventana de chat. Al menos no salvo que se haya acordado “concentrémonos unos minutos en chatear en tiempo real”. Si es remoto, llama por teléfono; si es presencial, hablen cara a cara. No hay que lanzar un mensaje en el chat y esperar una respuesta inmediata

• Me pregunto si hay casos en los que no hubo resentimiento con el sistema de “dos equipos”. No sé si también hubo casos en los que la gente no quisiera pasar naturalmente al equipo del futuro.
  Sobre el papel parece una buena idea, pero cuesta creer que funcione bien en la práctica. Lo más parecido que he visto fue algo como un equipo de librerías que creaba servicios como sistemas de diseño y componentes para que otros equipos los usaran.

  • En un trabajo anterior había una versión de un producto on-premise para la que la empresa había vendido soporte extendido a larguísimo plazo, aunque esa versión estaba por llegar al fin de soporte. Un equipo pequeño, quizá de unas 3 personas, era responsable únicamente de asegurar que esa versión siguiera soportada, que los pipelines funcionaran y que, si era necesario, se pudieran desplegar incluso correcciones grandes.
    Mientras cumplieran con esa responsabilidad, en el tiempo restante podían trabajar libremente en cosas que consideraran valiosas para la empresa. Era un trato bastante bueno. Los demás agradecían que ese equipo pequeño se encargara del trabajo sucio, y al equipo de mantenimiento le gustaba poder arreglar o investigar cosas que siempre les habían molestado en el tiempo que les sobraba. Olvidé los detalles, pero recuerdo que salieron mejoras e investigaciones bastante geniales. Que las personas de ese equipo fueran muy buenas y autodirigidas también ayudó al éxito, aunque también costó más.
  • El libro parece proponer rotaciones periódicas como solución a este problema. El artículo del blog de Microsoft recomienda cambiar cada semana a algunos integrantes entre los dos equipos, y definir al equipo de clientes como un equipo temporal.
    En la práctica, pasé por algunos lugares donde equipos completamente separados funcionaban bien. En juegos, basta pensar en el equipo de engine y el equipo del juego. En uno de mis roles anteriores, incluso dentro del equipo del juego, nos encargábamos de una feature de 6 a 12 semanas y la lanzábamos, y después nos ocupábamos del mantenimiento, las actualizaciones y la deuda técnica. Lo que acabábamos de lanzar era el foco principal, pero también había tiempo para volver a trabajos anteriores; otros equipos estaban en el mismo ciclo y, 6 a 8 semanas después, se hacía onboarding a una nueva feature, repitiendo el proceso.
  • Hace tiempo experimenté con un sistema de dos equipos. El desarrollo de features lo hacía el Red Team, y la estabilidad y la corrección de bugs las llevaba el Blue Team.
    No los tratábamos como equipos fijos, sino como un flujo de trabajo en el que la gente iba y venía en cada sprint, es decir, cada 2 semanas. Funcionó bien durante unos 3 meses, pero después dejó de encajar, y para entonces la organización había crecido y reorganizamos los equipos alrededor de capacidades de negocio o dominios.
  • Algo similar: una vez probé un sistema de turnos en el que los engineers se encargaban durante una semana del soporte y los reportes de bugs. Evitaba bastante bien las trampas de tener “dos equipos” completamente separados. Escribí un poco más en https://news.ycombinator.com/item?id=43337703#43339972.
  • Si el “equipo de clientes” tiene suficientes recursos y la compensación adecuada, no creo que necesariamente quieran pasarse al “equipo del futuro”. Pero incluso sin separarlos, normalmente el mantenimiento queda famélico y las nuevas features se llevan toda la atención y los recursos. Al dividirlo en dos equipos, parece muy probable que la situación empeore.

• Este tipo de material no está pensado para usarse como una Biblia; lo valioso es que ofrece un repaso amplio de responsabilidades y áreas de atención.
  A menos que tengas un gran mentor o hayas trabajado bajo alguien realmente excepcional, cuando llegas a este puesto no hay nadie sentado a tu lado dándote una lista de las cosas que debes cuidar. Cada sección ayuda porque te hace preguntar: “¿cuál es nuestra respuesta?”, “¿estamos de acuerdo?”, “¿nuestro proceso es mejor?”, “¿qué se me está pasando?”.

• Increíble que la separación en “dos equipos” esté planteada de forma tan explícita. Es una forma fantástica de hacer que sigas lanzando cosas hasta que el costo de lanzar algo decente se vuelva demasiado alto.
  Si cortas el feedback loop hacia las personas que crearon el software en primer lugar, esas personas se vuelven un poco más felices por un rato y las demás un poco más infelices por un rato. Luego el equipo de features ya no quiere que lo interrumpan nunca más, y el equipo de clientes nunca recibe los recursos para arreglar bien nada.
  Lo peor es que el equipo de features no aprende nada más que cómo sacar líneas. Con el tiempo todo se vuelve más lento y caro porque eliminaste la única función de aptitud del buen desarrollo de software: reintegrar el feedback negativo como fuente del desarrollo. Un verdadero handbook de liderazgo para CTO debería decir claramente: “es tu responsabilidad ayudar a que los desarrolladores mejoren incluso mientras lanzan, y a los desarrolladores no siempre les va a gustar”.

  • Decir que “permite que el equipo de features se concentre 100% en el futuro sin que lo interrumpa el soporte al cliente” se parece más a decir que permite que el equipo de features siga sin enterarse del desastre que desató hasta que el barco choque de lleno contra el iceberg.
    También aparecen conflictos de merge entre el equipo de features impulsado por ventas y el equipo de mantenimiento impulsado por los responsables de clientes. Mientras el “equipo de clientes” se describa como una etapa de la que luego se sale, es obvio qué lado ganará las peleas de prioridad. La frase “otra vía para que engineers individuales, especialmente juniors, aprendan y crezcan” termina sonando a “los seniors no quieren limpiar la mierda, así que se la pasamos a los juniors”.
  • Relacionado con esto, en las empresas donde trabajé que tenían equipos de plataforma, por lo general había una infección de sobreingeniería. Aquí “equipo de plataforma” significa algo como un tercer equipo de soporte que administra herramientas, prácticas y código común.
    Estos equipos tienden a atraer a personas que desprecian el trabajo de desplegar features y corregir bugs, y que quieren abstraer de más los problemas. En vez de corregir bugs, crean abstracciones cada vez más complejas con la idea de impedir que los bugs existan desde el inicio, y el resultado es predecible.
  • Ese es el trabajo del PM. Hace falta una persona, o algunas, que trabajen con los clientes y definan una visión de cómo encajarán todas las features en función del feedback.
    Los clientes, especialmente los no técnicos, no tienen una visión de producto coherente y muchas veces solo quieren la corrección inmediata, sin importar otros planes. Como los clientes no se comunican entre sí, el feedback también puede entrar en conflicto. Si le cargas eso a los desarrolladores, además de la competencia técnica de conocer y mantener bien el codebase, tienen que gestionar toda la comunicación, y todos los desarrolladores deben compartir la misma visión coherente para poder tomar decisiones consideradas. Si, como hoy, el rol del desarrollador también incluye manejar infraestructura, básicamente una sola persona está haciendo dos o tres trabajos.
  • Para compensarlo, cambiábamos de equipo en cada sprint o cada pocos sprints. Así la gente acumulaba experiencias más variadas y, si creaba features con muchos bugs, al final tenía que arreglarlas directamente, por lo que seguía recibiendo feedback.
    Creo que a la gente le gustó mucho más este enfoque. No se agotaban de arreglar bugs todo el tiempo, y también se evitaba esa desconexión del feedback que señalaste con tanta claridad.
  • Los desarrolladores deben operar y mantener el software que crean. Es un principio así de simple.

• A estas alturas ya hice tantas entrevistas que perdí la cuenta, así que me cuesta un poco estar de acuerdo. Una dificultad es que en la etapa de recepción puede haber demasiados postulantes, o potencialmente demasiados, y en esta fase normalmente es el equipo de reclutamiento el que interactúa con ellos
  Está bien incluir preguntas como las del ejemplo, pero para filtrar candidatos no calificados se necesitan preguntas que no sean de sí/no ni de escala. Yo prefiero preguntas muy simples con una respuesta clara. Hay una cantidad sorprendente de personas que dicen sentirse “muy cómodas” con JavaScript y aun así no saben qué es ===. Por eso hago preguntas como “¿cuál es el operador de igualdad estricta en JavaScript?”. Cualquier programador de JavaScript lo sabe, pero una sola pregunta así elimina al 50% del grupo de postulantes y le ahorra muchísimo tiempo a la organización

• Se habla mucho de encaje cultural, pero buena parte de eso parece sacar a la superficie una capa de discriminación oculta que perjudica a la empresa. Creo que la apertura cultural es un factor de éxito, y la discriminación lleva en la dirección opuesta
  Cuando leo la frase “los mejores líderes hacen seguimiento de la tasa de éxito, no temen reconocer errores de contratación, contratan despacio y despiden rápido”, me dan ganas de subir la imagen que muestra JWZ (Jamie Zawinski) cuando detecta un encabezado referrer que apunta a este sitio. Basta buscar en Google qué dijo Jamie Zawinski sobre Y Combinator. También es una de las personas a las que se atribuye la decisión de Netscape de liberar Netscape Navigator como open source, y gran parte del trabajo que llevó al motor de renderizado de ese navegador. Por eso existe Firefox

  • Ver el “encaje cultural” como discriminación oculta es una interpretación cínica, y en los casos que vi se usó más a menudo para proteger al candidato de asumir un trabajo que no le gustaría
    En uno de mis primeros empleos intentaron prohibir todo lo que pudiera llamarse encaje cultural dentro de los criterios de contratación. Como resultado, varias personas odiaron la empresa apenas entraron y renunciaron en cuestión de semanas o meses. Un candidato enfatizaba la planificación y la previsibilidad, y se quejaba de que sus empresas anteriores avanzaban demasiado rápido. Nosotros éramos una startup y, como era de esperarse, terminó odiando la empresa. Pero no podíamos plantear esa preocupación durante el proceso de decisión de contratación, porque se consideraba “encaje cultural” y podía llevar a discriminación. Después de que pasaran cosas parecidas varias veces más, esa política desapareció discretamente y volvimos a poder evaluar la compatibilidad con la cultura de ingeniería
  • Todo proceso de contratación discrimina. Lo importante es qué características favorece o perjudica, y qué excluye
    El “encaje cultural” suele ser un intercambio: se obtiene eficiencia en la comunicación y alta confianza a cambio de renunciar a parte de la diversidad de pensamiento. Como la gente ya sabe cómo debe actuar y qué esperar de los demás, no hace falta establecer tantas pautas, pero se vuelve más vulnerable al pensamiento de grupo y a sesgos cognitivos relacionados. Es algo así como: “en esta nave están todos los colores del arcoíris, pero incluso nuestros klingon creen que los klingon son malvados”
  • Acepté el desvío y busqué, pero todos los resultados de la primera página eran comentarios en Hacker News que mencionaban a Jamie Zawinski, así que abandoné ahí. Me gustaría que me contaran de qué se trata

• No estoy seguro de que el consejo de “crear una biblioteca de videos explicativos” sea bueno. Puede tener sentido para cosas específicas como una UI o animaciones
  Pero, en general, leer texto es más eficiente que ver videos. Cuando hay prisa, también es mucho más fácil saltar a las partes importantes en un texto que en un video

  • A algunas personas les gustan los videos y a otras les gusta el texto. Ambos son inversiones que requieren esfuerzo y tienen impacto. Ahora, gracias a la IA generativa, es más fácil crear ambos