En 540 no hay una única forma de llegar a CTO. En el caso de Gorka Moreno, el camino empieza pronto, casi por necesidad más que por diseño. Primero, unas prácticas en una pequeña empresa de desarrollo mobile en pleno boom de las apps, y después una continuidad natural en ese mismo entorno, cuando BlackBerry todavía convivía con la irrupción de la App Store. Allí, sin demasiada estructura y sin perfiles senior, el liderazgo llega antes del título.
“Era una empresa muy joven y sin nadie con experiencia sénior, así que desde el primer día me tocó liderar y sacar proyectos de clientes”, recuerda.
Esa etapa marca el ritmo de todo lo que vendrá después: aprender deprisa, equivocarse igual de rápido y entender que el liderazgo técnico no siempre llega acompañado de un cargo formal.
Con el tiempo, esa experiencia se traduce en una evolución natural hacia el rol de CTO en aquella primera etapa profesional. Y más adelante, ya con otra madurez y otra ambición, llega el salto definitivo: la creación de 540 junto a sus socios.
“Buscando una forma mejor de trabajar descubrí agile, buenas prácticas… todo lo que hoy doy por sentado. En dos años pasé a CTO”, resume.
Hoy, ya como cofundador y CTO de 540, Gorka mira hacia atrás y ve un hilo continuo: decisiones, aprendizajes y errores que no solo moldearon su forma de trabajar, sino que terminaron empujando la creación de su propia compañía.
Trayectoria: del liderazgo accidental al rol formal
El primer contacto de Gorka con el liderazgo no tiene nada de planificado. Es más bien una consecuencia directa del contexto: un equipo pequeño, sin referentes senior, y proyectos que había que entregar.
“En esa pequeña empresa ya tuve un momento de liderazgo porque éramos cuatro y alguien tenía que tomar decisiones y poner cierto marco”, explica.
Ese aprendizaje acelerado no vino solo con buenas prácticas, sino también con fricción. Con errores. Con presión por entregar. Y con una sensación constante de que el sistema se podía hacer mejor.
La respuesta no fue solo técnica. Fue estructural. Y ahí aparece el giro: la adopción de agile, la búsqueda de prácticas más sostenibles y la evolución natural hacia un rol de CTO.
Pero el punto de inflexión no llega ahí. Llega después, cuando la incomodidad con la forma de trabajar se convierte en impulso emprendedor.
Con otros dos compañeros funda 540. Tres personas, tres clientes, tres formas de entender el desarrollo que empiezan a converger en una idea común: construir software de otra manera.
“Empezamos siendo tres, cada uno al frente de un cliente; conforme hemos crecido, uno se ha centrado en el rol de CEO y yo en el de CTO”, explica.
Hoy la empresa ha crecido hasta unas 35–40 personas. Y con ese crecimiento, el rol vuelve a transformarse.
“Otra vez empieza a ser importante que alguien se preocupe de cosas más generales. Y ahí es donde vuelve el rol de CTO como tal”.
De improvisar liderazgo a darse cuenta de que ya estabas liderando
La evolución del rol atraviesa toda la conversación sin necesidad de forzarla. Pero cuando Gorka habla de ser CTO, no está pensando en código. Ni en estar cerca del código. Está pensando en otra cosa.
Y lo resume con una imagen muy simple:
“Es como en un restaurante. Alguien tiene que encargarse de que el proceso vaya bien, que las comandas salgan en orden, que la calidad sea adecuada, que el trato sea coherente… toda la experiencia”.
No suena técnico. Y no lo es. Es otra cosa.
Es sistema.
Y ese sistema no es una idea bonita. Es gente, procesos, producto, calidad… todo pasando a la vez. Y decisiones que no siempre son técnicas, pero que acaban siendo las que sostienen lo demás.
Porque al final, el CTO no es quien más código escribe. Es quien evita que el contexto se rompa. Quien hace que tenga sentido que ese código exista.
Por eso hay un momento en el que el trabajo cambia de sitio. Ya no está en la línea concreta. Está un poco más arriba. Mirando todo a la vez.
“Es más preocuparse de que las cosas estén funcionando que de la siguiente línea de código que tienes que escribir”.
Y eso no significa desconectarse de lo técnico. Pero sí dejar de vivir ahí dentro todo el rato. Porque incluso cuando sigue habiendo código, la cabeza está en otro lado.
“Me preocupo de que todo esté ordenado, de que se hagan las prácticas adecuadas, de que las conversaciones necesarias se hayan tenido”.
Retos actuales: personas, procesos y el ruido tecnológico
Cuando se le pregunta por los mayores retos de un CTO, Gorka no duda demasiado en el orden.
El primero es claro: las personas.
“Lo más importante es tener las personas adecuadas. Con ellas, cualquier cosa es posible”.
Después vienen los procesos y las herramientas. Pero no como respuesta a modas o tendencias, sino como ajuste fino a lo que realmente necesita la organización.
“Ni dejarse llevar por modas ni por lo que está de actualidad. Hay que pensar qué necesitas tú”.
En ese contexto, el ruido tecnológico se convierte en uno de los problemas más complejos.
“Intentar separar el ruido de la paja. Entender qué es lo que debe permanecer y qué es simplemente una moda”.
Esa tensión aparece especialmente en decisiones de arquitectura o stack tecnológico, donde las presiones externas suelen ser fuertes.
Tecnología y decisiones: cuando el stack deja de ser lo importante
En 540, la aproximación a la tecnología es pragmática. No parte de la pregunta “¿qué tecnología es mejor?”, sino de otra mucho más importante: “¿qué problema estamos resolviendo?”
“Me suelo fijar más en lo que haces con la tecnología que en la tecnología en sí”, explica.
Lenguajes como Python, Java, PHP o JavaScript son, en su opinión, suficientemente buenos en la mayoría de contextos.
El riesgo no está en la elección, sino en la deriva.
“Muchas veces el error es dejarse llevar por modas. Ahora microservicios, ahora otra cosa… y todo tiene que ser eso”.
El criterio que defiende es más sencillo y, a la vez, más difícil de aplicar: simplicidad y contexto.
“¿Qué necesitas ahora? ¿Qué es lo más simple que resuelve tu problema actual?”
Sin embargo, eso no significa quedarse bloqueado en lo conocido.
“Sin caer en el extremo de usar siempre lo que ya sabes aunque no encaje”.
Deuda técnica: el coste invisible que frena sin avisar
La deuda técnica aparece como uno de los temas recurrentes del rol. No tanto por su existencia, sino por su impacto acumulativo.
Para Gorka, el problema no es solo técnico, sino de percepción.
“Es un freno o un coste invisible. Vas tirando, pero no te das cuenta de que te está haciendo ir mucho más lento”.
El riesgo está en ignorarla demasiado tiempo.
“Hasta que no la atacas no desbloqueas”.
La solución, sin embargo, no pasa por detener el desarrollo, sino por integrar la mejora continua dentro del propio flujo de trabajo.
Y siempre con una idea en mente: no todo tiene que arreglarse a la vez.
Escalar sin perder cultura
El crecimiento de 540, de tres personas a varias decenas, plantea una pregunta recurrente en cualquier empresa tecnológica: cómo escalar sin perder identidad.
En su caso, la respuesta ha sido orgánica.
“Hemos crecido muy poco a poco, sin obsesionarnos con crecer rápido”.
El modelo también ha sido clave: incorporación progresiva, confianza y seguimiento cercano.
“Primero entra la persona en 540 y luego se asigna a proyecto”.
La cultura, en este contexto, no se impone. Se observa.
“Confiar en que la persona va a seguir la cultura, aunque no haga las cosas exactamente como las harías tú”.
Y cuando hay dudas, la transparencia se convierte en una gran herramienta.
“Si se empieza a perder la coherencia o la transparencia, ahí tienes un problema”.
Cuando el sistema falla: 100.000€ por un botón que no tocaba tocar
A veces todo el discurso sobre sistemas, procesos y calidad se resume en algo mucho más simple: un botón mal tocado.
En una app móvil de un cliente, activaron por error una licencia de navegación 3D de Here que ni siquiera estaban usando. Costaba 10€ por usuario.
El problema llegó cuando el sistema hizo lo que tenía que hacer: escalar el error.
“Con 10.000 usuarios activos, a final de mes nos llegó una factura de 100.000€”.
Y no había escapatoria fácil: la factura estaba a nombre de 540.
“Y lo mejor: estaba a nombre nuestro, no del cliente”.
Lo interesante no es el error. Es lo que revela.
Que un sistema no falla en el momento en que alguien se equivoca. Falla cuando ese error escala sin fricción, sin control y sin límites claros.
Lo resolvieron tirando de contactos y consiguiendo hablar con el proveedor para cancelar la factura. Pero el aprendizaje se quedó mucho más tiempo.
- Los servicios de terceros los paga el cliente, no el equipo que desarrolla.
- Todo coste por usuario necesita una multiplicación antes de activarse.
- Y, sobre todo, los sistemas sin límites claros no perdonan.
“Diez euros parecen nada hasta que los multiplicas por diez mil”.
Cuando la IA deja de ser herramienta y empieza a ser sistema
La irrupción de la inteligencia artificial ha cambiado el foco del trabajo técnico en 540. No tanto en lo que se construye, sino en cómo se construye.
“Ya no nos preocupamos tanto de cómo escribir una línea concreta, sino de cómo la IA nos ayuda a hacerlo”.
El cambio no es solo de herramientas, sino de mentalidad.
“En lugar de pensar en cómo mejora una persona, pensamos en cómo mejora el sistema que crea software”.
La empresa ha empezado a aplicar IA en casos concretos de producción. No como sustitución, sino como apoyo en procesos muy específicos. Uno de ellos tiene que ver con la gestión de catálogos y presupuestos en una empresa del sector industrial.
El sistema interpreta presupuestos, cruza información con catálogos de productos y sugiere soluciones a partir de reglas de negocio.
Otro caso automatiza la lectura de fichas de producto en documentos comerciales y su integración en el catálogo.
“Antes lo hacía una persona. Ahora lo hace un modelo de lenguaje, aunque siempre con revisión”.
El enfoque es claro: no eliminar el control humano, sino reducir fricción en tareas repetitivas.
El rol del CTO en la adopción de IA
En este nuevo escenario, el CTO asume un papel más estratégico que nunca.
“No solo es ver cómo usamos la IA, sino hacia dónde tenemos que ir”.
El cambio afecta incluso a la definición de roles dentro de la empresa.
“Un desarrollador ya no es alguien que escribe líneas de código durante ocho horas. Es alguien que sabe trabajar con sistemas que escriben código”.
Para gestionar esta transición, han creado distintos grupos internos: espacios de trabajo para compartir aprendizajes, experimentar y anticipar escenarios. Desde sesiones formativas internas hasta grupos más estratégicos que analizan implicaciones a largo plazo.
Consejos: no perseguir el cargo, sino el impacto
Cuando se le pregunta por cómo llegar a CTO, la respuesta es directa.
“No iría con la mentalidad de querer ser CTO”.
Para él, el rol es una consecuencia, no un objetivo.
“Debería ser el resultado de que estás liderando, ampliando tu área de influencia y aparece la oportunidad”.
Y añade un matiz la tecnología no es el centro absoluto.
“Es más importante el producto, las personas y el contexto. La tecnología acompaña”.
Cierre: decidir y sostener la decisión
Si pudiera volver atrás, Gorka tiene claro qué se diría a sí mismo: confiar más en la intuición.
“Muchas veces tenía claro el camino, pero me dejaba llevar por lo que me decían”.
Una duda que atraviesa toda la entrevista es precisamente esa tensión entre consenso y convicción.
“Si crees que esa es la solución, insiste. No intentes adaptarla hasta perderla por el camino”.
En su visión, el liderazgo no consiste en tener siempre razón. Pero sí en sostener las decisiones cuando hay convicción detrás.
Y quizá ahí esté una de las ideas más consistentes de toda la entrevista: el trabajo del CTO no es solo técnico, ni organizativo, ni estratégico.
Es sistémico.Y, como en un restaurante, si el sistema falla, todo lo demás deja de importar.
Gracias Gorka por tu tiempo y por abrir las puertas a nuestro proyecto Perspectiva CTO para compartir cómo vive el rol de CTO y todo lo que hay detrás del trabajo en 540.
