{"id":36223,"date":"2026-07-16T14:17:05","date_gmt":"2026-07-16T12:17:05","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=36223"},"modified":"2026-07-16T14:17:06","modified_gmt":"2026-07-16T12:17:06","slug":"gorka-moreno-cto-540","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/es\/perspectiva-cto\/gorka-moreno-cto-540\/","title":{"rendered":"\u201cNo escribes l\u00edneas de c\u00f3digo, haces que el sistema funcione\u201d – Gorka Moreno"},"content":{"rendered":"\n

En 540 no hay una \u00fanica forma de llegar a CTO. En el caso de Gorka Moreno<\/a>, el camino empieza pronto, casi por necesidad m\u00e1s que por dise\u00f1o. Primero, unas pr\u00e1cticas en una peque\u00f1a empresa de desarrollo mobile en pleno boom de las apps, y despu\u00e9s una continuidad natural en ese mismo entorno, cuando BlackBerry todav\u00eda conviv\u00eda con la irrupci\u00f3n de la App Store. All\u00ed, sin demasiada estructura y sin perfiles senior, el liderazgo llega antes del t\u00edtulo.<\/p>\n\n\n\n

\u201cEra una empresa muy joven y sin nadie con experiencia s\u00e9nior, as\u00ed que desde el primer d\u00eda me toc\u00f3 liderar y sacar proyectos de clientes\u201d, recuerda.<\/p>\n\n\n\n

Esa etapa marca el ritmo de todo lo que vendr\u00e1 despu\u00e9s: aprender deprisa, equivocarse igual de r\u00e1pido y entender que el liderazgo t\u00e9cnico no siempre llega acompa\u00f1ado de un cargo formal.<\/p>\n\n\n\n

Con el tiempo, esa experiencia se traduce en una evoluci\u00f3n natural hacia el rol de CTO en aquella primera etapa profesional. Y m\u00e1s adelante, ya con otra madurez y otra ambici\u00f3n, llega el salto definitivo: la creaci\u00f3n de 540 junto a sus socios.<\/p>\n\n\n\n

\u201cBuscando una forma mejor de trabajar descubr\u00ed agile, buenas pr\u00e1cticas\u2026 todo lo que hoy doy por sentado. En dos a\u00f1os pas\u00e9 a CTO\u201d, resume.<\/p>\n\n\n\n

Hoy, ya como cofundador y CTO de 540, Gorka mira hacia atr\u00e1s y ve un hilo continuo: decisiones, aprendizajes y errores que no solo moldearon su forma de trabajar, sino que terminaron empujando la creaci\u00f3n de su propia compa\u00f1\u00eda.<\/p>\n\n\n\n

Trayectoria: del liderazgo accidental al rol formal<\/strong><\/h2>\n\n\n\n

El primer contacto de Gorka con el liderazgo no tiene nada de planificado. Es m\u00e1s bien una consecuencia directa del contexto: un equipo peque\u00f1o, sin referentes senior, y proyectos que hab\u00eda que entregar.<\/p>\n\n\n\n

\u201cEn esa peque\u00f1a empresa ya tuve un momento de liderazgo porque \u00e9ramos cuatro y alguien ten\u00eda que tomar decisiones y poner cierto marco\u201d, explica.<\/p>\n\n\n\n

Ese aprendizaje acelerado no vino solo con buenas pr\u00e1cticas, sino tambi\u00e9n con fricci\u00f3n. Con errores. Con presi\u00f3n por entregar. Y con una sensaci\u00f3n constante de que el sistema se pod\u00eda hacer mejor.<\/p>\n\n\n\n

La respuesta no fue solo t\u00e9cnica. Fue estructural. Y ah\u00ed aparece el giro: la adopci\u00f3n de agile, la b\u00fasqueda de pr\u00e1cticas m\u00e1s sostenibles y la evoluci\u00f3n natural hacia un rol de CTO.<\/p>\n\n\n\n

Pero el punto de inflexi\u00f3n no llega ah\u00ed. Llega despu\u00e9s, cuando la incomodidad con la forma de trabajar se convierte en impulso emprendedor.<\/p>\n\n\n\n

Con otros dos compa\u00f1eros funda 540. Tres personas, tres clientes, tres formas de entender el desarrollo que empiezan a converger en una idea com\u00fan: construir software de otra manera.<\/p>\n\n\n\n

\u201cEmpezamos 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\u201d, explica.<\/p>\n\n\n\n

Hoy la empresa ha crecido hasta unas 35\u201340 personas. Y con ese crecimiento, el rol vuelve a transformarse.<\/p>\n\n\n\n

\u201cOtra vez empieza a ser importante que alguien se preocupe de cosas m\u00e1s generales. Y ah\u00ed es donde vuelve el rol de CTO como tal\u201d.<\/p>\n\n\n\n

De improvisar liderazgo a darse cuenta de que ya estabas liderando<\/strong><\/h2>\n\n\n\n

La evoluci\u00f3n del rol atraviesa toda la conversaci\u00f3n sin necesidad de forzarla. Pero cuando Gorka habla de ser CTO, no est\u00e1 pensando en c\u00f3digo. Ni en estar cerca del c\u00f3digo. Est\u00e1 pensando en otra cosa.<\/p>\n\n\n\n

Y lo resume con una imagen muy simple:<\/p>\n\n\n\n

\u201cEs 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\u2026 toda la experiencia\u201d.<\/p>\n\n\n\n

No suena t\u00e9cnico. Y no lo es. Es otra cosa.<\/p>\n\n\n\n

Es sistema.<\/p>\n\n\n\n

Y ese sistema no es una idea bonita. Es gente, procesos, producto, calidad\u2026 todo pasando a la vez. Y decisiones que no siempre son t\u00e9cnicas, pero que acaban siendo las que sostienen lo dem\u00e1s.<\/p>\n\n\n\n

Porque al final, el CTO no es quien m\u00e1s c\u00f3digo escribe. Es quien evita que el contexto se rompa. Quien hace que tenga sentido que ese c\u00f3digo exista.<\/p>\n\n\n\n

Por eso hay un momento en el que el trabajo cambia de sitio. Ya no est\u00e1 en la l\u00ednea concreta. Est\u00e1 un poco m\u00e1s arriba. Mirando todo a la vez.<\/p>\n\n\n\n

\u201cEs m\u00e1s preocuparse de que las cosas est\u00e9n funcionando que de la siguiente l\u00ednea de c\u00f3digo que tienes que escribir\u201d.<\/p>\n\n\n\n

Y eso no significa desconectarse de lo t\u00e9cnico. Pero s\u00ed dejar de vivir ah\u00ed dentro todo el rato. Porque incluso cuando sigue habiendo c\u00f3digo, la cabeza est\u00e1 en otro lado.<\/p>\n\n\n\n

\u201cMe preocupo de que todo est\u00e9 ordenado, de que se hagan las pr\u00e1cticas adecuadas, de que las conversaciones necesarias se hayan tenido\u201d.<\/p>\n\n\n\n

Retos actuales: personas, procesos y el ruido tecnol\u00f3gico<\/strong><\/h2>\n\n\n\n

Cuando se le pregunta por los mayores retos de un CTO, Gorka no duda demasiado en el orden.<\/p>\n\n\n\n

El primero es claro: las personas.<\/p>\n\n\n\n

\u201cLo m\u00e1s importante es tener las personas adecuadas. Con ellas, cualquier cosa es posible\u201d.<\/p>\n\n\n\n

Despu\u00e9s 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\u00f3n.<\/p>\n\n\n\n

\u201cNi dejarse llevar por modas ni por lo que est\u00e1 de actualidad. Hay que pensar qu\u00e9 necesitas t\u00fa\u201d.<\/strong><\/p>\n\n\n\n

En ese contexto, el ruido tecnol\u00f3gico se convierte en uno de los problemas m\u00e1s complejos.<\/p>\n\n\n\n

\u201cIntentar separar el ruido de la paja. Entender qu\u00e9 es lo que debe permanecer y qu\u00e9 es simplemente una moda\u201d.<\/p>\n\n\n\n

Esa tensi\u00f3n aparece especialmente en decisiones de arquitectura o stack tecnol\u00f3gico, donde las presiones externas suelen ser fuertes.<\/p>\n\n\n\n

Tecnolog\u00eda y decisiones: cuando el stack deja de ser lo importante<\/strong><\/h2>\n\n\n\n

En 540, la aproximaci\u00f3n a la tecnolog\u00eda es pragm\u00e1tica. No parte de la pregunta \u201c\u00bfqu\u00e9 tecnolog\u00eda es mejor?\u201d, sino de otra mucho m\u00e1s importante: \u201c\u00bfqu\u00e9 problema estamos resolviendo?\u201d<\/p>\n\n\n\n

\u201cMe suelo fijar m\u00e1s en lo que haces con la tecnolog\u00eda que en la tecnolog\u00eda en s\u00ed\u201d, explica.<\/p>\n\n\n\n

Lenguajes como Python, Java, PHP o JavaScript son, en su opini\u00f3n, suficientemente buenos en la mayor\u00eda de contextos.<\/p>\n\n\n\n

El riesgo no est\u00e1 en la elecci\u00f3n, sino en la deriva.<\/p>\n\n\n\n

\u201cMuchas veces el error es dejarse llevar por modas. Ahora microservicios, ahora otra cosa\u2026 y todo tiene que ser eso\u201d.<\/p>\n\n\n\n

El criterio que defiende es m\u00e1s sencillo y, a la vez, m\u00e1s dif\u00edcil de aplicar: simplicidad y contexto.<\/p>\n\n\n\n

\u201c\u00bfQu\u00e9 necesitas ahora? \u00bfQu\u00e9 es lo m\u00e1s simple que resuelve tu problema actual?\u201d<\/p>\n\n\n\n

Sin embargo, eso no significa quedarse bloqueado en lo conocido.<\/p>\n\n\n\n

\u201cSin caer en el extremo de usar siempre lo que ya sabes aunque no encaje\u201d.<\/p>\n\n\n\n

Deuda t\u00e9cnica: el coste invisible que frena sin avisar<\/strong><\/h2>\n\n\n\n

La deuda t\u00e9cnica aparece como uno de los temas recurrentes del rol. No tanto por su existencia, sino por su impacto acumulativo.<\/p>\n\n\n\n

Para Gorka, el problema no es solo t\u00e9cnico, sino de percepci\u00f3n.<\/p>\n\n\n\n

\u201cEs un freno o un coste invisible. Vas tirando, pero no te das cuenta de que te est\u00e1 haciendo ir mucho m\u00e1s lento\u201d.<\/p>\n\n\n\n

El riesgo est\u00e1 en ignorarla demasiado tiempo.<\/p>\n\n\n\n

\u201cHasta que no la atacas no desbloqueas\u201d.<\/p>\n\n\n\n

La soluci\u00f3n, sin embargo, no pasa por detener el desarrollo, sino por integrar la mejora continua dentro del propio flujo de trabajo.<\/p>\n\n\n\n

Y siempre con una idea en mente: no todo tiene que arreglarse a la vez.<\/p>\n\n\n\n

Escalar sin perder cultura<\/strong><\/h2>\n\n\n\n

El crecimiento de 540, de tres personas a varias decenas, plantea una pregunta recurrente en cualquier empresa tecnol\u00f3gica: c\u00f3mo escalar sin perder identidad.<\/p>\n\n\n\n

En su caso, la respuesta ha sido org\u00e1nica.<\/p>\n\n\n\n

\u201cHemos crecido muy poco a poco, sin obsesionarnos con crecer r\u00e1pido\u201d.<\/p>\n\n\n\n

El modelo tambi\u00e9n ha sido clave: incorporaci\u00f3n progresiva, confianza y seguimiento cercano.<\/p>\n\n\n\n

\u201cPrimero entra la persona en 540 y luego se asigna a proyecto\u201d.<\/p>\n\n\n\n

La cultura, en este contexto, no se impone. Se observa.<\/p>\n\n\n\n

\u201cConfiar en que la persona va a seguir la cultura, aunque no haga las cosas exactamente como las har\u00edas t\u00fa\u201d.<\/p>\n\n\n\n

Y cuando hay dudas, la transparencia se convierte en una gran herramienta.<\/p>\n\n\n\n

\u201cSi se empieza a perder la coherencia o la transparencia, ah\u00ed tienes un problema\u201d.<\/p>\n\n\n\n

Cuando el sistema falla: 100.000\u20ac por un bot\u00f3n que no tocaba tocar<\/strong><\/h2>\n\n\n\n

A veces todo el discurso sobre sistemas, procesos y calidad se resume en algo mucho m\u00e1s simple: un bot\u00f3n mal tocado.<\/p>\n\n\n\n

En una app m\u00f3vil de un cliente, activaron por error una licencia de navegaci\u00f3n 3D de Here que ni siquiera estaban usando. Costaba 10\u20ac por usuario.<\/p>\n\n\n\n

El problema lleg\u00f3 cuando el sistema hizo lo que ten\u00eda que hacer: escalar el error.<\/p>\n\n\n\n

\u201cCon 10.000 usuarios activos, a final de mes nos lleg\u00f3 una factura de 100.000\u20ac\u201d.<\/p>\n\n\n\n

Y no hab\u00eda escapatoria f\u00e1cil: la factura estaba a nombre de 540.<\/p>\n\n\n\n

\u201cY lo mejor: estaba a nombre nuestro, no del cliente\u201d.<\/p>\n\n\n\n

Lo interesante no es el error. Es lo que revela.<\/p>\n\n\n\n

Que un sistema no falla en el momento en que alguien se equivoca. Falla cuando ese error escala sin fricci\u00f3n, sin control y sin l\u00edmites claros.<\/p>\n\n\n\n

Lo resolvieron tirando de contactos y consiguiendo hablar con el proveedor para cancelar la factura. Pero el aprendizaje se qued\u00f3 mucho m\u00e1s tiempo.<\/p>\n\n\n\n