De developer a CTO: lo que nadie le 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 convertirse en mejor ingeniero. No lo es. Se trata de convertirse 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 le dice sobre esta transición.

Su mejor habilidad se convierte en su mayor lastre

Como desarrollador, le ascendieron porque usted escribía buen código. Resolvía problemas difíciles. Entregaba funcionalidades. Su valor estaba directamente ligado a su producción.

Como CTO, escribir código suele ser un mal uso de su tiempo. No porque programar esté por debajo de usted, sino porque su trabajo ha cambiado. Ya no es responsable de escribir el mejor código. Es responsable de asegurarse 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. Usted escribe código. Resuelve problemas técnicos. Tiene un oficio, y mejora en él con el tiempo. Hay una satisfacción en ello que es difícil de replicar.

Cuando se convierte en CTO, esa identidad se disuelve. Sus días se llenan de actividades que no se sienten como "trabajo real." Está en reuniones sobre contratación. Está revisando presupuestos. Está explicando restricciones técnicas a inversores. Está mediando en desacuerdos entre miembros del equipo. Está 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 miden su productividad por lo que construyen con sus manos, el liderazgo se sentirá profundamente insatisfactorio. Necesitan aprender a medirla por lo que construye su 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.

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

Deje de revisar cada pull request. No necesita aprobar cada línea de código. Defina estándares de código, configure verificaciones automatizadas y confíe en sus desarrolladores senior para revisarse mutuamente. Su revisión debería reservarse para decisiones de arquitectura, no detalles de implementación.

Deje 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. Su trabajo es hacer esa valoración, y requiere entender el contexto de negocio, no solo el técnico.

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

Lo que hay que empezar a hacer

Empiece a delegar el trabajo en el que es mejor. Es contraintuitivo. Usted quiere delegar el trabajo que no le gusta y quedarse con lo interesante. Haga lo contrario. Delegue el trabajo técnico interesante a su equipo. Quédese con el trabajo organizacional, estratégico y de personas. Ahí es donde aporta más valor ahora.

Empiece 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.

Empiece a tener one-on-ones. Conversaciones regulares y programadas con cada persona de su 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.

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

Las habilidades que nadie enseña

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

Contratación. Leer CVs, hacer entrevistas, evaluar encaje cultural, vender su 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. Su 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", su trabajo es explicar qué es realista sin ser despectivo. Cuando el CEO pregunta por qué algo está tardando tanto, necesita 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 cree

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

Durante ese tiempo, se sentirá impostor. Echará de menos programar. Cuestionará si tomó la decisión correcta. Tendrá días en los que querrá 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é le motiva.

Si le 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 sus propias manos, entonces quédese como contribuidor individual. No tiene nada de malo. Los ingenieros senior y staff tienen un impacto enorme.

Si le 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 construye la cosa. Construye 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.