Hay una idea que se repite en casi todas las empresas tecnológicas cuando empiezan a crecer: “ya escalaremos eso luego”.
El problema, como ha aprendido Alex a lo largo de más de 25 años de carrera, es que ese “luego” suele llegar antes de lo esperado… y casi nunca en buen momento.
En esta nueva entrega de “Perspectiva CTO”, hablamos con Alex Fernández “Pinchito”, socio de Fullcircle Digital Solutions, uno de esos perfiles que ha vivido la industria del software desde casi todos los ángulos posibles: consultoría, banca, startups en hipercrecimiento, adquisiciones internacionales y arquitectura de sistemas a gran escala.
Su historia empieza en la Física, en una época en la que las ondas gravitacionales todavía no habían sido detectadas y el software era potente, pero aún no había empezado a ser inabarcable. Entró en grandes organizaciones —consultoría, banca— donde aprendió pronto una de las reglas no escritas del sector: la estabilidad no es una virtud, es una obligación.
Cinco años en ING Direct terminaron de consolidar una idea muy clara: en sistemas críticos, lo importante no es construir rápido, sino construir algo que no te obligue a volver cada dos días a arreglarlo.
Y después de eso, el cambio.
En 2012 decidió dar un giro de escenario.
A partir de ahí el contexto cambia por completo.
“Me pasé al loco mundo de las startups.”
Su trayectoria no es lineal. Tampoco pretende serlo. Es más bien una sucesión de entornos donde la tecnología no solo tenía que funcionar, sino aguantar el tipo cuando el negocio empezaba a ir demasiado rápido.
El CTO del futuro no programa más: decide mejor
Cuando se le pregunta hacia dónde va el rol del CTO, Alex no entra en modas tecnológicas ni predicciones.
Lo resume así:
“Saber gestionar el foco de una empresa siempre ha sido importante. Trabajar en modo comandos se va a volver crucial incluso en sectores más tradicionales.”
Detrás de la frase hay una idea clara: el CTO no es quien más cosas sabe, sino quien mejor decide qué cosas no se hacen.
En su visión, la tecnología no compite por innovación aislada, sino por atención. Y la atención es limitada.
Por eso, el CTO deja de ser únicamente un rol técnico. Se convierte, en muchos casos, en el sistema que regula las prioridades reales de la empresa.
O, dicho de forma otra directa: la persona que acaba teniendo que poner límites cuando todo el mundo quiere abrir caminos.
El primer equipo de un CTO no es el equipo técnico
“El primer equipo de un CTO es el comité ejecutivo.”
El CTO no empieza en GitHub. Empieza en la mesa donde se decide qué es importante para la empresa.
De ahí su recomendación:
“Entender el producto y el negocio es siempre un valor seguro.Aprende a calibrar riesgos y beneficios.”
Porque al final, casi todo lo relevante en tecnología empresarial se reduce a eso: decidir qué riesgo estás dispuesto a asumir… y cuándo.
Cuando tres millones de eventos por segundo no perdonan
En su etapa en Devo, Alex trabajó en sistemas de ingesta capaces de procesar hasta tres millones de eventos por segundo.
En uno de esos cambios aparentemente rutinarios, algo dejó de encajar.
La nueva versión de Node.js no rendía como debería en conexiones seguras.
Lo que parecía un problema de rendimiento terminó convirtiéndose en una autopsia de bajo nivel:
“Al biseccionar el código C++, vimos que se había eliminado el buffering en el canal.”
El tipo de problema que no aparece en documentación, ni en dashboards, ni en logs bonitos.
Aparece cuando el sistema simplemente deja de comportarse como debería.
Alex reportó el problema con benchmarks a la comunidad de Node.js, y la actualización se detuvo.
Un año después, una desarrolladora en Barcelona propuso un parche que no solo corrigió el problema, sino que mejoró el rendimiento global.
Este tipo de historias no suelen aparecer en los CVs, pero explican muy bien algo que sí define su carrera: la frontera entre entender un sistema… y descubrir cómo se comporta realmente cuando nadie lo está mirando.
Deuda técnica: el crecimiento invisible que nadie quiere mirar
Hay conceptos en ingeniería que empiezan siendo abstractos y terminan siendo inevitables.
La deuda técnica es uno de ellos. Alex lo describe como:
“La degradación progresiva de la velocidad de desarrollo del equipo.”
El problema no es cuándo aparece. Es cuándo deja de percibirse como un problema.
Y es en ese punto cuando surge una de las tentaciones más recurrentes en los equipos técnicos: la llamada “reescritura mítica”.
“La reescritura mítica, que nos hará perder foco durante meses o incluso años.”
Un proyecto total que promete ordenar el sistema desde cero… a cambio de una pausa prolongada disfrazada de progreso.
Para evitar ese escenario, su enfoque es deliberadamente incremental, pero efectivo: tests, despliegue continuo y mejoras progresivas del sistema.
Porque, en su experiencia, la deuda técnica rara vez desaparece de golpe.
Se reduce mientras el sistema sigue vivo.
Cómo se mide y cómo se combate
Medir la deuda técnica no pasa por una única métrica, sino por un conjunto de señales. Alex la observa a través de la velocidad de desarrollo del equipo, la calidad del código y la complejidad de los cambios, junto con métricas DORA como la frecuencia de despliegues, el tiempo de entrega, el porcentaje de fallos en producción o el tiempo medio de recuperación. Más que un número concreto, es una tendencia: cuando el sistema empieza a ralentizarse de forma sostenida, algo se está acumulando debajo.
El origen suele ser silencioso. No calibrar bien la calidad necesaria del código en cada contexto y permitir que pequeñas decisiones se acumulen sin una estrategia de corrección. Para evitarlo, su enfoque es incremental: tests, despliegue continuo y mejoras progresivas integradas en el flujo normal del producto. Sin grandes reinicios ni proyectos paralelos. Porque la deuda técnica no se elimina con un gesto único: se gestiona mientras el sistema sigue evolucionando.
IA: utilidad práctica sin delegación de criterio
Sobre inteligencia artificial, Alex adopta una postura deliberadamente alejada del ruido. No hay promesa de transformación radical en la toma de decisiones técnicas dentro de la organización.
El uso está, pero es operativo más que estructural. La IA aparece como herramienta de apoyo en tareas concretas: prototipos, refactorizaciones, trabajos mecánicos o maquetación. Siempre bajo una condición que se repite de forma constante:
“Siempre bajo supervisión humana.”
El punto crítico, en su visión, no es la capacidad de la tecnología, sino el margen de decisión que se le delega. Porque ahí es donde empiezan los problemas difíciles de revertir.
“La decisión y la gobernanza tienen que ser siempre humanas.”
Y el riesgo no es teórico. Cuando la adopción no está suficientemente controlada, el sistema puede perder coherencia interna, tanto a nivel técnico como de producto.
“Implementar IA sin control puede llevar a sistemas con poca coherencia de producto.”
Por eso, el enfoque que han adoptado es más pragmático que experimental sin estructura: un AI Lab separado del entorno de producción donde poder explorar sin comprometer lo que ya funciona. Una forma de permitir innovación sin trasladar incertidumbre al sistema crítico.
La idea de fondo es sencilla, pero consistente con toda su visión del desarrollo de software: experimentar sí, pero sin romper el equilibrio operativo que sostiene el negocio.
Lo que realmente cambia cuando llevas 25 años en esto
Después de más de dos décadas en la industria, Alex no se queda con una conclusión única.
Se queda con una constante:
la tecnología cambia rápido, pero los problemas humanos no tanto.
La gestión del foco, la toma de decisiones, el entendimiento del negocio y la capacidad de decir “no” siguen siendo los factores críticos.
La IA acelera. La nube escala. Los lenguajes evolucionan. Pero el trabajo del CTO sigue teniendo mucho de lo mismo: tomar decisiones con información incompleta… y vivir con sus consecuencias.
Libros para entender mejor a las personas (más que la tecnología)
Si hay algo que se repite en las lecturas que menciona Alex es que ninguna tiene que ver directamente con tecnología.
The Five Dysfunctions of a Team, de Patrick Lencioni, le sirve para entender por qué los equipos fallan incluso cuando todo “debería funcionar”. The Culture Map, de Erin Meyer, pone el foco en cómo la cultura cambia por completo la forma en la que se interpreta un mismo mensaje. Y Cognitive Dissonance, de Joel Cooper, entra en un terreno más incómodo: cómo las personas justifican sus decisiones incluso cuando saben que no encajan del todo.
No son libros de arquitectura de software. Son libros de comportamiento. Y quizá por eso encajan con alguien que lleva décadas construyendo sistemas donde la parte difícil nunca ha sido solo técnica.
Escalar también es saber decir no
La trayectoria de Alex Fernández no es la historia de alguien que ha seguido una tendencia tecnológica.
Es la historia de alguien que ha estado en suficientes sistemas complejos como para entender que la verdadera dificultad no está en construir software, sino en evitar que se rompa cuando todo lo demás crece alrededor.
En un sector obsesionado con la innovación constante, su visión introduce una idea necesaria:
a veces, la mejor arquitectura no es la más moderna, sino la que menos interrumpe lo que ya funciona.
Desde “Perspectiva CTO”, agradecemos a Alex Fernández su tiempo y su mirada sobre una industria que cambia rápido, pero no siempre aprende igual de rápido.
