- Muchos CTO pasan a un enfoque más centrado en la gestión, pero algunos siguen desarrollando productos escribiendo código directamente
- Generan un alto apalancamiento dentro de la organización a través de tres tipos de trabajo de desarrollo: proyectos experimentales, solicitudes urgentes de clientes y corrección de errores
- Al seguir programando, experimentan de primera mano la utilidad real y las limitaciones de las herramientas de IA, y aseguran decisiones técnicas más realistas
- Más que la gestión, ponen su fortaleza y pasión en resolver problemas y construir productos, y diseñan una estructura organizacional que lo haga posible
- No existe un molde fijo para el rol de CTO; lo clave es encontrar un estilo de liderazgo que encaje con las fortalezas de cada persona y la situación de la empresa
Por qué sigo escribiendo código como CTO
- Muchos CTO dejan de programar con el tiempo, pero aquí se mantiene la práctica de desarrollar y desplegar funciones directamente
- En los últimos 12 meses se lanzaron varias funciones importantes sin tener reportes directos
- No es un simple hobby: se cumple un rol de desarrollador de funciones clave que terminan en el producto real
- Se define esto como “una de las actividades de mayor apalancamiento para un líder técnico”
Tres tipos de proyectos que realmente construyo
1. Proyectos experimentales de largo plazo (Long-horizon experimental projects)
- Dentro de una organización, son muy pocas las personas que realmente pueden construir un producto nuevo
- La mayoría de las organizaciones están enfocadas en mantener y escalar el producto existente
- Solo los fundadores, algunos ejecutivos y ciertos contribuyentes individuales (IC) de alto desempeño tienen margen para intentar algo nuevo
- Por la estructura organizacional, los incentivos del roadmap y el presupuesto limitado para asumir riesgos, la mayoría de los ingenieros no puede impulsar durante meses proyectos inciertos
- Un CTO está en una posición única para impulsar rápidamente proyectos experimentales inciertos, gracias a una comprensión profunda de los pain points del cliente y de la arquitectura
- Hubo fracasos, pero también éxitos grandes
- Caso del producto de chat con IA: el equipo reconocía su valor, pero no tenía tiempo ni espacio, así que durante el feriado de Acción de Gracias se desarrolló un prototipo
- Después, junto con el equipo, se logró convertirlo en un producto comercial con millones de dólares en ARR
2. Atención de solicitudes críticas de clientes (Critical customer asks)
- A veces una función que un cliente importante necesita con urgencia se convierte en un bloqueo para un gran contrato o una renovación
- En lugar de reasignar a un ingeniero que ya está en el sprint actual, el CTO lo resuelve directamente con base en decisiones rápidas y entendimiento integral del sistema
- Caso real: solicitud de una función de reducción de datos para cumplir requerimientos de compliance de un cliente que paga un millón de dólares al año
- La revisión inicial del equipo estimó que el cliente tendría que construir una integración con la API por su cuenta, o que harían falta varias reuniones entre producto, legal e ingeniería
- El CTO construyó y desplegó en un día una versión funcional, y así se mantuvo la relación con el cliente
3. Corrección de errores (Bugfixes)
- Aunque a muchos les sorprende, corregir bugs es una de las formas favoritas de mantener un mapa mental del codebase
- Al rastrear por qué la paginación se rompe en la página 3 de resultados de búsqueda, o por qué una conexión WebSocket se corta exactamente a los 60 segundos, se recorre todo el sistema
- Se obtiene una comprensión intuitiva de la deuda técnica que es difícil conseguir solo con code reviews o discusiones de arquitectura
- Esa experiencia permite mantener la intuición necesaria para decidir la dirección y prioridad de las inversiones técnicas
Por qué sigo programando
1. Para entender qué tecnología realmente funciona
- La experiencia de usar a diario herramientas de IA como Claude Code, Codex y Cursor permite distinguir entre realidad y hype al tomar decisiones sobre herramientas y estrategia de contratación
- Caso reciente: se intentó hacer vibe-coding con una función que tocaba una integración compleja, pero no avanzó; al escribirla manualmente, el progreso fue mucho más rápido
- No era mucho código, pero sí requería lógica precisa, un área en la que los LLM suelen fallar
- En cambio, otra función grande se desarrolló casi por completo con Claude Code
- Entender dónde la IA sobresale (CRUD, pruebas, boilerplate) y dónde falla (precisión, matices del sistema) es mejor que decidir en función del hype de Twitter
- Estar dentro del código permite percibir cuándo presionar y cuándo aflojar
- Se detecta cuándo la arquitectura se vuelve demasiado compleja o cuándo la deuda técnica pasa a ser un problema real
- Un gerente que depende solo de reportes puede perder de vista muchas cosas
2. Para enfocarme en lo que hago bien y disfruto
- Construir organización y gestionar personas no es algo que disfrute especialmente
- La gestión de ingeniería requiere dinámicas interpersonales, evaluaciones de desempeño y diseño organizacional
- Es una función importante, pero no es donde están sus mayores fortalezas
- Por eso se contrata a excelentes engineering managers y líderes
- Ellos lo hacen mejor y además lo disfrutan
- Así el CTO puede enfocarse en desarrollo de producto, resolución de problemas técnicos y programación
- Una startup es como una “maratón en formato sprint”, así que el rol se diseña alrededor del tipo de trabajo que mantiene el interés y permite correr rápido durante mucho tiempo
- Esa ha sido una forma sostenible por años, y muy importante para la empresa
3. Porque las herramientas de IA ampliaron el apalancamiento
- Hace unos años era difícil encontrar tiempo para programar mientras se atendía el trabajo estratégico
- A medida que la empresa crecía, el día se llenaba de reuniones y de tareas fuera de la zona de fortalezas
- Fue una de las etapas profesionalmente más duras
- Las herramientas modernas de IA cambiaron esa ecuación de forma fundamental (especialmente en los últimos meses)
- La productividad mejoró entre 2 y 3 veces respecto a antes
- Estas herramientas no reemplazan el criterio ni el conocimiento técnico; de hecho, hacen que esas habilidades valgan más
- Si se le indica a una herramienta de IA: “construye una exportación de datos que coincida con el formato existente de exportación CSV, pero que incluya tres campos adicionales de la tabla de perfiles de usuario”, puede generar correctamente la mayor parte del código
- Existe un contexto profundo sobre qué se necesita exactamente y dónde encontrarlo
- Un ingeniero que no conoce esa parte del codebase tardaría bastante tiempo en entender los detalles
- El trabajo pasó de “escribir cada línea de código” a “proveer contexto, tomar decisiones y evaluar soluciones”
- Y por suerte, hay mucho contexto acumulado
Encontrar la forma que te funciona
- Al definir el rol de CTO, se tomó como referencia la publicación de Greg Brockman sobre cómo definir el rol de CTO en Stripe
- Tras hablar con varios CTO, se reconoció que hay una variación enorme en la forma que puede tomar el rol
- Algunos CTO son visionarios técnicos, otros constructores de organización, otros están centrados en infraestructura
- Lo que comparten los grandes CTO es que identifican dónde pueden crear más valor considerando sus habilidades específicas, sus intereses y la situación de la empresa
- En este caso, eso significa escribir mucho código
- Se disfruta más construir software que diseñar organizaciones
- Se es especialmente efectivo por el conocimiento profundo del cliente y del codebase
- Se contratan engineering managers sólidos
- Pero este es un camino personal, no una receta
- El rol de CTO es muy flexible
- Construcción organizacional, estrategia de producto y más: el liderazgo técnico puede tomar muchas formas según las fortalezas, la fuente de energía y las necesidades de la empresa
- Para los ingenieros que temen que liderar implique abandonar el trabajo técnico: hay muchos caminos posibles
- La clave es identificar en qué eres excepcionalmente bueno de forma única
5 comentarios
Soy CTO en ejercicio y discrepo mucho con este artículo.
Coincido al 100% en que no hay que dejar de programar, pero para eso basta con hacer open source que no esté relacionado con el producto de la empresa. Creo que es una postura válida solo desde la perspectiva de que, como fundador técnico de una startup en etapa inicial, tienes que trabajar como todoterreno.
Qué bueno para él… ¿pero y la empresa?
Debería hacer un trabajo acorde al sueldo que recibe…
Me parece extraño que un CTO se encargue directamente de un proyecto experimental. Si le dieran suficiente tiempo al equipo operativo, podrían hacerlo bien. Lo que más me desconcierta es que un proyecto experimental de largo plazo tenga que ser llevado solo por el CTO. Si tiene autoridad para asignar recursos, bastaría con conseguir recursos aparte para un proyecto experimental y darles suficiente tiempo al equipo operativo.
Un camino personal... habrá que administrarlo bien para que no sigan aumentando las partes de gestión dentro de la organización.
Comentarios en Hacker News
Si estuviera pensando a qué empresa postularme y viera una entrada de blog donde el CTO presume que hace commits de código todos los fines de semana, yo me prepararía para salir corriendo
El rol de un líder es crear una cultura organizacional sana, y presumir trabajo de fin de semana va en la dirección opuesta
Además, decir públicamente que resolvieron un problema de un cliente en un solo día saltándose revisión legal o de ingeniería es una señal de alerta
En una startup en etapa inicial, la cultura es completamente distinta, y este tipo de texto incluso funciona como un filtro para descartar talento no adecuado
El código que escribo suele ser para mejoras internas de DevEx o para resolver deuda técnica
Nunca se omite revisión legal, y lo que hago se queda más en nivel PoC que en código de producción
Para un CTO fundador es importante mantenerse cerca del código, pero la clave es no perder el equilibrio
El rol de CTO cambia según la empresa
Como en el caso de Stripe con Greg Brockman, hay CTOs que son visionarios tecnológicos, otros que son arquitectos organizacionales, y otros más centrados en infraestructura
En mi caso, disfruto programar y me involucro a fondo con los clientes y con la base de código, así es como más valor genero
El título de “CTO” tiene una definición ambigua
Algunos CTO vienen del mundo fundador y programan con libertad, mientras que otros trabajan de cara al cliente y hasta pierden acceso al código
Por otro lado, también existen CTOs autoritarios
Al final, solo tiene sentido preguntar “¿por qué programa?” si antes se aclara qué tipo de CTO es
En ese caso, el nombre CTO no es más que una división de funciones
El CTO se enfoca en estrategia y dirección, mientras el VP se concentra en la gestión diaria de ingeniería
Da igual si lo logra construyendo organización o programando directamente
Cuando alguien de gestión escribe código directamente, puede distorsionar las revisiones de código y generar confusión en el equipo
Al final, probablemente esa persona no es realmente un CTO, sino que en el fondo sigue siendo desarrollador
No estoy totalmente en contra de que un CTO programe, pero en este caso parece que está faltando cumplimiento del rol de CTO
El liderazgo técnico real lo lleva un ingeniero fundador, pero la estructura problemática es que recibe mucha menos compensación
Un CTO sin línea de reporte y que solo programa me parece más cercano a un rol de desarrollador senior que a uno estratégico
A mí también me ofrecieron algo así, pero al final no era más que un título formal
Supongo que el rol cambiará cuando la organización crezca
En una startup pequeña, mi trabajo es avanzar los sprints junto al equipo, resolver la causa cuando el calendario se atrasa, y cuidar a quien esté quemado
Pero si, por lo que dice el texto, el equipo ni siquiera tiene margen para intentar proyectos de IA de moda, entonces eso ya es un problema organizacional
En vez de que el CTO programe directamente, debería resolver este tipo de cuellos de botella sistémicos
En cada empresa, el papel de alguien “senior” o “head” puede ser completamente distinto
Los problemas que aparecen cuando un CTO se mete demasiado en programar son claros
Distorsión en la revisión de PR, descuido del trabajo principal, confusión de roles e invasión de la autonomía del equipo
La idea de que “un CTO no debe programar y solo debe hacer estrategia” es una forma de pensar mecánica
La esencia de una empresa tecnológica es entregar valor, y a veces lo más valioso puede ser que el CTO implemente directamente una funcionalidad importante en un solo día
Incluso podría ser un día mucho más productivo que una reunión de KPI
A veces hace falta que alguien de nivel C recupere directamente el sentido de campo
A veces alguien llega a ser CTO solo por ser cofundador
Si intentara entrar a otra empresa con ese enfoque, quizá ni siquiera alcanzaría el nivel de staff engineer
Por último, el hecho de que la página de precios del sitio web de la empresa no muestre precios reales puede generar confusión, así que convendría corregirlo