En el caso de Álvaro García Loaisa, el camino hasta convertirse en CTO no sigue una línea recta. Empieza en el sector espacial, pasa por sistemas de control y dinámica de vuelo, continúa por la geolocalización y las metodologías ágiles y atraviesa compañías muy distintas entre sí: desde una startup de cinco personas hasta una fintech británica con sistemas críticos a gran escala.
Hoy es CTO de Libnova, empresa española especializada en software de preservación digital para archivos, universidades y bibliotecas de referencia internacional. Desde 2024, cuando se incorporó como Head of Engineering, ha trabajado no solo en la transformación del departamento de ingeniería, sino también en cómo se organiza y funciona el resto de la compañía. Desde 2025, ya como CTO, ese trabajo se ha ampliado a una cuestión que atraviesa prácticamente toda la organización: cómo construir equipos autónomos, alineados con el negocio y capaces de decidir qué merece la pena construir.
Porque esa es, probablemente, una de las ideas que más se repiten a lo largo de la conversación: el CTO ya no puede limitarse a controlar la tecnología.
Tiene que decidir dónde poner la atención. Y, cada vez más, también cuándo no construir.
Del espacio a la ingeniería de producto
La trayectoria de Álvaro comienza en GMV, donde pasó por el departamento de Sistemas de Control y participó en el primer centro de control de satélites multifamilia. Después llegó al departamento de Dinámica de Vuelo y, más adelante, el salto a Deimos Space.
Allí empezó a trabajar en soluciones de geolocalización y descubrió las metodologías ágiles. La experiencia fue suficientemente transformadora como para convertirse en evangelizador ágil dentro de la compañía.
Después llegó SuperTruper, una empresa pequeña, de unas cinco personas, donde la autonomía era prácticamente una necesidad. Más adelante, en OSOCO, profundizó todavía más en esa forma de trabajar y descubrió qué significaban realmente los equipos autogestionados y autónomos, aplicando Lean y Agile de manera intensiva.
La siguiente parada fue INCLAM, donde intentó trasladar todo ese aprendizaje a un contexto mucho más legacy. Y después llegó un cambio de escala importante.
En 2020 se incorporó a Tymit, una fintech británica especializada en tarjetas de crédito. Allí evolucionó desde Senior hasta Principal Software Engineer y trabajó con sistemas críticos a gran escala.
Todo ese recorrido termina confluyendo en Libnova. Primero como Head of Engineering y, desde 2025, como CTO.
Pero hay algo que se mantiene constante a lo largo de todas esas etapas: la convicción de que la ingeniería no puede funcionar aislada del producto ni del negocio.
“Mi forma de pensar está muy orientada a producto”, explica.
Y ahí aparece una de las claves de su manera de entender el liderazgo técnico: conseguir que las personas que forman los equipos no sean simplemente ejecutores de tareas, sino ingenieros de producto capaces de entender qué están construyendo, para quién y qué impacto tiene.
Un CTO no debería ser el cuello de botella
Para Álvaro, una de las mejores formas de medir el trabajo de un CTO no tiene que ver directamente con métricas técnicas.
Tiene que ver con su propia ausencia.
“Un CTO no escala por lo que él mismo sabe hacer, sino por cuántas decisiones buenas se toman sin que él tenga que estar presente”.
La frase resume una filosofía de liderazgo basada en la autonomía.
Un departamento que necesita consultar cada decisión importante con su CTO puede parecer muy controlado. Pero, desde su perspectiva, probablemente sea justo lo contrario: una organización que todavía no ha conseguido generar suficiente criterio compartido.
Por eso, una de sus prioridades es formar líderes y crear equipos capaces de tomar decisiones por sí mismos.
El objetivo no es desaparecer. Es dejar de ser imprescindible.
“Si el departamento funciona igual de bien cuando te vas dos semanas de vacaciones, has hecho bien tu trabajo”.
Esta idea también cambia la manera de entender el impacto del rol. El éxito de un CTO no está necesariamente en todo aquello que controla, sino en todo aquello que puede dejar de controlar porque el sistema ya funciona.
Y para que eso ocurra, la autonomía no puede significar que cada equipo haga lo que quiera. Tiene que existir alineamiento.
El CTO como jardinero
Si tuviera que explicar qué hace realmente un CTO más allá del título, Álvaro no elegiría la metáfora del arquitecto. Elegiría la del jardinero.
“Para mí, un CTO es más como un jardinero que como un arquitecto”.
La diferencia está en cómo entendemos el software.
Un edificio, una vez terminado, permanece relativamente estable. El software no. Cada funcionalidad que se incorpora continúa viva mientras exista en el sistema. Hay que mantenerla, entenderla, adaptarla y convivir con ella cada vez que se modifica algo a su alrededor.
Por eso utiliza la imagen de un jardín.
Las funcionalidades se plantan. Los procesos son parte del sistema de riego. La deuda técnica y la obsolescencia son maleza. Y hay momentos en los que añadir nuevas plantas deja de tener sentido porque toca podar lo que ya ha crecido demasiado.
“Si dejas de cuidar una parte del jardín, no se queda igual: se descontrola”.
El CTO no tiene que plantar personalmente cada una de esas plantas.
Tiene que ayudar a decidir cuáles merecen la pena, dónde colocarlas, qué zonas necesitan atención y qué mecanismos hacen posible que el jardín no dependa de una única persona para mantenerse.
Y hay algo especialmente interesante en esta metáfora: cuando el trabajo está bien hecho, casi no se nota.
“Los equipos sienten que trabajan con libertad, que las cosas ‘simplemente crecen’”.
Hasta que algo deja de cuidarse. Entonces es cuando el CTO aparece.
Tres cualidades para un CTO: producto, autonomía y criterio
Si tuviera que quedarse con solo tres cualidades esenciales para un CTO, Álvaro lo tiene bastante claro.
La primera es la mentalidad de producto.
Un CTO que solo entiende de tecnología puede tomar decisiones técnicas excelentes y decisiones de negocio equivocadas. Entender por qué se construye algo es tan importante como saber cómo construirlo.
Porque a veces la mejor decisión es decir que no.
Incluso cuando técnicamente se puede hacer.
“Sin esto, terminas construyendo software perfecto que a nadie le importa y nadie usa”.
La segunda cualidad es la capacidad de generar autonomía en otros. No se trata de acumular conocimiento, sino de multiplicarlo.
La tercera es el criterio para priorizar bajo incertidumbre.
Y aquí la inteligencia artificial introduce un cambio importante. Si cada vez resulta más barato y rápido construir, la pregunta deja de ser principalmente si algo se puede hacer.
La pregunta es si merece la pena hacerlo.
“Con la IA abaratando cada vez más la ejecución, la escasez ya no es ‘¿podemos construirlo?’ sino ‘¿merece la pena construirlo, y ahora?’”.
Producto para saber qué construir. Autonomía para no convertirse en cuello de botella. Y criterio para decidir entre todas las cosas que podrían hacerse.
Los tres grandes retos siguen siendo humanos
Paradójicamente, cuando se habla de los desafíos más difíciles de un CTO, Álvaro no empieza por la arquitectura, la tecnología o la IA.
Empieza por las personas.
El primero es la gestión de equipos: contratar, retener, dar feedback, gestionar motivaciones distintas y ayudar a crecer a personas diferentes.
“El conocimiento técnico, con el tiempo, se aprende. Gestionar personas de forma consistente, bajo presión y sin perder la empatía, no se automatiza nunca”.
El segundo es el alineamiento entre equipos y departamentos.
Porque la autonomía mal entendida puede generar precisamente el problema contrario al que intenta resolver.
Si cada equipo optimiza su propia parcela, el resultado global puede empeorar.
Ingeniería tiene que entender a producto. Producto a ventas. Ventas a operaciones. Operaciones a finanzas. Y todos necesitan compartir una misma visión de negocio.
El tercer desafío es la conversación difícil.
Decir que no. Comunicar una decisión impopular. Explicar algo que alguien no quiere escuchar.
“Lo que realmente cuesta es tener la conversación honesta que ese problema exige, en el momento adecuado, con la persona adecuada”.
En el fondo, los tres retos tienen algo en común.
“La tecnología es predecible, las personas no. Y ese es precisamente el trabajo”.
Construir en pasos pequeños.
Esa misma filosofía aparece cuando Álvaro habla del futuro del rol.
En su opinión, el CTO se va a alejar cada vez más de “controlar la tecnología” para acercarse a decidir qué merece la pena construir y mantener.
La razón tiene mucho que ver con la IA.
Si la ejecución se abarata, producir más software deja de ser necesariamente una ventaja.
Cada funcionalidad tiene un coste que continúa después del lanzamiento. Hay que entenderla, mantenerla y convivir con ella. Por eso, desde una perspectiva Lean, cada nueva pieza de software añade peso al sistema.
La respuesta está en construir en pasos pequeños.
Lanzar antes. Aprender antes. Decidir antes si merece la pena continuar.
“Creo que el trabajo del CTO del futuro va a consistir, cada vez más, en construir menos, pero mejor”.
La IA puede acelerar esos ciclos, pero no decide por sí sola qué debería existir.
Y ahí vuelve a aparecer el criterio.
Cuando el cliente te compara con tu principal competidor
Hay una historia reciente que resume bastante bien esta manera de entender el producto.
Uno de los clientes más antiguos de Libnova sacó a concurso la renovación de su contrato. No era un cliente cualquiera: llevaba mucho tiempo trabajando con ellos, pero decidió comparar seriamente el mercado.
Y la competencia no llegó sola. Contaba además con el apoyo de un consultor externo especializado.
La situación podía haberse planteado como una batalla de presentaciones, roadmaps y promesas.
No lo hicieron.
Siguieron haciendo lo mismo que habían hecho durante los meses anteriores: mantener el producto estable, resolver las incidencias correctamente y escuchar lo que el cliente necesitaba de verdad.
Cuando llegó el momento de decidir, el cliente no comparó discursos. Comparó experiencia. Y Libnova ganó.
No solo mantuvo al cliente: amplió el contrato durante diez años más y prácticamente duplicó lo contratado.
La conclusión de Álvaro es especialmente reveladora:
“No ganamos esa comparativa el día de la presentación. La ganamos en los dos años anteriores”.
En un mercado donde una demo puede ser espectacular y una presentación puede prometer prácticamente cualquier cosa, la ventaja competitiva puede estar en algo mucho menos visible.
El trabajo constante. El producto que funciona. La confianza acumulada.
La IA cambia qué merece la pena construir
En Libnova, la inteligencia artificial ha pasado de ser una cuestión de experimentación individual a contar con una estructura definida.
Cada equipo de ingeniería tiene un AI Champion, con tiempo reservado durante la semana para explorar dónde puede aportar valor la IA.
Pero con una condición importante: no se empieza por la herramienta.
Se empieza por el problema.
Las pruebas están acotadas y tienen una duración máxima de tres o cuatro semanas antes de decidir si tiene sentido llevarlas más lejos.
Ese enfoque ya está cambiando las decisiones técnicas.
Entre los casos identificados están la documentación y comprensión de código legacy, la generación de tests, la revisión automática de código en cada Merge Request y la automatización de scripts de migración e infraestructura.
Pero quizá el cambio más interesante está en la forma de plantear las conversaciones técnicas.
En Libnova están aplicando metodologías como Spec-Driven Development, donde la especificación detallada del problema se convierte en el artefacto central antes de escribir código.
La IA ayuda a generar e iterar sobre esa especificación.
El orden cambia.
Antes se discutía primero la implementación. Ahora se discute primero qué problema se quiere resolver y cómo debe especificarse. La implementación viene después.
Y eso también modifica el papel del CTO: no solo supervisar qué se está construyendo, sino tener más visibilidad sobre por qué se está construyendo.
Experimentar rápido sin romper lo que funciona
La estrategia de adopción de IA en Libnova se apoya en una distinción clara.
Hay cosas con las que se puede experimentar rápido.
Y hay cosas que no.
Documentación, revisión de código, automatizaciones internas o herramientas para los equipos pueden pasar por un carril rápido de experimentación.
Los productos en producción y, especialmente, todo aquello que afecta a datos de clientes, requieren otro nivel de control.
La diferencia no es tecnológica.
Es de riesgo.
“Ser lento en todo te deja fuera del mercado; ser rápido en todo sin gobernanza te puede costar mucho más caro el día que falle donde no debía”.
La madurez está precisamente en saber en qué velocidad debe moverse cada cosa.
Por eso, cuando una prueba demuestra que funciona, no se queda como una ventaja privada del equipo que la descubrió. Se comparte con el resto de la organización y puede convertirse en una práctica estándar.
La innovación no debería competir con la estabilidad.
Debería acabar reforzándola.
De Skills internas a IA dentro del producto
La experimentación ya ha dado lugar a varias herramientas que forman parte del trabajo diario de Libnova.
Han desarrollado Skills reutilizables para revisión de código, generación de documentación, presentaciones y páginas web siguiendo el estilo de marca, además de automatizaciones para las presentaciones de las Sprint Reviews y vídeos de formación creados a partir de documentación técnica.
También han desarrollado herramientas propias para medir mejor el trabajo del departamento y automatizar procesos internos.
El aprendizaje ha sido bastante concreto:
“Una Skill concreta y bien definida escala mucho mejor que un agente genérico que intenta hacerlo todo”.
Pero el principal desafío no ha sido técnico.
Ha sido conseguir que el equipo incorpore estas herramientas como parte habitual de su trabajo, y no simplemente como algo que se prueba cuando queda tiempo.
Mientras tanto, hay otro caso de uso mucho más delicado: aplicar IA dentro del producto principal para extraer metadatos de los archivos que ingieren sus clientes.
Aquí el contexto lo cambia todo.
En preservación digital, un metadato mal extraído puede quedar registrado durante décadas.
Por eso, la velocidad deja de ser la prioridad.
La fiabilidad pasa a serlo.
El piloto mantiene supervisión humana y dedica más esfuerzo a validar precisión y escalabilidad que a acelerar la implementación.
La pregunta no es cuánto tiempo puede ahorrar la IA.
Es cuánto riesgo se puede asumir en cada contexto.
El verdadero riesgo no es experimentar demasiado, sino experimentar igual en todo
Cuando se plantea el dilema entre quedarse al margen de la IA o implementarla demasiado pronto, Álvaro no cree que ninguno de los extremos sea la respuesta.
Pero sí considera más peligroso quedarse fuera.
La barrera de entrada para construir y automatizar está bajando muy rápido. Esperar a tener todas las respuestas antes de empezar puede significar que otros ya hayan aprendido mediante iteración cuando una organización decide finalmente moverse.
Eso no significa eliminar los controles.
Significa aplicarlos donde realmente importan.
En Libnova, la experimentación interna puede avanzar rápido. En cambio, cualquier iniciativa que afecte al producto o a datos de clientes pasa por evaluación de seguridad y aprobación formal.
“Ser lento en todo te deja fuera del mercado; ser rápido en todo sin gobernanza te puede costar mucho más caro el día que falle donde no debía”.
La cuestión, por tanto, no es elegir entre velocidad y seguridad.
Es aprender a distinguir cuándo necesitas cada una.
La IA también cambia el trabajo del propio CTO
La inteligencia artificial no solo está transformando el trabajo de los equipos de ingeniería. También está cambiando cómo Álvaro toma decisiones.
Por un lado, le permite apoyarse más en datos reales y menos en intuiciones.
Análisis de logs, costes de infraestructura o patrones de incidentes pueden hacerse mucho más rápido, lo que facilita tomar decisiones con una base más sólida.
Por otro, introduce un nuevo riesgo.
No tanto que la IA genere código incorrecto —algo que se puede revisar y corregir—, sino que la facilidad para construir haga que aparezca complejidad arquitectónica sin que nadie haya decidido conscientemente introducirla.
“Cuando construir es barato y rápido, la tentación de ‘probar algo’ en producción sin pasar por el proceso de decisión de arquitectura es mayor”.
Por eso, el trabajo del CTO no consiste en frenar la IA. Consiste en controlar el ritmo. Saber cuándo acelerar. Y saber cuándo exigir gobernanza.
Lo que la IA nunca debería decidir
Para Álvaro, hay una frontera clara.
La IA puede analizar datos, generar alternativas o acelerar un análisis.
Pero no debería asumir la responsabilidad final de determinadas decisiones.
“Puedo apoyarme en IA para analizar datos, generar alternativas o acelerar un análisis, pero decidir a quién asciendo, cómo comunico una mala noticia a un cliente, o si asumo un riesgo arquitectónico importante (…) tiene que seguir siendo una decisión de personas”.
Porque existe una diferencia fundamental entre utilizar una herramienta para decidir mejor y delegarle la responsabilidad de decidir.
“El día que deleguemos eso, dejamos de liderar y empezamos simplemente a ejecutar lo que la máquina sugiere”.
Y esa es una línea que, en su opinión, un CTO no debería cruzar.
Si pudiera volver atrás: primero la estructura, después las herramientas
La experiencia de Libnova también ha dejado aprendizajes sobre cómo introducir la IA.
Si pudiera volver un año atrás, Álvaro no empezaría antes con herramientas.
Empezaría antes con estructura.
Durante los primeros meses, cada persona experimentaba por su cuenta. Eso generó entusiasmo, pero también conocimiento disperso.
Alguien encontraba una solución interesante y esa experiencia no necesariamente llegaba al resto.
Hoy lo haría de otra manera.
“Montaría un AI Hub y la red de Champions desde el primer mes”.
También establecería antes las reglas de gobernanza.
No todas las pruebas necesitan el mismo nivel de control. Y cuanto antes se establece esa frontera, menos fricción aparece después.
Pero hay una tercera lección todavía más importante.
Comunicar desde el principio que la IA no sustituye el criterio profesional.
Lo hace más importante.
Los ingenieros que vienen tendrán que saber definir antes de construir
La adopción masiva de IA también está cambiando las habilidades que diferencian a los equipos técnicos.
La primera es saber definir bien el problema.
Si generar código es cada vez más barato, formular correctamente qué se quiere construir se vuelve más valioso.
“La parte puramente técnica de ‘saber programar’ sigue siendo necesaria, pero deja de ser la habilidad diferencial”.
La segunda es saber revisar y validar con criterio.
La IA puede producir resultados que parecen correctos con mucha facilidad. El reto está en detectar cuándo algo aparentemente correcto no lo es.
Y la tercera es la curiosidad aplicada.
No esperar a que alguien diga qué herramienta utilizar, sino preguntarse qué partes del propio trabajo podrían hacerse de otra manera.
La pregunta pasa a ser casi cotidiana:
¿Esto que hago todas las semanas se podría hacer distinto con IA?
Los equipos que mejor aprovechen la tecnología serán los que sepan formular mejores problemas, revisar mejor las respuestas y experimentar de forma constante.
Cómo empezar a prepararse para ser CTO
Para quienes quieran orientarse hacia el rol, Álvaro no recomienda perseguir únicamente el cargo.
Recomienda leer, probar y aprender.
Especialmente sobre gestión de equipos, conflictos, procesos y sistemas.
Entre los libros que más le han influido están Menos software, más impacto, de Eduardo Ferro; This is Lean; Refactor: The CTO’s Guide to Reclaim Your Time and Multiply Your Output; An Elegant Puzzle: Systems of Engineering Management; The CTO Toolbox; The Manager’s Path; Team Topologies; The Five Dysfunctions of a Team; Radical Candor; Modern CTO y Staff Engineer: Leadership beyond the management track.
Cada uno, explica, aporta una pieza diferente: eficiencia y flujo, gestión de personas, diseño organizativo, liderazgo técnico o evolución profesional.
Pero la formación no termina en los libros.
El CTO tiene que entender cómo funcionan conjuntamente ingeniería, producto, ventas, operaciones y finanzas.
Y ahí aparece una idea especialmente importante: la cultura no es algo inmutable.
Se puede transformar. Con tiempo, paciencia y las personas adecuadas.
El impacto de un CTO no está en lo que controla
Si tuviera que quedarme con una sola idea de toda la entrevista, probablemente sería esta:
El impacto de un CTO no debería medirse por cuánto controla, sino por cuánto consigue que funcione sin necesidad de estar encima.
Por cuántas buenas decisiones se toman sin él en la sala. Por cómo habla el resto de la empresa de ingeniería. Y por hasta qué punto las decisiones técnicas están conectadas con objetivos reales de negocio.
El jardinero no puede controlar cada planta. Pero sí puede crear las condiciones para que el jardín crezca.
Gracias, Álvaro, por tu tiempo y por compartir con nosotros tu visión sobre el liderazgo técnico, la autonomía de los equipos y el papel que la IA está empezando a jugar en la evolución del CTO dentro de Perspectiva CTO.
