De developer a CTO: lo que nadie te cuenta

El salto de desarrollador a CTO es la transición de carrera más malinterpretada en tech. La gente asume que se trata de convertirte en mejor ingeniero. No lo es. Se trata de convertirte en un tipo de profesional completamente diferente.

He hecho esta transición yo mismo, primero como CTO en OneRagtime y después a través de varios roles de liderazgo. Ahora enseño un módulo llamado "Developer to CTO" en Harbour.Space University en Barcelona. En cada cohorte, veo a los estudiantes enfrentarse a las mismas revelaciones que tuve hace años.

Esto es lo que nadie te dice sobre esta transición.

Tu mejor habilidad se convierte en tu mayor lastre

Como desarrollador, te ascendieron porque escribías buen código. Resolvías problemas difíciles. Entregabas funcionalidades. Tu valor estaba directamente ligado a tu producción.

Como CTO, escribir código suele ser un mal uso de tu tiempo. No porque programar esté por debajo de ti, sino porque tu trabajo ha cambiado. Ya no eres responsable de escribir el mejor código. Eres responsable de asegurarte de que el mejor código se escriba.

Lo pasé mal con esto en OneRagtime. Al principio, yo era quien construía todo: la Platform, el Core, Deepdive. Estaba metido de lleno en la codebase Django, escribiendo Python, desplegando en Docker Swarm. Y se sentía bien porque era familiar. Sabía que estaba siendo productivo porque podía medirlo en commits y funcionalidades.

Pero a medida que el equipo crecía, cada hora que pasaba programando era una hora que no dedicaba a las cosas que solo yo podía hacer: definir la dirección técnica, alinear el trabajo de ingeniería con la estrategia de negocio, o desbloquear a gente que estaba atascada.

El día más duro de mi carrera fue cuando me di cuenta de que necesitaba cerrar mi IDE y empezar a dedicar la mayoría de mi tiempo a reuniones, documentos y one-on-ones. Se sentía como una degradación. Me llevó meses aceptar que ese era el trabajo real.

La crisis de identidad es real

Los desarrolladores tienen una identidad clara. Escribes código. Resuelves problemas técnicos. Tienes un oficio, y mejoras en él con el tiempo. Hay una satisfacción en ello que es difícil de replicar.

Cuando te conviertes en CTO, esa identidad se disuelve. Tus días se llenan de actividades que no se sienten como "trabajo real." Estás en reuniones sobre contratación. Estás revisando presupuestos. Estás explicando restricciones técnicas a inversores. Estás mediando en desacuerdos entre miembros del equipo. Estás escribiendo documentos que nadie leerá.

Al final de un día típico como CTO en OneRagtime, a menudo no podía señalar una sola cosa concreta que hubiera "construido." Ni código, ni arquitectura, ni funcionalidad desplegada. Solo conversaciones, decisiones y planes. Me llevó tiempo entender que esas conversaciones y decisiones eran el producto de mi trabajo.

Les digo a mis estudiantes en Harbour.Space: si mides tu productividad por lo que construyes con tus manos, el liderazgo se sentirá profundamente insatisfactorio. Necesitas aprender a medirla por lo que construye tu equipo.

Lo que hay que dejar de hacer

Aquí va una lista concreta de cosas que tuve que dejar de hacer cuando pasé de desarrollador a CTO. Esta lista me habría ahorrado un año de errores.

Deja de ser el primero en responder preguntas técnicas. Cuando alguien de tu equipo pregunta cómo resolver un problema, tu instinto es responder inmediatamente. Resiste. Pregúntale primero qué piensa. Si siempre tienes la respuesta, tu equipo nunca desarrolla la capacidad de encontrar respuestas por sí mismo.

Deja de revisar cada pull request. No necesitas aprobar cada línea de código. Define estándares de código, configura verificaciones automatizadas y confía en tus desarrolladores senior para revisarse mutuamente. Tu revisión debería reservarse para decisiones de arquitectura, no detalles de implementación.

Deja de optimizar para la mejor solución técnica. La mejor solución técnica no siempre es la correcta. A veces la solución "suficiente" que sale esta semana es mejor que la perfecta que sale el mes que viene. Tu trabajo es hacer esa valoración, y requiere entender el contexto de negocio, no solo el técnico.

Deja de trabajar solo. Como desarrollador, podías ponerte auriculares y desaparecer en un problema durante horas. Como CTO, el aislamiento es peligroso. Las decisiones que tomas afectan a todo el equipo. Si las tomas sin input, cometerás errores que podrían haberse evitado fácilmente.

Lo que hay que empezar a hacer

Empieza a delegar el trabajo en el que eres mejor. Es contraintuitivo. Quieres delegar el trabajo que no te gusta y quedarte con lo interesante. Haz lo contrario. Delega el trabajo técnico interesante a tu equipo. Quédate con el trabajo organizacional, estratégico y de personas. Ahí es donde aportas más valor ahora.

Empieza a comunicar decisiones técnicas en términos de negocio. Cuando proponía cambios de arquitectura en OneRagtime, dejé de enmarcarlos como mejoras técnicas. En su lugar: "Este cambio nos permitirá entregar el dashboard de inversores dos semanas antes" o "Esta migración reducirá nuestros costes de infraestructura un 30 %." Los interlocutores de negocio no se preocupan por la arquitectura limpia. Se preocupan por la velocidad y el coste.

Empieza a tener one-on-ones. Conversaciones regulares y programadas con cada persona de tu equipo. No actualizaciones de estado. Conversaciones reales sobre cómo están, qué les frustra y qué quieren aprender. En Consentio, mis one-on-ones con cada uno de mis diez ingenieros son las reuniones más importantes de mi agenda. Ahí es donde descubro lo que realmente está pasando, no en los tableros de Jira ni en los standups.

Empieza a decir "no lo sé." Como desarrollador, admitir que no sabes algo se siente como incompetencia. Como CTO, es esencial. No puedes ser experto en todo lo que hace tu equipo. Decir "no lo sé, pero lo averiguo" o "no lo sé, ¿qué piensas tú?" construye más confianza que fingir que tienes todas las respuestas.

Las habilidades que nadie enseña

Hay habilidades que necesitas como CTO que ningún programa de ingeniería cubre.

Contratación. Leer CVs, hacer entrevistas, evaluar encaje cultural, vender tu empresa a candidatos. Era terrible en esto al principio. Contraté a gente técnicamente fuerte pero incapaz de colaborar. Me llevó varias experiencias dolorosas aprender que un gran desarrollador que no puede trabajar con otros es peor que un buen desarrollador que sí puede.

Resolución de conflictos. Los equipos técnicos discrepan. Sobre arquitectura, sobre prioridades, sobre estilo de código. Tu trabajo es resolver esos desacuerdos de forma que mantenga el respeto y haga avanzar al equipo. Es más difícil que cualquier problema técnico al que me he enfrentado.

Gestión de presupuesto. Entender los costes de infraestructura, planificar plantilla, prever los gastos de ingeniería. En OneRagtime, tenía que justificar cada contratación de ingeniería ante los inversores. En Consentio, gestiono presupuestos que afectan directamente la rentabilidad de la empresa. Nadie me enseñó esto. Lo aprendí cometiendo errores.

Gestión de stakeholders. Traducir entre la realidad de la ingeniería y las expectativas del negocio. Cuando un product manager pide una funcionalidad "para el viernes", tu trabajo es explicar qué es realista sin ser despectivo. Cuando el CEO pregunta por qué algo está tardando tanto, necesitas traducir la complejidad técnica a términos que pueda entender y sobre los que pueda actuar.

La transición lleva más tiempo del que crees

En Harbour.Space, doy a los estudiantes un plazo: espera que la transición de desarrollador a CTO lleve de dos a tres años antes de sentirte realmente cómodo. No de dos a tres meses. Años.

Durante ese tiempo, te sentirás impostor. Echarás de menos programar. Cuestionarás si tomaste la decisión correcta. Tendrás días en los que querrás tirar los libros de gestión y simplemente abrir el portátil para escribir código.

Es normal. Todo CTO que respeto ha pasado por ello. Los que llegaron al otro lado lo hicieron aceptando que la incomodidad es parte del proceso, no una señal de que algo va mal.

¿Merece la pena?

Me hacen esta pregunta en cada cohorte. Mi respuesta siempre es la misma: depende de qué te motiva.

Si te motiva el oficio de escribir código, la elegancia de una función bien diseñada, la satisfacción de resolver un problema técnico difícil con tus propias manos, entonces quédate como contribuidor individual. No tiene nada de malo. Los ingenieros senior y staff tienen un impacto enorme.

Si te motiva construir cosas que importen, ver un producto triunfar en el mercado, ver a un equipo crecer y mejorar, entonces el camino de CTO merece la incomodidad. La palanca es diferente. Ya no construyes la cosa. Construyes el equipo que construye la cosa. Y cuando funciona, la satisfacción es profunda.

Eso es lo que intento transmitir en Harbour.Space. No que todo el mundo deba ser CTO. Sino que quienes eligen serlo deberían saber en qué se están metiendo realmente.