Hay una transformación ocurriendo en la forma en la que se construyen los productos digitales. Durante años, la escala se ha medido en equipos: más personas, más capas, más especialización. Pero algo está cambiando.
En esa transición aparece la figura de Valia Merino, actualmente en Agile TV, con una trayectoria que cruza tecnología, negocio y producto sin pedir permiso a las fronteras tradicionales.
Su recorrido no es lineal. Es más bien una suma de capas: formación multidisciplinar en tecnología, humanidades y empresa —UAM, EOI, IE, UNAM, entre otras— y una carrera que empieza en Ernst & Young como programador en 1998.
A partir de ahí, el patrón se repite: tecnología como eje, pero aplicada siempre a entornos distintos. SAP R/3, consultoría, Capgemini, Optiva Media, EPAM… hasta llegar a un punto donde el rol deja de ser solo técnico.
Hoy, en Agile TV, combina ventas, operaciones y desarrollo de producto en piezas críticas del sistema. Y eso, de alguna forma, define su visión del CTO.
El CTO del futuro: menos volumen, más criterio
Cuando se le pregunta cómo evolucionará la figura del CTO en los próximos 10 años, Valia no duda en situar la inteligencia artificial como punto de inflexión.
Pero no en el sentido habitual.
“Las fronteras entre los negocios basados en licencias y los basados en servicios van a desaparecer.”
En su visión, el concepto tradicional de producto también se diluye. Y con él, cambia el rol del CTO.
“El CTO será alguien con un equipo más reducido, más senior, más crítico y con una visión end-to-end muy aguda.”
Cómo se llega a CTO: experiencia antes que método
“Experiencia, primero mucha experiencia en proyectos de base tecnológica, ya sean de software u operaciones.”
La formación ayuda, pero no sustituye la exposición real a proyectos complejos. Y ahí aparece una idea recurrente en su discurso: no todos los proyectos enseñan lo mismo.
“Hay proyectos y proyectos.”
Después de la experiencia, llegan otros dos pilares: formación continua —real, aplicada— y una comprensión profunda del impacto de la IA en la industria.
Libros, papers y otras formas de aprender
La forma de mantenerse al día de Valia está más cerca del flujo continuo de investigación, papers y voces de referencia que de una lista cerrada de lecturas. Sigue a perfiles que considera determinantes y consume conocimiento en formatos menos lineales, más cercanos a la actualización constante que a la lectura estructurada.
Pero hay una obra que sí destaca cuando piensa en su desarrollo profesional.
“The Entrepreneurial State: Debunking Public vs. Private Sector Myths”, de Mariana Mazzucato.
Un libro que pone el foco en el papel de los programas públicos en el impulso de la innovación tecnológica, especialmente en Estados Unidos, y en cómo la relación entre sector público y privado ha sido históricamente más entrelazada de lo que suele reconocerse.
Más que una referencia puntual, funciona como una forma de entender el contexto en el que se construye la innovación.
Deuda técnica: cuando el problema es de definición, no de código
En su visión, la deuda técnica rara vez es solo técnica. Es, sobre todo, una consecuencia de cómo se define el trabajo.
“Es un tema recurrente que lastra la relación con los clientes y condiciona la ejecución de los proyectos.” El origen, en muchos casos, está antes de la primera línea de código.
Dependencias obsoletas, proveedores inestables o, sobre todo, falta de claridad en los requisitos.
“Muchas veces el problema está en no tener bien definido el alcance desde el principio.”
En su experiencia, incluso los documentos funcionales pueden convertirse en el punto de fallo si no están bien alineados.
Medir la deuda técnica: cuando el impacto es negocio, no ingeniería
Valia no cree en una única métrica universal. Depende del contexto.
A veces son tickets en Jira. A veces son impactos financieros directos en releases. Y otras veces, el impacto es puramente de negocio.
Como ejemplo, lo explica de forma muy concreta:
“Si una funcionalidad impide lanzar una oferta que genera ingresos directos, el impacto es evidente.”
En su caso, incluso menciona escenarios donde dependencias técnicas —como problemas en reproductores o dispositivos concretos— pueden bloquear directamente productos comerciales.
La deuda técnica solo se entiende bien cuando empieza a afectar al negocio, no cuando intentas cuantificarla.
Deuda técnica: cuando el problema no es el código, sino el contexto
La deuda técnica rara vez aparece como un fallo evidente. Suele llegar de forma silenciosa, acumulándose en decisiones pequeñas que, con el tiempo, condicionan todo el sistema.
En muchos casos, no es un problema de ingeniería pura, sino de definición, alcance y dependencias externas. Es un tema recurrente que, además, termina afectando tanto a la relación con clientes como a la ejecución de los proyectos.
“La buena noticia es que ahora tiene una solución, casi milagrosa.”
Estrategia: parar, rediseñar o continuar
La deuda técnica no nace de una única causa, sino de la combinación de factores que se van encadenando con el tiempo. Dependencias tecnológicas que se quedan atrás, proveedores que no cumplen el ritmo esperado o, sobre todo, una definición inicial insuficiente del alcance. En ese sentido, uno de los puntos críticos está en cómo se formula el trabajo desde el principio. “Por ejemplo, no tener bien definido en un FSR (Informe o Documento de Especificación Funcional) genera una confusión continua en el alcance de un proyecto o sistema.”
A eso se suma otro elemento habitual: la gestión de expectativas con los clientes finales, que amplifica cualquier desviación técnica y convierte problemas acotados en fricciones estructurales.
No existe una única forma de abordar la deuda técnica. En algunos casos, el sistema puede evolucionar de forma progresiva. En otros, el problema es estructural desde su origen.
“Absolutamente. A veces es mejor parar y empezar desde cero.”
La clave no está en la urgencia de la solución, sino en la calidad del diagnóstico: entender si el sistema todavía admite evolución o si ha alcanzado un punto de bloqueo donde seguir iterando solo aumenta la complejidad.
Cuando es posible, la estrategia es arquitectónica: evolucionar sin interrumpir el flujo del producto. Cuando no lo es, entra en juego una decisión más drástica, pero a veces necesaria: el reinicio controlado.
Porque no toda deuda técnica se comporta igual. Algunas se corrigen. Otras, simplemente, se sustituyen.
IA: de la decisión al cuello de botella
La inteligencia artificial ya no es un factor periférico en la toma de decisiones técnicas. En muchas organizaciones, ha pasado a ocupar un papel estructural.
En el caso de Valia, su influencia no es puntual ni experimental, sino transversal.
“De forma absoluta, es una piedra angular.”
La IA condiciona tanto la forma en la que se diseñan los sistemas como la manera en la que se priorizan decisiones técnicas dentro de la organización.
De generar código a revisarlo: el nuevo desplazamiento del problema
Uno de los cambios más significativos que introduce la inteligencia artificial en el desarrollo de software no está en su capacidad de generación, sino en su impacto en la cadena de validación.
La creación de código, que durante años ha sido el componente más costoso del proceso, se ha convertido en una tarea cada vez más automatizada y accesible.
Pero ese desplazamiento tiene una consecuencia directa.
“La generación de código mediante IA ha dejado de ser una promesa para convertirse en una práctica industrial habitual.”
Y, al hacerlo, reorganiza por completo el flujo de trabajo:
“La IA abarata radicalmente la parte que antes era muy cara —crear código— y traslada toda la presión a la parte que sigue dependiendo del criterio humano —revisarlo—.”
“El cuello de botella no desaparece; se desplaza al Pull Request.”
El rol del CTO en la era de la IA
El CTO, en este contexto, deja de ser un perfil exclusivamente técnico. Pasa a ser un actor central en la adopción y gobernanza de la IA. Debe evangelizar, estructurar y asegurar que la transformación no rompa el sistema.
“Primero ser evangelista. Segundo velar por el buen gobierno. Tercero adaptar la organización.”
Y añade algo importante: la IA no es un área.
Es transversal.
“Debe estar presente en todos los tipos de trabajo y tareas.”
Cómo experimentar sin romper producción
La estrategia no es compleja, pero sí deliberada. Separar. Reducir escala. Controlar impacto.
“Usando equipos pequeños, dos personas nada más.”
El objetivo no es limitar la innovación, sino evitar que afecte a sistemas críticos.
Decidir sigue siendo la parte más difícil
La trayectoria de Valia Merino no encaja en la narrativa clásica del CTO técnico que escala sistemas. Es una evolución distinta: la de alguien que ha ido desplazándose desde la ejecución hacia la interpretación del sistema completo.
En su visión, el futuro no pertenece a los equipos más grandes. Sino a los más precisos.
Y quizá por eso su definición del CTO del futuro no habla de tecnología.
Habla de criterio.
Gracias por compartir tu visión con nosotros, Valia. Nos vemos en próximas ediciones de Perspectiva CTO.
