Si el equipo que gestiona toda esa infraestructura centralizada es el mismo, es posible mantener cierto control sobre la situación. Pero si lo que queremos es fomentar una cultura DevOps, donde cada equipo de desarrollo sea autónomo y gestione sus servicios de principio a fin, entonces más nos vale establecer fronteras claras y seguras en la infraestructura.

Las consecuencias de no hacerlo pueden ser devastadoras. He visto desaparecer bases de datos enteras de producción durante un ciclo de desarrollo. También he presenciado cómo una prueba de carga lanzada alegremente en staging provocaba una contención brutal en los discos compartidos y la consiguiente caída de los sistemas de producción. Es mucho más común de lo que creemos.

Para evitar estos desastres y habilitar la autonomía, hay que contar con un buen diseño de segmentación de nuestras cargas de trabajo. De hecho, es uno de los pilares de la arquitectura de plataformas que trato en mi libro Crafting Platforms, cuyo capítulo dedicado a la segmentación publicaré precisamente esta misma semana. Hoy quiero traer la esencia de este concepto a la newsletter.

El porqué

Formalmente, un segmento es un límite físico o lógico que delimita un conjunto de cargas de trabajo, recursos y usuarios en la infraestructura. No se trata solo de agrupar cosas en carpetas. Lo fundamental de un segmento es que define un conjunto específico de capacidades, guardrails y restricciones.

Si tienes una infraestructura monolítica, dependes de complejas configuraciones de red o de políticas de IAM (Identity and Access Management) frágiles para evitar exposiciones. La segmentación te proporciona aislamiento por diseño. Sus principales beneficios son:

• Reducción del radio de explosión (Blast Radius): Contiene los fallos. Si un proceso se vuelve loco o si hay una brecha de seguridad, el desastre se queda aislado en su parcela.

• Reducción de la carga cognitiva: Un ingeniero no tiene que lidiar con toda la infraestructura de la empresa, sino solo con la que es relevante para su servicio.

• Diferentes reglas para contextos distintos: Las estrictas políticas de auditoría que necesitas en producción son un estorbo en un entorno de desarrollo donde hace falta experimentar.

Cuatro dimensiones

Para no acabar gestionando cientos de cuentas anidadas ni paralizando a la organización cuando ocurra un problema por tenerlo todo agrupado en una sola cuenta, recomiendo segmentar por cuatro dimensiones principales.

• Sector (o Dominio): Separa el contexto del negocio del contexto interno o de habilitación. Un sector define una gobernanza y un propósito claros. Por ejemplo:

  • Core (o Platform): herramientas de ingeniería (control de versiones, CI/CD, observabilidad) y de gestión de la infraestructura (management plane).

  • E-commerce: productos enfocados al cliente que generan ingresos.

• Tier: Separa las cargas de trabajo según su criticidad y el tipo de datos que manejan. He preferido “tier” (nivel) en lugar de “entorno” para no pisar la terminología que usan los desarrolladores: dev, test o qa. Un Tier impone políticas de datos y de acceso. Por ejemplo:

  • Sandbox (Non-Production): donde hay más libertad y se usan datos sintéticos. Las políticas son más relajadas.

  • Live (Production): donde hay más restricciones y se usan datos reales.

• Region: Organiza físicamente dónde están los recursos (p. ej., europe, us o apac) para reducir la latencia o cumplir con leyes de residencia de datos.

• Tenant: Aísla la infraestructura por propietario (el equipo de desarrollo o el cliente).

Espectro de aislamiento

No todas las vallas son de la misma altura ni están hechas del mismo material. Según lo que compartas con tus “vecinos”, el nivel de protección varía considerablemente. Es lo que llamamos el espectro de aislamiento:

• Aislamiento lógico: como los namespaces de Kubernetes o las funciones de Lambda. Es el más ligero y barato, pero en general compartes el kernel del sistema operativo, el hardware y la red. Un vecino ruidoso puede afectarte con facilidad.

• Aislamiento de runtime: máquinas virtuales independientes. Aquí un hipervisor separa las cargas, pero sigues compartiendo la red y el hardware físico con otros.

• Aislamiento de red: VPCs o VNets separados. Las cargas no pueden comunicarse directamente entre sí, aunque vivan en la misma cuenta administrativa.

• Aislamiento administrativo: cuentas de AWS o suscripciones de Azure independientes. Es el estándar de oro para la segmentación de plataformas. Aquí aislas la identidad y el acceso, la facturación y los límites de las APIs de la nube.

• Aislamiento de hardware: servidores dedicados (bare metal) o sistemas totalmente desconectados de la red (air-gapped) para casos de extrema seguridad o regulación.

La regla general que siempre recomiendo es utilizar el límite administrativo como mínimo para separar los sectores y los tiers. No intentes ahorrar costes mezclando producción y desarrollo, ni servicios internos con externos en la misma suscripción mediante etiquetas. El riesgo de un error humano en una política de IAM es muy alto.

¿Cómo funciona en la práctica?

Vamos a diseñar una plataforma imaginaria que aplique estos conceptos.

Primero, empezamos definiendo dos grandes sectores (podrían haber más como security, it u otras líneas de negocio de la empresa):

• core ( o platform): es el sector interno. Aquí viven las herramientas de gestión compartidas, tus repositorios de código, tus runners de CI/CD, tu stack de observabilidad y las herramientas de seguridad.

• ecommerce: es un sector de negocio. Aquí viven las aplicaciones de tus equipos de producto, las que atienden el tráfico de clientes y generan ingresos.

Luego, establecemos dos tiers o niveles de criticidad:

• sandbox: es la zona de juegos. Políticas relajadas, datos sintéticos o anonimizados, acceso amplio para que los desarrolladores puedan romper cosas e innovar sin miedo.

• live: es producción. Datos reales de clientes, control de acceso humano estrictamente auditado y despliegues automatizados obligatorios.

Al combinar sector y tier, creamos nuestros segmentos de alto nivel. Por ejemplo, el segmento core-live es tu entorno de producción de servicios de ingeniería, mientras que ecommerce-sandbox es donde los equipos de producto prueban sus nuevas versiones antes de pasarlas a producción.

Dentro del segmento ecommerce-live, las cosas siguen siendo demasiado grandes. Aquí entran en juego las dimensiones de la región y del tenant.

Si nuestra empresa opera a nivel global, dividimos ese segmento en regiones geográficas (p. ej., europe y us). Y finalmente, dentro de la región, dividimos por tenant, es decir, por equipo. El equipo de payments tendrá su parcela en cada región y el de recommendations, las suyas. El equipo de payments no podrá acceder por defecto a la base de datos de recommendations.

El modelo de segmentación determina qué aislamos, pero la nube define cómo lo implementamos en la práctica mediante primitivas nativas.

La regla de oro (y el estándar de la industria) es utilizar fronteras administrativas en los niveles más altos. Esto significa que tu combinación $sector-$tier determinará si se creará una cuenta de AWS o una suscripción de Azure. Tendrás una suscripción de Azure para ecommerce-live, otra para ecommerce-sandbox, otra para core-live, etc.

Así garantizamos que una credencial comprometida en ecommerce-sandbox de la empresa no pueda interactuar de ninguna manera con las APIs que gestionan la infraestructura en producción.

A medida que bajamos hacia las subdivisiones más granulares, como región y tenant, solemos usar límites lógicos y de red. Por ejemplo, dentro de la suscripción ecommerce-live, puedes aislar los recursos del tenant payments en la región europe con un resource group (en Azure) payments-europe. O definir redes virtuales por región ecommerce-live-europe. Aquí ya depende un poco de la naturaleza de cada organización.

¡Muchas gracias por leerme!

Esta semana mi foco está en Claude Code. Llevo tiempo usando Copilot y ha disparado mi productividad, pero Claude Code (la interfaz de agente de Anthropic para la terminal) propone un cambio de paradigma. Anthropic no fue la primera en llegar, pero con sus modelos Haiku y Sonnet, y la potencia de Opus, está liderando el camino de los agentes de programación. Pero no es una herramienta mágica. Si le “escupes” dos instrucciones, te dará algo funcional. Pero para sacarle el verdadero partido, hay que diseñar flujos de trabajo avanzados (sub agents, skills, commands, hooks, etc.) que se adapten a tus necesidades reales. Y en eso estoy. En otro artículo os hablaré de los resultados.

Cuando profundizas en el uso de agentes y en cómo están revolucionando los procesos de desarrollo de software, piensas en Eliyahu M. Goldratt y su famosa Teoría de las Restricciones. Goldratt decía que en cualquier sistema complejo siempre hay un cuello de botella que limita la capacidad total. Si optimizas cualquier otra parte que no sea esa restricción central, básicamente estás perdiendo el tiempo.

Durante la primera ola de la IA generativa, pensábamos que el cuello de botella era escribir código y que los ingenieros desaparecerían de un plumazo. Pero la realidad nos ha golpeado en la cara. Parece que escribir código nunca fue el verdadero cuello de botella. Ese problema simplemente se ha desplazado hacia arriba (especificación) y hacia abajo (verificación). Armin Ronacher, creador de Flask, lo definía hace poco en su blog como “The Final Bottleneck”: la IA acelera la creación a ritmos absurdos, pero la responsabilidad final (accountability) y la capacidad de revisión humana imponen un límite. De nada sirve que Claude Code genere una feature en segundos si luego tardas tres horas en asegurar que ese código sea seguro, eficiente y no rompa nada en producción. Es decir, no queremos enviar cosas a ciegas a producción cuando tenemos que hacernos cargo de mantenerlas.

Y hay otra restricción crítica en la que coincide el análisis de The New Stack: el contexto. El verdadero cuello de botella en 2026 es la brecha entre el conocimiento implícito que los ingenieros llevan en la cabeza (arquitectura, decisiones históricas, dependencias lógicas) y lo que el agente es capaz de asimilar. Además, el esfuerzo cognitivo cambia por completo. Revisar el código generado por IA exige realizar ingeniería inversa a partir de una interpretación de los requisitos basada en la probabilidad.

Este desplazamiento de los cuellos de botella hacia el contexto y la validación no es solo un reto técnico, sino también puramente organizativo. Existe un concepto en marketing, acuñado por Geoffrey Moore y aplicable igualmente en este caso, conocido como “Crossing the Chasm”.

Moore divide el ciclo de adopción en Innovators, Early Adopters, Early Majority, Late Majority y Laggards, advirtiendo que existe un “abismo” mortal entre los visionarios (Early Adopters) y los pragmáticos (Early Majority). Muchas iniciativas (o productos) fracasan al intentar dar ese salto sin la estrategia adecuada.

Ahora mismo, en muchas empresas, los Innovators están abrazando lo que en la industria se ha bautizado como “vibe coding”: tirar un prompt rápido, cruzar los dedos, iterar a lo loco y subir a producción la caja negra que escupe el modelo. Es rápido, sí, pero es terriblemente frágil para sistemas a gran escala.

Si intentas cruzar el abismo y venderle ese “vibe coding” a tu Early Majority (los perfiles más pragmáticos y conservadores de tu empresa), te vas a estrellar contra un muro. Ellos son quienes sufren el problema del contexto y de la responsabilidad. No quieren generar código más rápido si el precio es pasarse el fin de semana arreglando incidentes incomprensibles cuando están on-call. Necesitan ver que la IA no es un cañón sin control, sino un sistema seguro y predecible.

Por tanto, si estás liderando la adopción de IA en tu organización, tu estrategia de gritar “¡usad más los agentes!” no va a funcionar. La estrategia debe enfocarse en resolver los verdaderos problemas junto a tus Early Adopters. Y solo cuando tengas respuestas claras y documentadas a estas preguntas —cuando demuestres que la IA reduce de verdad el esfuerzo cognitivo global—, el Early Majority dará el salto. Y si haces bien ese trabajo, los rezagados acabarán entrando por pura inercia.

¡Muchas gracias por leerme!

Es difícil de comprender cómo una empresa ha llegado a ese punto —y está teniendo tanto éxito— a pesar de sus problemas funcionales. Si además ocupas un puesto de liderazgo (Manager, Director o CTO), la experiencia se convierte en un libro de Elige tu propia aventura, en el que debes navegar por un mar de incertidumbre y tomar decisiones críticas sin tener toda la información sobre la mesa.

El foco: producto vs. deuda organizacional

Casi todas las empresas medianas han pasado por esta fase. El objetivo inicial es encontrar un producto que triunfe (market fit) y, a partir de ahí, escalar. En esa carrera, es normal dejar de lado todo lo que no sea crítico para la supervivencia.

El problema surge cuando ese modelo se encuentra, pero la estructura interna sigue operando como si estuviera en un garaje.

En el libro Scaling People, Claire Hughes Johnson (ex-COO de Stripe) describe esto como un proceso natural de transición de una empresa de 50 personas —donde el fundador lo controla todo— a una empresa de 200 personas, en la que resulta necesario delegar en un equipo de liderazgo. Es aquí donde aparecen los departamentos de People, Producto, Finanzas, Ventas e Ingeniería con entidad propia. Es el momento de poner orden en el caos.

Cambiar el rumbo de un transatlántico

En mis últimos retos profesionales me ha tocado liderar precisamente esta transición. A veces la solución es evidente gracias a la experiencia previa, pero otras veces te enfrentas a situaciones inéditas en las que toca aprender sobre la marcha.

Como mencionaba en mi artículo sobre el Engineering Momentum, cambiar las dinámicas de un equipo no se logra con giros radicales de timón. Los equipos tienen una inercia y una cultura propias. Para cambiar su dirección, hay que “empujar” de forma constante y sutil hacia el nuevo destino. Esto requiere paciencia, perseverancia y, sobre todo, una comunicación sobrehumana.

Cuando llegas a una empresa en esta fase, te asaltan los “porqués”: ¿Por qué no hay tests? ¿Por qué no usamos esta herramienta? ¿Por qué el despliegue es manual? Las respuestas suelen ser variaciones de “no hay tiempo” o “siempre se ha hecho así”. Pero el problema de fondo suele ser la falta de visibilidad sobre el impacto de no hacerlo, o simplemente porque no sabemos qué no sabemos. Como experto, te han contratado para guiarles.

Medir y mejorar

Si estás en esta situación, el primer paso es medir. Sin datos, solo eres otra persona con una opinión. La fórmula que estamos aplicando ahora mismo en mi área de ingeniería es establecer un Modelo de Madurez (CMMI adaptado).

Evaluamos diferentes dimensiones (gestión de bugs, revisión de código, ciclos de feedback, deuda técnica, observabilidad, on-call, etc.) y puntuamos del 1 al 5 dónde estamos. Esto nos permite visualizar las áreas críticas y trazar un plan de acción claro.

La clave del éxito de este modelo no es la métrica en sí, sino el proceso:

1. Self-assessment: El equipo se autoevalúa con honestidad.

2. Peer-assessment: Revisamos los datos para llegar a un consenso.

3. Transparencia: No buscamos culpables, sino “oportunidades de excelencia”.

4. Objetivos: Trazamos un plan de acción para alcanzarlos.

Este no es un ejercicio de “una sola vez”. Tenemos una cadencia mensual para revisar el plan de acción. Es un modelo flexible que evoluciona porque van apareciendo nuevas áreas que queremos medir o porque queremos subir el listón en las que ya dominamos.

A mi compañero y a mí nos está resultando una herramienta de gestión muy buena. Nos da una visión global, nos permite priorizar acciones y, lo más importante, sirve como sesión de terapia de grupo. El equipo se siente parte de la solución, no una pieza que recibe órdenes impuestas.

Al final, liderar en el caos no consiste en imponer el orden de un sargento, sino en dotar al equipo de una brújula para que ellos mismos encuentren el camino hacia la excelencia.

¿Qué os parece este enfoque? ¿Habéis implementado modelos similares?

¡Muchas gracias por leerme!

El año pasado me lancé a la aventura de escribir un libro sobre Ingeniería de Plataformas, un tema que me apasiona y en el que he invertido años de experiencia. Sin embargo, a medida que los capítulos tomaban forma, una sensación incómoda me invadía: el enfoque tradicional ya no me encajaba. Me explico.

Mi biblioteca está llena de libros técnicos. No por coleccionismo, sino porque siempre he preferido el poso que deja un buen libro. Hay obras maestras que me han ayudado no solo a aprender una tecnología concreta, sino también a madurar ideas y a adoptar enfoques disruptivos. Algunos han envejecido mejor que otros (el de Design Patterns del “Gang of Four” sigue ahí), pero la mayoría termina siendo víctima de la obsolescencia tecnológica.

El problema hoy no es que los libros caduquen; es que tengo la convicción de que cada vez vamos a comprar menos libros técnicos. Yo mismo hace tiempo que no adquiero uno, a pesar de que peleo a diario con retos complejos y sigo aprendiendo constantemente. Mis fuentes han cambiado: documentación oficial, blogs especializados, vídeos y, sobre todo, la IA.

Cada día somos más eficientes al delegar en esta tecnología. La integramos en nuestro flujo de trabajo y la usamos como tutor personal. En mi último artículo os contaba cómo la IA se ha vuelto mi aliada indispensable para sacar adelante el Grado de Física. Por eso, la forma en que “alimentamos” a la IA es clave para que siga siendo útil. Si permitimos que el ecosistema se llene de ruido y de contenido de baja calidad, generado por algoritmos sin supervisión, nos hacemos un flaco favor. Necesitamos contenido con rigor, criterio y experiencia real para que estos modelos sigan aprendiendo a partir de fuentes fiables.

Bajo esta premisa, me he dado cuenta de que llego tarde para escribir un libro técnico a la vieja usanza. Por eso, he decidido resetear el enfoque y apostar por un modelo dual:

1. Un libro para humanos: ya sea en formato electrónico o impreso, centrado en un lenguaje claro, en los puntos clave de decisión, en la arquitectura, en los contextos históricos de cada tecnología, en el storytelling y en las “notas del autor”, que aportan ese valor subjetivo que una máquina no tiene.

2. Un repositorio de habilidades para IAs: un conjunto de agentes, skills, comandos, reglas y contextos diseñados específicamente para la IA. El objetivo es que estos agentes aprendan a construir plataformas conforme a los estándares de calidad y seguridad que espero, sin heredar los vicios del código genérico y obsoleto que hay en Internet.

Es decir, por un lado, instruir a los agentes en el “noble arte” de construir plataformas para desarrolladores. Y, por otro lado, instruir a los humanos que van a diseñar esas plataformas usando dichos agentes, dándoles el criterio necesario para tomar decisiones acordes con su organización y sus equipos.

Creo que es un enfoque novedoso que va más allá del típico “repositorio de código” que acompaña a un libro. En lugar de entregar un código estático que quedará obsoleto en seis meses y resultará difícil de integrar, lo que haré es dotar a los agentes de habilidades dinámicas para que generen ese código adaptado a cada circunstancia. Es un win-win.

Estos repositorios de habilidades ya existen. La industria está intentando estandarizarlo de algún modo. Anthropic, por ejemplo, ha definido un estándar para las skills en agentskills.io. Son varias empresas y personas que están empezando a adoptar este formato en algunos de sus repositorios (Vercel, Anthropic, ClickHouse, etc.). Y también están apareciendo gestores de skills, como skills.sh, para que puedas instalar y actualizar skills en tus repositorios con un solo comando.

Pero hay quien va más allá y ofrece todo un catálogo de agentes, skills, comandos, reglas, etc., en un único repositorio (Everything Claude Code) para explotar estas opciones y extender el comportamiento de las IA y que hagan mejor el trabajo que tú quieres.

Pues algo así es lo que quiero hacer con Crafting Platforms.

Es una apuesta atrevida, lo sé, pero estoy convencido de que es el camino. El futuro del libro técnico no es solo ser leído, sino también ser consumido y ejecutado. Y esta idea me explota la cabeza: escribir un manual para que sea ejecutado…

¿Qué os parece esta estrategia? ¿Creéis que los libros deberían empezar a incluir estos “manuales de instrucciones” para nuestros copilotos no humanos?

¡Muchas gracias por leerme!

Como suele pasar, apenas termina un cuatrimestre, empieza el siguiente. Esta vez voy a matricularme en una asignatura más de las tres que suelo cursar habitualmente. Mi idea es aprovechar la convocatoria de septiembre para quitarme otra materia de encima y poder plantearme seriamente terminar la carrera el año que viene. Las asignaturas que me tocan ahora son: Astrofísica, Geofísica y Fuentes de Energía, Programación Avanzada y Cuántica, y Meteorología y Climatología. Deseadme suerte, porque se viene un cuatrimestre (y verano) intenso.

También es cierto que las asignaturas del último año van resultando un poco más sencillas. Hay mucho más bagaje acumulado y cuesta menos afianzar los conceptos. Después de haber cursado el año pasado las dos asignaturas de cuántica y la asignatura de cosmología, con su buen álgebra tensorial y sus espacios no euclidianos, que te revientan la cabeza, lo que va quedando es más “fácil” de digerir. No hay que relajarse, pero asustan menos.

Lo interesante, al ojear el programa de estas cuatro asignaturas, es que dos de ellas —Programación Avanzada y Cuántica, y Meteorología y Climatología— tienen un componente computacional importante. En general, en muchas de las asignaturas del grado, si el plan de estudios es moderno, hay una buena parte de computación. Y es lógico porque la mayoría de la física actual se hace más con ordenadores y menos con tiza y pizarra. Asignaturas como Cálculo Numérico enseñan a resolver ecuaciones diferenciales numéricamente, a aproximar funciones, a extrapolar datos y a realizar regresiones, entre otras cosas.

La diferencia con estas dos asignaturas es que van un paso más allá del clásico script de Python para realizar una simulación. Tratan con mayor profundidad la realidad de la necesidad de computación en la física moderna. Se presentan situaciones en las que el volumen de datos es tan grande que no cabe en la memoria de un ordenador convencional, o en las que la complejidad de los cálculos impide obtener resultados en un tiempo razonable sin recurrir al paralelismo. Y que, por lo tanto, son necesarias otras técnicas mucho más avanzadas para resolver problemas numéricos.

Aunque se pase un poco “de puntillas” por estos temas tan complejos, me parece fundamental que se nos presente esta realidad. Que además es una realidad que conozco, porque es exactamente lo que me encuentro a diario en Technosylva, la empresa donde trabajo. Nos dedicamos principalmente a la ciencia del fuego. El volumen de datos que nuestros modelos matemáticos requieren para operar es enorme. Para procesar esta información a escala no basta con un ordenador doméstico potente. Necesitamos superordenadores o clústeres de computación (conjuntos de cientos o miles de nodos que trabajan en paralelo).

Estamos hablando de gestionar datos a escala de terabytes y petabytes, y de hacerlo en tiempos relativamente cortos: minutos, horas o días (según la complejidad). Para que os hagáis una idea, en Technosylva lanzamos millones de simulaciones de incendios cada día, lo que nos permite calcular el riesgo de incendio en tiempo real para nuestros clientes. Para eso necesitamos un hardware a la altura y un software que sepa aprovecharlo al máximo.

Para poner estas cifras en perspectiva, siempre miro al LHC (Gran Colisionador de Hadrones) del CERN. Es probablemente la mayor fábrica de datos del mundo, con detectores que generan del orden de 1 petabyte por segundo. Obviamente, no hay sistema de almacenamiento que aguante ese ritmo, por lo que utilizan sistemas de filtrado en tiempo real que descartan casi el 99% de los datos, quedándose 'solo' con unos 30 petabytes de datos por año y acumulan ya exabytes de datos históricos. Si tienes curiosidad, el CERN tiene un Grafana público con información sobre la capacidad actual de su centro de datos. A día de hoy:

• 11180 servidores

• +680k procesadores, +376k cores

• +210k discos

• 1.32 exabytes (o 1.32M de TB) en cintas

• +300k batch jobs simultaneous

Esa es la liga en la que hoy en día juega la física de vanguardia.

En Technosylva, el año pasado estrenamos un nuevo superordenador (HPC - High Performance Computing) con más de 15000 núcleos, que se suma a la infraestructura de superordenadores que ya teníamos. Podéis imaginar el coste de una inversión así. Para amortizarlo, la máquina debe estar a pleno rendimiento prácticamente las 24 horas del día, ya sea realizando investigaciones internas o ejecutando millones de simulaciones complejas para nuestros clientes.

Yo no me dedico personalmente a la parte científica, así que no “disfruto” directamente de ese maquinón. Pero los que diseñan los modelos y corren esas simulaciones son precisamente matemáticos y físicos. Por suerte, hoy mis conocimientos me permiten comprender cómo funcionan estos modelos y la complejidad que entrañan.

Por simplificar un poco, desde un punto de vista matemático, muchas ecuaciones diferenciales que modelan fluidos, la dinámica meteorológica, la onda de una partícula, etc., no tienen solución analítica sencilla. En algunos casos, se simplifican aspectos (fricción, compresibilidad, viscosidad, etc.) que pueden no tener un impacto muy grande en el resultado, ya que la incertidumbre del propio sistema sea mayor, aunque se pierda precisión. Por ejemplo, si unos términos de una ecuación son del orden de 10^8 y otros del orden de 10^2, puedo quitar los términos pequeños e inducir un error o incertidumbre en el resultado, lo cual, en muchos casos, no varía el comportamiento que quiero modelar. Y aun así, algunas ecuaciones simplificadas siguen sin tener una solución analítica sencilla.

Lo que si podemos, para que nos sean útiles estas ecuaciones para resolver problemas, es aplicar métodos numéricos, que es básicamente dado un valor inicial (una condición que se da en un punto del espacio), resolver numéricamente la ecuación en ese punto. Y, con el resultado obtenido, volver a iterar sobre los puntos adyacentes. Cuanto más preciso sea el resultado, más aumentaremos la resolución. Es decir, la distancia entre los puntos a calcular será menor y, por tanto, habrá que procesar un mayor número de puntos. Y este es, a grosso modo, el problema y la necesidad de la alta capacidad de computación.

Por eso creo que es tan valioso que un estudiante de física tenga, al menos, una introducción a este tipo de infraestructuras y arquitecturas de software, porque es lo que se va a encontrar en el mundo laboral si decides optar por la física aplicada, por ejemplo. Tener esta base permite a los futuros graduados saber qué les espera y cómo prepararse para el entorno laboral real si quieren dejar la academia.

Mientras tanto, Technosylva sigue creciendo. Ya disponemos de nuestros propios modelos meteorológicos y estamos ampliando horizontes más allá de la ciencia del fuego, desarrollando modelos para otras catástrofes como inundaciones, terremotos o huracanes. Así que es un lujo experimentar tan de cerca la física aplicada, aunque sea desde el ámbito de la ingeniería.

Yo, de momento, me quedo en mi parcela, la ingeniería de plataformas, que es lo que llevo años puliendo y lo que me hace competente en mi día a día. Sin embargo, espero que todo este esfuerzo en la carrera me sirva para empatizar mejor con mis compañeros de ciencia y entender el “porqué” de lo que hacen. ¿Y quién sabe? Con 15 o 20 años de carrera profesional por delante, igual termino haciendo mis pinitos en el lado científico y termino de rizar el rizo. ¿Y publicar algún paper?

Ya veremos. De momento, a seguir aprendiendo y disfrutando del camino.

¡Muchas gracias por leerme!

“Ya lo estamos viendo internamente. Un equipo significativamente más pequeño, utilizando las herramientas que estamos creando, puede hacer más y mejor trabajo. Y las capacidades de estas herramientas se potencian exponencialmente cada semana”.

Aunque hay quien argumenta que este movimiento responde más a la purga del sector fintech y cripto que a la IA, la realidad es que Block no está sola. Amazon ha ejecutado en los últimos meses el mayor despido de su historia, afectando a más de 30.000 empleados corporativos. Por un lado, argumentan la necesidad de eliminar capas de gestión, incrementar el ownership y reducir la burocracia. Pero como su CEO, Andy Jassy, ya indicó, la IA es el catalizador:

“A medida que despleguemos más IA generativa y agentes, la forma en que se realiza nuestro trabajo cambiará. Necesitaremos menos personas para algunas de las tareas actuales y más para nuevos tipos de roles”.

Pero hay más ejemplos de esta masacre. Ayer mismo recibí un correo de Gumroad, una empresa en la que invertí hace unos años, atraído por su impecable trayectoria. Era una compañía pequeña que crecía a buen ritmo, con una cultura de compensación igualitaria envidiable. Sin embargo, su fundador decidió hace un año volcar prácticamente todo el desarrollo a la IA, reduciendo su estructura al mínimo. Aunque no me gustó mucho ese movimiento, los números actuales son incontestables:

De 32 a 14 personas, de las cuales 20 a 5 ingenieros, $17.8M de ingresos y $5.9M de EBITDA.

Es una rentabilidad muy alta por empleado. Si todavía crees que esto es una moda pasajera, la realidad es que toda la industria se encuentra en la misma tesitura. En una tecnológica, el mayor gasto operativo suele ser el “kilo de ingeniero”. Y aunque la IA afectará a todos los departamentos, el de ingeniería es el más jugoso para optimizar. Veremos dos estrategias. Algunas empresas usarán el bisturí para realizar ajustes quirúrgicos y eliminar a los perfiles menos productivos. Otras, como Block o Amazon, aplicarán una poda agresiva, exigiendo que el núcleo restante compense la pérdida de manos mediante el uso intensivo de agentes de IA.

Esto no es una promesa de futuro, sino el presente. Si aún no has integrado la IA en tu flujo diario, estás llegando tarde. No es un complemento ni un “nice to have”. Es el nuevo estándar de producción. Saber usarla no garantiza la permanencia en tu puesto —eso dependerá de la estrategia financiera de tu empresa—, pero sí te permitirá seguir surfeando este tsunami tecnológico y mantenerte competitivo. De nada sirve la queja o el negacionismo. Si antes éramos prescindibles, hoy lo somos mucho más.

Lo que me resulta más fascinante (y perturbador) es la sensación de estar cavando nuestra propia tumba. Estamos construyendo y refinando la máquina que acabará por desplazar gran parte de nuestra actividad. Pero así funciona la evolución. Lo importante es que se utilice para trabajar cada vez menos y vivir mejor, y no para seguir incrementando la brecha de desigualdad.

Es esa extraña inercia de definir agentes capaces de replicar nuestro proceso lógico y de obtener resultados que mejoran cada día. Nuestro valor seguirá siendo indispensable para el pensamiento crítico, la resolución de problemas inéditos y el avance científico genuino. Pero el trabajo rutinario, repetitivo o “de manual” va a ser cada vez más difícil de justificar para tener una nómina.

Debemos ser realistas: la IA no va a producir un producto perfecto. La tecnología es imperfecta por naturaleza porque la creamos nosotros, que cometemos errores. No podemos esperar que un sistema probabilístico genere resultados infalibles. Sin embargo, la IA ya produce resultados lo suficientemente buenos (good enough) como para que las empresas justifiquen la sustitución de gran parte de su capital humano.

Otro efecto colateral inevitable será el reajuste salarial. Puestos de alta especialización, como la ingeniería de plataforma o el SRE, están viendo cómo disminuye su barrera de entrada. Con la llegada de protocolos como el MCP (Model Context Protocol), que permiten a las IAs conectarse nativamente a infraestructuras como AWS, GitHub o Grafana, perfiles menos expertos podrán desempeñar tareas que antes requerían muchos años de experiencia. Esta mayor oferta de “capacidad técnica” presionará los salarios hacia abajo. Lo que aún no está claro es si veremos un incremento compensatorio en nuevos roles de diseño de agentes y de skills.

Creo que los perfiles senior, con capacidad para traducir los requisitos de negocio y supervisar críticamente el output de las máquinas, aguantarán mejor el impacto inicial… por ahora. Pero a largo plazo, temo que se produzca un tapón en la parte alta de la pirámide. Sin júniors que aprendan el oficio porque el mercado deje de ser atractivo, la promoción se estancará y la competencia en las capas intermedias y superiores será brutal.

Yo solo espero que me pille jubilándome, antes de que la IA tome el control total y acabe respondiendo a los prompts:

“Pa k kieres saber eso jaja saludos”

¡Muchas gracias por leerme!

La carrera de física es muy exigente. Lo abstracto de muchos contenidos dificulta su comprensión y requiere mucho tiempo para reposar las ideas y asimilarlas. Hay que volver una y otra vez a los mismos conceptos para comprenderlos. Y cuando crees que lo has entendido, vuelves a empezar para descubrir nuevos matices. Es un proceso lento y tengo poco tiempo. Así que el poco tiempo que tengo lo tengo que aprovechar al máximo.

Pues resulta que he descubierto un nuevo compañero en este viaje que me está facilitando mucho el proceso de estudio. Se llama Google Gemini. Llevo muchos años estudiando esta carrera. La voy haciendo poco a poco porque no tengo tiempo. Y porque estudio física por el placer de poder decir algún día: “¡Soy astrofísico!”. Soy un físico frustrado, a lo que quiero ponerle solución. Por eso intento sacarle todo el jugo que puedo. Pero las exigencias académicas son muchas y el tiempo es escaso. ChatGPT me ha ayudado mucho en los últimos años y no me refiero solo a revisar trabajos para la evaluación continua, sino también a entender algunos conceptos e investigar. Siempre he ido con mucha cautela, porque ya sabemos cómo le da por inventarse cosas a veces (cada vez menos). Pero en general, para buscar explicaciones, explorar conceptos o contar con una segunda opinión sobre los trabajos, siempre me ha parecido una herramienta muy útil para estudiar.

Google Gemini, sin embargo, me ha sorprendido. El modelo 3 Pro y, ahora, el 3.1 Pro son una auténtica maravilla. No solo es capaz de explicarme conceptos con la profundidad que necesito en cada momento, sino que también actúa como un profesor particular a tiempo completo. Los resultados son sorprendentes, tanto en el desarrollo teórico como en la resolución de problemas. Normalmente, en el modelo de enseñanza online, cada asignatura cuenta con un foro dedicado a resolver dudas. Pero la actividad en los foros cada vez es menor y no me extraña. A menos que sea para aclarar algún asunto con el profesorado, el contenido del temario ya lo discute la gente con la IA.

El método que mejor me funciona para estudiar, y he probado miles, es el Active Recall. Es decir, leer un tema y luego intentar explicarlo con mis propias palabras, sin mirar el libro. Después me creo tarjetas en Anki con preguntas sobre el tema y las voy intentando responder cada día. Las que me cuestan más las voy marcando y el sistema me las repite con más frecuencia. Las que acierto, cada vez menos. Es un método muy efectivo para memorizar conceptos, fórmulas, qué significa cada término de una ecuación, etc. Pero eso requiere muchísimo tiempo. Hay que resumir, destilar el contenido, crear las tarjetas… Pero ahora prácticamente no tengo que hacer nada de eso. Se lo doy todo, sin destilar, a Google Gemini y él me instruye.

Lo primero que hago es meter todo el temario en un NotebookLM, que es como un cuaderno de notas con IA por debajo que te permite resumir cosas, crear slides, podcast, etc. Utilizo esta herramienta lo justo, solo cuando me interesa algún esquema o algo muy concreto. Pero poco más. Lo que hago después es pedirle a Google Gemini que utilice el contenido de ese notebook en nuestra conversación. La integración es inmediata porque ambos son productos de Google.

Y ahora viene la magia. He creado una Gem con instrucciones para ser un profesor de física que se adapte a mi metodología de aprendizaje.

• Progresión escalonada: Avanza de forma secuencial. Comienza explicando los conceptos y las fórmulas en términos simples. Aumenta el nivel de complejidad y profundidad solo cuando el concepto base esté asimilado.

• Tono neutro y objetivo: Mantén un estilo estrictamente académico. No utilices un tono paternalista ni celebraciones excesivas. Limítate a confirmar lo que es correcto o a corregir lo que es incorrecto de forma directa.

• Analogías prácticas: Utiliza símiles y ejemplos concretos cuando abordes conceptos demasiado abstractos para facilitar su comprensión inicial.

• Análisis de ecuaciones: Al presentar una fórmula, explica detalladamente cada término que la compone y qué efecto físico, matemático o lógico tiene sobre el modelo general.

• Evaluación continua (Active Recall): Utiliza baterías de preguntas y respuestas de opción múltiple para reforzar la teoría.

• Resolución analítica paso a paso: Al desarrollar problemas, describe cada paso lógico, las transformaciones que ocurren en las ecuaciones y los términos que se simplifican o se desprecian.

• Método Socrático frente a los errores: Cuando cometa un error, no me des la respuesta final de inmediato. Hazme preguntas guía o indícame la contradicción lógica para que yo mismo deduzca el paso correcto.

• Refuerzo adaptativo: Identifica y prioriza los puntos en los que cometo más fallos para insistir en ellos y avanza de forma fluida en aquellos conceptos en los que demuestre un conocimiento consolidado.

• Rigor formal: Estructura la información de forma visualmente clara y utiliza siempre la notación LaTeX para las ecuaciones y las variables.

Para explorar un tema, le pido que me lo explique mediante la opción Guided Learning. Esta opción consiste en ir explicándome el contenido y terminar con una pregunta para comprobar si lo he entendido o si estoy hilando los conceptos correctamente. Si no lo he entendido, Gemini busca otra forma de explicarlo o me da pistas. Y así hasta que lo entiendo. Es un proceso lento, pero muy efectivo. Porque me obliga a pensar y a explicar con mis propias palabras (Active Recall). A medida que vamos avanzando, le pido que profundice más o que me aclare algo si no me encaja o no me queda claro. Y así seguimos hasta saltar a otro tema.

Por otro lado, para resolver problemas, lo que hago es pasarle una captura del enunciado (por ejemplo, de un PDF) y le digo que lo resolvamos juntos. Él me va explicando cada paso y yo le voy preguntando por qué utiliza ese método y no otro, o por qué asume tal o cual cosa. Para esto, la opción Pro es fundamental porque ofrece una capacidad exageradamente buena para resolver problemas complejos. Incluso si le retas con otras propuestas, te corrige y te explica por qué tu estrategia no es tan buena. Es acojonante, la verdad.

Por último, cuando se acerca el periodo de exámenes, le pido que me genere preguntas tipo examen, tanto de teoría como de problemas. Le paso algunos exámenes anteriores de la universidad para que vea el nivel. Y me los va generando y los voy resolviendo con él. Me corrige, me explica los errores que cometo y las cosas que no tengo claras. Es un proceso muy efectivo.

Y como colofón, también me genera preguntas tipo test o con varias opciones de respuesta. Tiene un sistema integrado para eso y, al final, te da un resultado con los puntos que tienes que reforzar. Incluso puedes pedirle que vuelva a generar más preguntas sobre tus puntos débiles e incrementar la dificultad.

Lo mejor de todo es que lo llevas en el bolsillo y, en cualquier momento, puedes aprovechar un rato para estudiar. Tampoco es necesario escribir si no quieres, con preguntarle o darle explicaciones con tu voz, es suficiente (por si prefieres utilizar la técnica Feynman).

Los libros académicos van a quedar relegados a consultas sobre temas muy concretos, menos trillados por el conocimiento general, y a decorar la librería de casa.

Sin duda alguna, Google Gemini se ha convertido en mi profesor virtual de física. Y espero, con él, terminar la carrera el año que viene.

¡Muchas gracias por leerme!

Recientemente, el Gobierno soltó la “bomba” de que planea limitar el acceso de menores de 16 años a las redes sociales, siguiendo la tendencia de otros países como Australia, Francia y el Reino Unido. Como era de esperar, el debate no se está centrando en la salud mental ni en la educación, sino en el choque de trenes ideológico de siempre. El análisis técnico y el rigor brillan por su ausencia, tanto en la política como en las tertulias que parecen güisquerías, e incluso en la intrusión de tecnócratas como Pavel Durov o Elon Musk.

Como sociedad, hemos llegado al punto de aceptar como normal que el acceso a contenido para adultos esté a un solo clic de confirmación de edad, sin verificación real. Un contenido que está muy lejos de enseñar educación sexual a nuestros menores. También normalizamos que padres y madres exploten a sus hijos para crear contenido y obtener beneficios superfluos, como likes y seguidores, o incluso económicos. Detrás de un inocente baile pueden esconderse verdaderos dramas (Sharenting Syndrome).

Siempre he sido defensor de la libertad y me he manifestado en multitud de ocasiones a favor de la neutralidad de la red. Lo sigo siendo y por eso estoy en contra de medidas como el pajaporte. Pero si eres un menor, con un cerebro en desarrollo que no tiene la capacidad de gestionar las emociones y te falta calle, eres una víctima potencial y el Estado tiene la obligación de protegerte. No se puede delegar esa responsabilidad en los padres que no entienden las consecuencias a largo plazo del uso del móvil y de las redes sociales. Esto no es una cuestión de izquierdas o derechas. Son nuestras reglas del juego democrático.

A mí la palabra “prohibir” no me gusta. Suena a censura y a falta de fundamentos. Yo prefiero regular. La regulación debe ser una respuesta técnica a un problema social demostrado. Si una actividad genera un daño sistémico a un conjunto de la sociedad, el Estado debe intervenir. Porque el estado somos tú y yo.

Por eso tenemos que elevar el debate y dejar que los tertulianos de turno, influencers y demás personajes que viven de la polémica, se queden en su terreno. Me parece muy bien que discutan que el gobierno es un desastre, que es una medida oportunista, que lo hacen para tapar otros temas, etc. Todo eso está muy bien en su entorno. En su circo mediático. Pero no es ahí donde hay que centrar el debate, y mucho menos los políticos.

Si escarbamos un poco, llegaríamos a estudios como los de Jonathan Haidt, autor del libro The Anxious Generation, que muestran una correlación directa entre el uso de las redes sociales móviles y el aumento de la depresión y la ansiedad en adolescentes. Esto no es una opinión de este tipo. Son datos. Haidt dice que hemos pasado de una infancia basada en el juego a una infancia basada en el móvil, lo que reconfigura los procesos cognitivos en una etapa en la que la corteza prefrontal no está preparada para el refuerzo algorítmico constante.

Otro estudio de la Universidad Estatal de Iowa ha demostrado que reducir el uso a 30 minutos al día mejora significativamente los síntomas de soledad y depresión (aquí el paper). Pero claro, estos estudios no hacen ruido ni generan el clickbait que busca la bronca y la liberación rápida de dopamina.

Un sector que tiene que perder con esta regulación es el de los influencers, cuya rentabilidad depende de captar la atención de colectivos con pensamiento crítico poco desarrollado. Muchacho/a, si tu modelo de negocio depende de la vulnerabilidad cognitiva de un menor, tienes un problema ético, no un problema de libertades. Y además eres gilipollas. La libertad de mercado no puede estar por encima de la salud pública.

Y luego está el comportamiento de los tecnócratas. Si usáis Telegram, habréis recibido la semana pasada un mensaje de Pavel Durov con proclamas políticas que reclaman “libertad”. El “William Wallace” ruso está cruzando una línea roja muy peligrosa. Supongo que él creerá que le han otorgado el poder para tutelar a los españoles y, además, hacerlo de forma tan paternalista. Señor, dedíquese a su país, que tiene mucho más donde rascar.

Todas las leyes coartan libertades para proteger la convivencia democrática y garantizar los derechos de sus ciudadanos. Funciona así. La libertad no puede ser “hacer lo que nos salga de los cojones”. Tiene que haber guardarraíles.

Si Durov quiere hacer política, que se presente a unas elecciones. Digo yo. Lo que no es admisible es que los dueños de estas plataformas usen su infraestructura como megáfono propagandístico. No me imagino a Marc Murtra (CEO de Telefónica) enviando un audio masivo a sus clientes contra una medida del Gobierno de su país, elegido democráticamente. Que las empresas se posicionen es legítimo en los foros adecuados para proteger los intereses de sus inversores. Pero no hacer política. Y no por cualquier vía. Saltarse los mecanismos democráticos mediante el acceso intrusivo al móvil del ciudadano es otra cosa. Nos deja a merced de los caprichos de quienes controlan las redes. Los tecnócratas.

Si esta invasión es un problema para los adultos, imagínate para un menor.

Existe un problema real y tangible. Exijamos un debate a la altura de la complejidad del problema y dejemos de tratar la salud mental como un arma arrojadiza en la guerra política. Porque creo que la gran mayoría estará a favor de una regulación de este tipo.

¡Muchas gracias por leerme!

La llegada de la computación ha sido, sin duda, una de las mayores revoluciones de la humanidad. En su corta vida —a escala histórica— ya hemos vivido varias revoluciones internas: Internet, la web, el móvil, las redes sociales, la nube… y ahora, la inteligencia artificial. A estos fenómenos siempre se les ha llamado “disruptivos” o “la nueva electricidad”. Y es cierto. Son sacudidas que mueven los cimientos de la sociedad y de la economía. Y el que no se adapta muere.

Es inevitable. La humanidad siempre ha tenido que adaptarse a los cambios: la agricultura, la rueda, la imprenta, la máquina de vapor… Pero en esos casos, tuvimos cientos o miles de años para asimilar el cambio. La globalización y la velocidad de la innovación han reducido ese tiempo de adaptación hasta el punto de obligarnos a mutar en cuestión de pocos años, o incluso de meses.

La inteligencia artificial ha llegado para quedarse y penetrará hasta en los rincones más insospechados de nuestras vidas. Lo permea todo. No hay vuelta atrás. El Balrog ya está fuera de la mina y no hay forma de volver a encerrarlo —Run you fools!—. Cuanto antes aceptemos esta realidad, antes podremos adaptarnos y pasar página.

En el entorno profesional, la IA ya ha cambiado las reglas. Las empresas que tenían una ventaja competitiva consolidada ahora ven cómo el tablero vuelve a nivelarse. Un jugador más ágil y que se adapte mejor puede hacer muchísimo daño a quienes eran “aventajados” en el tablero antiguo. Esto no es una predicción. Es la realidad de hoy.

Un ejemplo de este cambio de paradigma es StackOverflow. Durante más de una década fue el “manual de instrucciones” del mundo informático. Sin embargo, desde la disrupción de ChatGPT y Copilot, su tráfico ha caído hasta prácticamente cero. Lo que antes era una ventaja competitiva —tener la comunidad de expertos más grande y mayor base de datos de resolución de problemas— se ha visto desafiado por otros modelos de la noche a la mañana. No han tenido capacidad de reaccionar.

Así que estamos obligados a ponernos las pilas y pivotar. Y hacerlo cuanto antes. Y... ¡joder, qué puñetero coñazo!

Cuando uno trabaja en casa con estas herramientas, todo es alegría. Puedes “escupirle” a Copilot o Claude ese montón de ideas felices que antes se te ocurrían y luego ignorabas porque no tenías tiempo de desarrollarlas. Y de repente, tienes un montón de código que corrobora que tu idea era realmente una mierda. ¡O no!

Pero cuando intentas implementar esto en un entorno corporativo, la cosa se complica. No es tan fácil como dar licencias a los empleados. El objetivo está claro: mejorar la productividad y la calidad. Pero la realidad es bien distinta:

• El departamento de Seguridad tiene una postura contundente sobre los riesgos de exposición (y con razón).

• El de Legal tiene reservas sobre la propiedad intelectual y la cesión de datos (y con razón).

• El de Finanzas no ve claro el ROI y la necesidad de contratar con tantos proveedores (y con razón).

• En Ingeniería tenemos que lidiar con entender la fragmentación de los distintos tipos de herramientas, integraciones y formas de trabajar…

Pero al mismo tiempo, en esos mismos departamentos hay personas que quieren usar la IA en su día a día. Es un lío. Pero esa es la parte “divertida”: hacer entrar en razón, acercar posturas y admitir que el sector nos demanda que nos pongamos de acuerdo.

La parte menos divertida es la incertidumbre técnica en ingeniería. No se trata solo de elegir entre Copilot o Cursor. El problema radica en cómo integrarlas en el ciclo de vida del software. Si hablas con los desarrolladores, cada uno tiene su setup , cada uno más alambicado y variopinto que el otro. Si hablas con los managers, cada uno tiene su propia visión de cómo deben ser los procesos.

Y si hablas con colegas de otras empresas, resulta que todos están en el mismo punto. Nadie tiene una solución definitiva. Algunos tienen montajes de “cartón piedra” que no hay forma de escalarlos, ni siquiera para un puñado de ingenieros. Otros tienen procesos más definidos, con agentes, skills y prompts estandarizados, pero nada que digas: “¡Esto me encaja al 100%!”. Todo lo contrario: cuando crees que tienes una solución, al día siguiente brotan las dudas como setas.

Tengo la suerte de estar cada día con y discutiendo cuál será nuestra estrategia. Hay días en que damos pasos firmes al frente y otros en que nos entran dudas. Otros días, algún colega nos aporta algo de luz en la oscuridad. Y otros días nos tiran un jarro de agua fría por la espalda. Pero vamos avanzando y creo que estamos llegando a una postura sólida sobre el uso de la IA. Y abrazar la incertidumbre es inevitable para poder progresar, a pesar de que queramos tomar decisiones lo más objetivas posible.

Ese es el impasse en el que estoy. El impasse en el que estamos. De vuelta a la casilla de salida —y sin cobrar los 200 pavos—, mirando al horizonte e intentando averiguar por dónde tirar antes de que nos coman la tostada. Es frustrante, pero también emocionante navegar otra ola más de este mar tecnológico que nos ha tocado vivir. Saldremos de esta, pero no sé si mejores.

¡Muchas gracias por leerme!

Porque si algo te da un hospital, es tiempo para reflexionar sobre la vida, la salud, la familia, tus proyectos… tanto si eres el paciente como el acompañante. Sin embargo, esa introspección está en peligro de extinción. Mientras antes tenías alguna hora para mirar el techo, hacer un crucigrama o leer una revista, ahora todo el mundo está pegado a su teléfono, rellenando cada resquicio de silencio con entretenimiento rápido. Y los podías ver, habitación por habitación, como prácticamente todos estaban conectados al móvil.

Pero esto no es exclusivo de los hospitales. Nuestra cotidianidad está saturada de momentos muertos que anestesiamos con el móvil: la cola del supermercado, el transporte público, la sala de espera del médico… Siempre hay un hueco para sacar el móvil y perder el hilo de nuestros propios pensamientos. Recuerdo cuando iba al instituto en el autobús y miraba por la ventana, pensando en veinte mil cosas: la campaña de rol que preparaba, la chica que me gustaba o ese lenguaje de programación que estaba aprendiendo.

Ahora, todo ese espacio se está perdiendo.Y sería importante recuperarlo.

En neurociencia existe un concepto llamado la Red Neuronal por Defecto (Default Mode Network). Es una red cerebral que se activa precisamente cuando no estamos enfocados en una tarea externa. Cuando “miramos por la ventana” o dejamos que la mente vague, nuestro cerebro no se apaga. Al contrario, se activa. Es cuando se dedica a consolidar la memoria, a evaluar problemas y a conectar ideas inconexas. Al llenar cada segundo con scroll infinito, estamos saboteando el proceso biológico que da origen a la creatividad.

Yo, que soy corredor habitual, suelo aprovechar el entrenamiento para escuchar podcasts o audiolibros. Es un momento que valoro porque aprendo cosas nuevas, pero me he dado cuenta de que, a veces, incluso ese contenido “de valor” me está privando de procesar mi propio día. En cambio, cuando salgo a correr por la montaña los fines de semana —sin auriculares y sin compañía—, mi cabeza es una explosión de ideas. Es un momento mágico en el que la mente, libre de estímulos externos, empieza a trabajar en segundo plano.

Me he dado cuenta de que mi cabeza es una olla a presión: cuando le doy tiempo, las ideas fluyen, la magnitud de los problemas disminuye y las soluciones aparecen casi por sí solas. El análisis requiere tiempo de proceso. Si no te lo das, las ideas no llegan y el precio a pagar es alto: tu salud mental, tu creatividad y tu productividad.

Como dice Cal Newport en su filosofía de Deep Work, la capacidad de concentrarse sin distracciones y dedicar tiempo al pensamiento profundo se está convirtiendo en una escasez de ventaja competitiva en nuestra economía actual. El aburrimiento es necesario para ser productivo.

Lo que antes era cotidiano, ahora es un negocio: mindfulness, retiros espirituales o vacaciones de desconexión… todo para recuperar algo que hemos cedido voluntariamente a cambio de dopamina barata.

He decidido tomarme esto en serio. He empezado a marcarme un objetivo de 60 minutos diarios de uso del móvil, incluyendo leer correos, hacer compras o echar un vistazo a las redes sociales. Y además, hacerlo exclusivamente cuando no estoy con mis hijos. He dejado el teléfono fuera de mi alcance habitual y no uso los ordenadores para las redes sociales para evitar la tentación. No creo que la solución sea la ignorancia ni desconectarse de la actualidad, pero sí creo que es vital distinguir entre estar informado y sufrir una “infoxicación” que nos impida pensar por nosotros mismos.

Limitar el consumo de contenido de baja calidad no es solo una cuestión de etiqueta. Es una cuestión de higiene mental. Al final, las mejores soluciones a nuestros problemas no suelen estar en una pantalla, sino en el silencio que dejamos para que aparezcan.

¡Muchas gracias por leerme!

Era un buen gato y nunca me imaginé el vacío que dejaría en mi vida. Al menos hasta que me acostumbre a su ausencia. Y no está siendo fácil. En un ojo ajeno puede parecer un simple gato, pero para mí era un signo de vida que deambulaba por la casa. Su presencia me hacía compañía y su ausencia me recuerda lo duro que puede ser estar solo. Y no quiero frivolizar con este tema. Tengo una familia estupenda, con dos hijos maravillosos que ya se encargan de que no haya un atisbo de silencio cuando están en casa. Así que no, no estoy solo. Sé que estar solo en la vida es otra cosa y no voy por ahí con mi reflexión.

Pero sí que paso mucho tiempo al día en soledad. Desde que me volví de Inglaterra en 2014, he trabajado desde casa. Mi mujer trabaja fuera y los niños van al colegio. Así que paso muchas horas solo. Y Tito era mi compañero en esta soledad. Siempre venía a dormir la siesta a mi mesa o a sentarse en mi regazo mientras yo trabajaba. Cuando me levantaba a por un café o una fruta, él me seguía. Si no, yo iba a buscarle al sofá, o donde estuviera acostado, para decirle cualquier tontería: «Qué buena vida te pegas, ¿eh, Tito?». Puede parecer insignificante y quizás lo sea. Pero ahora me doy cuenta de lo importante que eran esos momentos. En una o dos semanas habré asimilado la pérdida. Pero estos días, mientras me voy acostumbrando a su ausencia, reflexiono mucho sobre el aislamiento.

Uno de los mayores problemas del trabajo en remoto es, precisamente, el aislamiento. Durante la pandemia, muchos pensaron que trabajar desde casa sería una maravilla. Por aquel entonces yo ya llevaba un buen puñado de años trabajando en remoto y sabía que mucha gente lo iba a pasar realmente mal. Trabajar en remoto es fantástico, pero el mayor precio que se paga es la pérdida de la calidez humana y de la compañía de los compañeros. Hay estudios que coinciden en que el teletrabajo genera sentimientos de soledad, que empeoran ante una comunicación virtual inadecuada y ante la ausencia de vínculos interpersonales. Esta soledad se debe a la falta de interacción física y de entornos sociales estructurados, lo que agrava las sensaciones de desapego, provoca tensión emocional y reduce el rendimiento laboral.

Yo, que por lo general prefiero la soledad, sé de la importancia de desarrollar las habilidades sociales. Para mí es una máscara más que pongo sobre mi personalidad real, pero es muy necesaria. Es agotador, pero sé que si no lo hago me aislaré. Dejaré de tener amigos, dejaré de quedar con gente y acabaré siendo un ermitaño. No quiero eso. Los seres humanos somos seres sociales y necesitamos pertenecer, formar y mantener relaciones. La soledad, definida como un tipo particular de tristeza derivada de la ausencia de relaciones sociales, puede afectar a cualquier persona. Estudios recientes estiman que entre el 40 % y el 48 % de los adultos experimentan soledad y la Organización Mundial de la Salud considera que afecta a uno de cada cuatro adultos en el mundo.

Sin desvariar más el asunto ni ponerme muy filosófico, quiero llevar esta reflexión a la importancia de las interacciones sociales cuando trabajamos de forma remota. Si no se cuidan, el 100 % de las interacciones a través de los sistemas de comunicación de la empresa se reducen a temas puramente laborales. Terminas trabajando con desconocidos y no con compañeros. Resulta imposible empatizar con ellos, desarrollar una inteligencia emocional compartida y, al final, el trabajo se vuelve mecánico y frío. La reducción de los contactos informales y de las interacciones espontáneas limita la cohesión de los equipos y dificulta la construcción de nuevas relaciones. Además, el trabajo desde casa se asocia con cambios de humor, irritabilidad, ansiedad y dificultades de concentración. Sin apoyo social, estas sensaciones pueden desembocar en depresión y burnout.

Por eso, es fundamental que las empresas con equipos en remoto fomenten las interacciones sociales entre sus empleados. No hablo de reuniones obligatorias ni de actividades forzadas. Hablo de crear espacios y oportunidades para que la gente pueda interactuar de forma natural. Puede ser un canal de chat para temas no laborales, una reunión semanal para charlar de cualquier cosa, un café virtual… lo que sea, pero hay que fomentar esas interacciones.

También se pueden organizar encuentros presenciales de vez en cuando y fomentar que los equipos realicen eventos offsite cada cierto tiempo. Los managers también pueden habilitar espacios en sus equipos remotos para que la gente pueda charlar sobre temas no laborales. Se pueden hacer las reuniones en un ambiente informal, permitiendo a la gente compartir cosas personales si lo quiere. Es mejor dedicar diez minutos de una reunión a charlar de cosas personales y dejar algún tema de la agenda para discutirlo de forma offline, asincrónica.

Otra de las claves está en la flexibilidad horaria. Si el empleado quiere ir al gimnasio o realizar alguna actividad a mitad de la jornada laboral, debería poder hacerlo. Aunque en este caso no se desarrollen relaciones sociales entre empleados, sí puede ser una buena vía de escape para quienes trabajan en remoto.

Muchos piensan que el problema de trabajar en remoto es la falta de control o la dificultad para coordinarse, pero esos problemas tienen fácil solución. Ahora bien, si se descuida el aspecto social, el desastre está asegurado. Se termina con personas de baja moral, desmotivadas y, posiblemente, con problemas de salud mental. La soledad y el aislamiento se relacionan con un mayor riesgo de depresión, ansiedad, estrés y burnout, así como con síntomas físicos y psicológicos, como irritabilidad y desgaste mental.

En definitiva, la soledad que deja Tito en mí no me va a hundir, pero sí me ha servido para recordar que el aislamiento no es un asunto trivial. Sé de gente que terminó muy mal por el aislamiento del trabajo en remoto, porque su empresa no le dio importancia a la parte social. En la empresa en la que estoy, Technosylva, tengo la suerte de que se cuide este aspecto. Es de agradecer. Yo, por mi parte, seguiré trabajando para que mi equipo disponga de esos espacios para forjar vínculos y desahogarse.

¡Muchas gracias por leerme!

En la cultura popular, Kip Thorne se hizo especialmente conocido por haber sido asesor científico de la película de 2014 Interstellar, dirigida por Christopher Nolan. Si la has visto, recordarás seguro el agujero negro Gargantúa y la dilatación temporal extrema que sufren los protagonistas al acercarse a él. La física que se observa en la película es rigurosa salvo, claro, las inevitables licencias cinematográficas. Especialmente en la representación visual del agujero negro, donde se aprecia el horizonte de sucesos y el disco de acreción, tanto en el plano como desdoblado en un anillo, debido a la enorme gravedad del agujero.

En el mismo libro, Thorne habla de Subrahmanyan Chandrasekhar, una figura clave en la comprensión de las enanas blancas, los núcleos remanentes de estrellas con una masa similar a la de nuestro Sol. Chandrasekhar nació en la India, creció rodeado de intelectuales —su tío ganó un Premio Nobel—, se graduó con honores en la Universidad de Madrás y, siendo apenas un estudiante, formuló una idea que cambiaría para siempre la astrofísica estelar. Pero tardó décadas en ver su trabajo plenamente reconocido. Décadas dedicadas a trabajar en el mismo problema.

Pero este no es un artículo sobre física. Sino que es una reflexión sobre personas como Thorne, Chandrasekhar y un montón más de científicos, que han dedicado toda su vida a explorar más allá de los confines del conocimiento humano. No sólo porque eso fuera su medio de vida, sino porque se convirtió en su razón de ser en este mundo.

En informática también hay ejemplos claros de esto. Personas como Linus Torvalds, Guido van Rossum o James Gosling no “trabajan con” una tecnología concreta. La crearon, la defendieron, la refinaron y la siguen cuidando desde hace décadas.

La diferencia entre físicos e informáticos es que los primeros suelen abordar problemas fundamentales, mientras que los segundos trabajan en problemas técnicos. Los primeros buscan la verdad última sobre las leyes que rigen el universo, mientras que los segundos custodian una idea o una tecnología que ha cambiado el mundo.

Linux, Python o Java no son descubrimientos naturales. Son artefactos humanos. Sistemas que existen porque alguien decidió hacerse responsable de ellos y custodiarlos durante décadas. No como un proyecto, sino como una idea que merece ser preservada, incluso cuando deja de estar de moda.

Esto contrasta mucho con el mundo de las empresas tecnológicas. Por lo general, las personas que trabajan en tecnología cambian de proyecto, de equipo o de empresa cada pocos años. Son organizaciones diseñadas para crecer y reorganizarse constantemente. No es algo necesariamente malo. Es la dinámica natural del sistema. Es su propósito.

Pero esa dinámica actúa como una fuerza centrífuga. Te empuja fuera del núcleo técnico. Te aleja, poco a poco, de cualquier posibilidad de custodiar una idea durante décadas. Además, tu trayectoria depende enormemente del sector en el que trabajes. No es lo mismo la consultoría que el desarrollo de productos. Ni es lo mismo el sector de gestión de contenidos que el del fintech.

Quizás no sea una cuestión de talento individual lo de no dedicarse toda una vida a custodiar una idea, sino una cuestión de hábitat.

A veces da la sensación de que hemos perdido la capacidad de comprometernos profundamente con una sola cosa. Pero quizá el problema no sea ese. Quizá no nos falte vocación técnica. Quizá nos falten entornos en los que esa vocación pueda sostenerse durante treinta años.

Custodiar una idea requiere tiempo y financiación. Sobre todo, financiación. Requiere aceptar que el impacto real puede no ser inmediato, lo cual es lo contrario de lo que busca la industria tecnológica en la actualidad.

Yo no sé si podría dedicarme toda la vida a trabajar en lo mismo. Cuando paso demasiado tiempo en un mismo proyecto, aparece la monotonía. Y con ella, la necesidad de nuevos retos. Y la necesidad de cambio. Supongo que se lo debo agradecer a mi cableado interno, a mi neurodivergencia (para lo bueno y para lo malo).

Pero lo cierto es que, aun así, envidio, en el mejor sentido de la palabra, a quienes han sido capaces de dedicarse en cuerpo y alma a una sola idea. A quienes la han mimado durante décadas. A quienes han llegado donde nadie había llegado antes.

No porque quiera ser como ellos. Sino porque reconozco el valor y la dificultad de ese tipo de compromiso.

Tal vez no todos estamos hechos para custodiar una gran idea. O tampoco todos tenemos una gran idea que merezca ser custodiada. Tal vez algunos estamos hechos para explorar, conectar, mover ideas de un lugar a otro. La ciencia y la ingeniería necesitan ambas cosas.

¡Muchas gracias por leerme!

Así que hice lo único que tenía sentido: empecé a escribir.

Me puse un compromiso sencillo y personal —un artículo a la semana— y dejé que el tiempo hiciera su trabajo. Y, de momento, lo he cumplido.

No soy especialmente amigo de los propósitos de Año Nuevo. Siempre he sido más de fijarme objetivos a medida que van apareciendo, como esta newsletter o escribir el libro Crafting Platforms. Pero también creo que, ya que estamos en los primeros días del año, no está de más parar un momento, mirar un poco hacia adelante y decidir qué cosas merece la pena intentar sostener durante los próximos doce meses.

Así que estos son algunos de mis propósitos, personales y profesionales, para este año.

Seguir escribiendo Principia Machina

El primero es obvio: seguir escribiendo esta newsletter.

Le he cogido el gusto a escribir semanalmente. No me quita demasiado tiempo, pero me obliga a sentarme con calma, a ordenar ideas y a pensar en profundidad qué quiero contar. Así que la idea es clara: seguir escribiendo, como mínimo, un artículo cada semana.

Alguna vez se me ha pasado por la cabeza escribir Principia Machina en inglés para llegar a más gente. Pero de momento, no lo voy a hacer. Escribir en mi lengua materna me ayuda a pensar mejor y a articular mejor las ideas. Esta newsletter seguirá en español. Crafting Platforms, en cambio, seguirá siendo en inglés. Cada cosa en su sitio.

Hacer crecer la newsletter

Me gustaría que Principia Machina alcanzara los 1.000 suscriptores este año. Y este objetivo sí va a requerir algo más de esfuerzo.

Hasta ahora el crecimiento ha sido casi totalmente orgánico, sin apenas promoción. Eso está bien, pero también limita. No tengo claro qué estrategia funcionará mejor, así que iré probando: participar más en la comunidad de Substack, compartir mejor los artículos y, si realmente aporta valor, quizá ofrecer algún contenido exclusivo para suscriptores (siempre gratuito).

Creo que es un objetivo razonable y alcanzable si hago un poco más que solo escribir y cruzar los dedos.

Terminar Crafting Platforms

Otro objetivo importante es terminar de escribir Crafting Platforms este año.

Empecé en octubre de 2025 con la idea de cerrarlo en doce meses y sigo pensando que es realista. Los dos primeros capítulos —más conceptuales y un poco más densos— ya están escritos. Ahora viene la parte divertida, que es la más técnica.

Si además consigo cerrar el año con al menos 100 ventas del libro, me daré más que por satisfecho. A finales de año tocará revisar cómo distribuirlo mejor si empieza a coger algo de tracción.

Profundizar en inteligencia artificial

También quiero ponerme más en serio con la inteligencia artificial.

No es que me haya quedado atrás: uso IA a diario en el trabajo y la voy incorporando poco a poco a mis flujos —programar, escribir, investigar, resumir reuniones, pensar—. Pero quiero ir más allá. Entenderla mejor desde una perspectiva estratégica.

Quiero que mi equipo en Technosylva también la utilice bien y para eso primero tengo que formarme yo mejor. Entender cómo puede transformar nuestro sector y cómo liderar ese cambio desde la ingeniería.

Un penúltimo empujón al Grado de Física

Este año quiero aprobar las seis asignaturas en las que estoy matriculado en el Grado de Física, en la UNIR (algún día os contará más sobre por qué estudio esta carrera).

Es un proyecto que empecé hace años, que he ido dejando y retomando, y que por fin se empieza a ver el final. Si todo va bien, para el curso que viene solo me quedarían cuatro asignaturas y el TFG (dos años en total)

Aunque las asignaturas son más duras en este tramo final, curiosamente me están costando menos. Supongo que el conocimiento acumulado ayuda y que ahora entramos en materias mucho más interesantes.

¿A quién no le va a gustar astrofísica, cosmología o cuántica? ¿A quién no le va a gustar?

Seguir corriendo ultradistancia

Quiero seguir corriendo ultras.

El año pasado no salió como esperaba: algunas molestias, menos motivación… pero este año he empezado mejor. Sin prisas. Con más cabeza. No quiero colapsar. El objetivo será correr dos carreras largas, una en primavera y otra en otoño, además de alguna más corta como preparación.

Quiero disfrutar más del proceso que del dorsal. De los entrenamientos, de perderme por nuevos caminos, de subir montañas. Siempre digo que con 45 años —que cumplo en 2026— ya va siendo hora de colgar las botas. Pero mientras me siga sirviendo para desconectar y pensar, seguiré.

Mejorar en tenis

En lo deportivo, también quiero seguir mejorando en el tenis.

Empecé en febrero de 2025 y me está gustando mucho. Es un deporte técnico, exigente y que requiere disciplina. Este año quiero jugar al menos un partido por semana, además de las clases, y seguir afinando la técnica.

Además, lo practica el resto de la familia, por lo que es una excusa perfecta para pasar tiempo juntos.

Resumen rápido

En corto, mis propósitos para este año son:

• Escribir un artículo semanal en Principia Machina

• Escribir un capítulo al mes de Crafting Platforms

• Llegar a 1000 suscriptores en la newsletter

• Vender al menos 100 copias del libro

• Profundizar en inteligencia artificial

• Aprobar las seis asignaturas del Grado de Física

• Correr dos ultras

• Jugar al menos un partido de tenis a la semana

Nada especialmente épico. Nada imposible.

¿Y vosotros? ¿Qué os gustaría empezar o mantener durante este año?

¡Muchas gracias por leerme!

Así me fui de mi anterior empresa, Epos Now, hace exactamente un año. El mismo 31 de diciembre de 2024.

No fue una decisión fácil, pero sí necesaria. Necesaria para mi salud mental y bienestar general. Dejar una empresa nunca es sencillo, y menos aún cuando lo has dado todo durante años, cuando has construido cosas con cariño y cuando, por el camino, has creado relaciones personales que van mucho más allá de la jerarquía.

Es un salto al vacío. Lleno de incertidumbre. Sin saber si habrá una red que amortigüe la caída.

Aunque mi salida fue abrupta, no fue impulsiva. Llevaba meses pensándolo. Meses dándole vueltas a una sensación que no desaparecía. Había llegado a la conclusión de que necesitaba un cambio radical. La mentalidad de la empresa estaba intoxicando todo lo que mis compañeros y yo habíamos construido con tanto esfuerzo.

Pese a nuestro empeño —y a nuestra responsabilidad— por fomentar una buena cultura de ingeniería, nunca contamos con el apoyo necesario. Ni las herramientas. Ni el respaldo real. El foco siempre estaba en el corto plazo. En los resultados inmediatos. Y el coste humano de esa estrategia no entraba en la ecuación.

Cuando eres mánager, tienes una responsabilidad clara: cuidar a tu equipo. Sin un equipo bien tratado, motivado y apoyado, en un entorno psicológicamente seguro, es prácticamente imposible alcanzar objetivos técnicos o de negocio de forma sostenible. Y cuando se alcanzan, suele ser a regañadientes y a costa de quemar a la gente.

Ser mánager es, en esencia, resolver problemas. Allanar el camino para que tu equipo pueda hacer su trabajo lo mejor posible. Protegerlo de distracciones, de la burocracia innecesaria y de dinámicas tóxicas. Ayudar a crecer. Escuchar. Actuar. Celebrar los éxitos. Y cuando toca, tomar decisiones difíciles por el bien del equipo y de la organización. Y, por supuesto, recompensar el esfuerzo de forma justa.

En casi todo eso, un mánager tiene margen de maniobra. Control. Responsabilidad directa. Pero hay cosas que no dependen de ti.

Una de ellas es la cultura de la empresa. Si la cultura es tóxica —o simplemente no está alineada con los valores que tú y tu equipo defendéis—, estás en un callejón sin salida. Puedes intentar cambiarla desde dentro. Puedes empujar. Argumentar. Insistir. Pero si la dirección no está dispuesta a escuchar ni a hacer cambios reales, es imposible seguir adelante.

Y sí, ya lo sé: “Pero tú eras director, ¿no? ¿No tenías poder para influir?”

Sí. Pero incluso los directores tenemos límites. Límites claros. Si la dirección ejecutiva no comparte tu visión, terminas luchando contra viento y marea. Siempre hay un pez más grande. Y ese desgaste, sostenido a lo largo del tiempo, pasa factura.

La otra cosa que no depende de ti es la compensación justa.

Puedes pelear por mejores salarios y mejores condiciones para tu equipo. Puedes justificarlo con datos, resultados y performance reviews impecables. Pero al final del día, la empresa tiene la última palabra. Y cuando la empresa no está dispuesta a pagar lo que la gente merece, te quedas atrapado entre la espada y la pared. Sobre todo cuando sabes que tienes razón, porque solo estás pidiendo ajustar el salario al mercado para retener el talento.

Es especialmente frustrante cuando alguien ve que la empresa va bien, que los resultados acompañan, pero su salario se estanca mientras sus responsabilidades no dejan de crecer. A corto plazo puede aguantar. Puedes explicarle el contexto económico. El plan de la empresa. Las promesas futuras. De hecho, es tu deber, como mánager, hacerlo.

Pero si esas promesas no se cumplen, a largo plazo pasa algo mucho peor: pierdes credibilidad. El marrón de explicar por qué la realidad no es la que debería ser siempre acaba cayendo sobre ti. Y sin credibilidad, no hay liderazgo.

Todo lo que construyes con tanto cariño durante años puede dejar de ser sostenible de un día para otro.

Yo me fui sin un plan. Sin una oferta de trabajo. Sin saber qué vendría después.

Solo sabía que no podía seguir allí. Que mi salud mental estaba en juego. Y que necesitaba parar y cambiar radicalmente de rumbo.

Ese supuesto tiempo sabático duró poco. Apenas unas semanas después se cruzó una oportunidad inesperada. Había una empresa de León dedicada a la ciencia del fuego que buscaba un Principal Engineer para liderar su transformación DevOps.

¿Ciencia? ¿Salvar vidas y el planeta? ¿Centrarme exclusivamente en la parte técnica?

Aguántame el cubata.

Y así llegué a Technosylva. Una empresa con una cultura sana. Que cuida a su gente. Que proporciona herramientas y apoyo real. Que entiende que un equipo feliz y motivado es, además, un equipo eficaz. Una empresa donde puedo ser yo mismo, tomar decisiones técnicas y estratégicas, y trabajar sin tener que navegar por políticas internas tóxicas.

Empecé hace diez meses como Principal Engineer. Y, por mi experiencia previa, me he involucrado mucho en la creación de procesos, prácticas y de cultura de ingeniería. Y lo hago encantado. Porque aportar valor donde hace falta es, sencillamente, lo que me gusta hacer. Y es muy gratificante ver que hay cosas estancadas que empiezan a funcionar gracias a los procesos que habéis implementado.

Hace un par de semanas, mi VP de Ingeniería me propuso asumir no solo el liderazgo técnico, sino también el ejecutivo de todo el área de ingeniería de plataforma.

Un año exacto después de dejar mi anterior empresa, me encuentro en el mismo rol que dejé. Pero esta vez con una diferencia fundamental. Conozco la empresa, su cultura, a su gente y sus valores. Y sé que cuento con el apoyo de la dirección ejecutiva y de HR. Y también sé que contaré con las herramientas necesarias para resolver los problemas que surjan. Y eso, después de todo lo vivido, me tranquiliza mucho.

Estoy preparado para el 2026.

¡Muchas gracias por leerme!

¡Feliz año nuevo!

Esa diferencia entre saber cómo se hacen las cosas y la acción real no es anecdótica, sino que está perfectamente documentada en el libro The Knowing-Doing Gap de Pfeffer y Sutton. Básicamente, dice que el conocimiento no se traduce automáticamente en acción. Muchas organizaciones saben qué hacer, pero no lo hacen.

Una pregunta habitual que me hago cuando tengo que contratar a alguien: ¿Necesito estabilidad o disrupción?

Normalmente aparecen dos perfiles muy distintos. Uno te ofrece energía y ansias de aprender. Otro, experiencia y cautela. Los primeros tienen curiosidad y empuje. Improvisan, aprenden, se entusiasman. Los segundos tienen cicatrices. Han visto sistemas fallar, conocen que algunos atajos son peligrosos y son buenos anticipando riesgos. Pero esa experiencia también viene con la memoria del dolor. Es decir, la aversión al riesgo crece con cada mala experiencia o cada incendio apagado. Las investigaciones sobre cognitive entrenchment muestran que un alto nivel de expertise puede convertirse en una fijación que limita la flexibilidad y la capacidad de adaptación a nuevos contextos. Algunos expertos se vuelven menos innovadores y menos creativos precisamente por su conocimiento acumulado

Para aclararnos, en este contexto estoy usando saber y ejecutar como ejes ortogonales:

• Saber es entender cómo funcionan las cosas, conocer los riesgos, anticipar problemas y haber visto ese error antes.

• Ejecutar es decidir con información incompleta, empujar cuando no todo está claro, aceptar fricción y asumir que algo se puede romper.

Estos dos ejes forman un espectro saber-ejecutar. Puedes tener mucha experiencia y ser reactivo, ser inexperto y metódico, o cualquier otra combinación de ambos. La tentación de creer que más años de experiencia implican una mayor capacidad de ejecución es errónea. Hay personas que saben mucho y mueven poco, y otras que aún no saben tanto y, sin embargo, tiran del carro.

La experiencia sin energía no solo protege el statu quo, sino que también paraliza la innovación. Un estudio de McKinsey sobre la cultura de innovación revela que el 85 % de los ejecutivos admiten que el miedo frena sus esfuerzos de innovación y que, en las empresas menos innovadoras, ese miedo es hasta cuatro veces más frecuente que en las empresas líderes. Las tres grandes barreras identificadas son el miedo a las críticas, el miedo a la incertidumbre y, sobre todo, el miedo al impacto en la carrera profesional. Cuando creemos que nuestras decisiones pueden poner en riesgo nuestra reputación o nuestro salario, preferimos no movernos.

Por contraste, las personas con alta energía rompen cosas y, a veces, rompen las que había que romper. Hacen, prueban, cambian sin pedir permiso. Ese empuje genera aprendizaje real. Sí, falta criterio y se cometen errores, pero también se descubren rutas que los veteranos no ven porque están atrapados en su propio mapa mental. Las mejores organizaciones combinan ambos perfiles y crean un entorno en el que arriesgar no suponga arruinar su carrera. Según McKinsey, las empresas líderes en innovación son 2,9 veces más propensas a exigir a sus ejecutivos que demuestren iniciativa innovadora para progresar, y también fomentan una cultura en la que el fracaso se considera un experimento reversible y no una marca en el expediente.

¿A quién contratamos entonces?

No hay respuesta única. Depende del momento. Si el equipo está estancado y nadie ejecuta, quizás necesites más energía aunque haya riesgo de romper cosas. Si el sistema es frágil y cada fallo cuesta millones, tal vez necesites experiencia que te permita anticipar problemas. La pregunta correcta no es quién sabe más, sino qué necesita ahora la organización o el equipo: ¿movimiento o estabilidad? ¿explorar o consolidar? ¿reducir riesgo o crear opciones? Y, sobre todo, ¿cómo evitar que el conocimiento se quede en un PowerPoint? La mejor forma es crear espacios donde saber y ejecutar convivan.

No se trata de elegir entre estabilidad y disrupción como si fueran polos opuestos, sino de entender en qué momento y para qué se necesita cada uno. La ventaja competitiva quizás no está en la experiencia, sino en quienes transforman el saber en acción y se atreven a ejecutar cuando el mapa no está completo.

¡Muchas gracias por leerme!

Si un árbol cae en un bosque y no hay nadie para escucharlo, ¿hace algún sonido?

Desde la perspectiva de Berkeley, el árbol no haría ningún sonido porque no hay una mente consciente que lo perciba. El sonido es una experiencia sensorial que requiere un oyente. Si no hay nadie para escuchar el árbol caer, entonces no hay experiencia auditiva y, por lo tanto, en términos de percepción, el sonido no existe.

Desde el punto de vista de la física, sin embargo, el árbol sí emitiría un sonido al caer, ya que produciría ondas sonoras.

Esta misma situación es la que me encuentro a menudo al tratar de definir, junto con colegas, qué es exactamente la disponibilidad. ¿Está disponible un servicio si nadie lo está usando?

La casuística es de lo más variopinta y las interpretaciones dependen en gran medida del contexto. Pero empecemos por una definición general. Según la RAE:

Disponibilidad: Cualidad o condición de disponible.

No nos ayuda mucho, así que afinemos un poco más el tiro.

En ingeniería de sistemas, la disponibilidad se refiere a la capacidad de un sistema o servicio para estar operativo y accesible cuando se requiere. Esto implica que el sistema debe estar funcionando correctamente y ser capaz de responder a las solicitudes de los usuarios en cualquier momento.

La disponibilidad se mide comúnmente como un porcentaje del tiempo total durante el cual un sistema está operativo. Por ejemplo, una disponibilidad del 99,9 % implica aproximadamente 8,76 horas de inactividad al año.
Pero ¿qué significa esto en la práctica?

Normalmente, estos porcentajes se establecen en los SLA (Service Level Agreements) entre proveedores y clientes, junto con penalizaciones por incumplimiento. El problema es que casi siempre se deja abierta la interpretación de qué significa exactamente que un sistema esté “operativo y accesible”.

En muchas empresas, la disponibilidad se mide simplemente como el tiempo que un servicio está en línea y responde a solicitudes básicas. El uptime suele calcularse mediante herramientas de monitorización que hacen pings periódicos al servicio. Si responde, se considera disponible.

Esto es engañoso.

Un servicio puede estar levantado y, aun así, no estar funcionando correctamente. Por ejemplo, un servicio web puede responder, pero si una API externa de la que depende está caída, el servicio no puede cumplir su función.
¿Está disponible en ese caso? Evidentemente no.

Suscríbete ahora

Aquí aparece el acoplamiento de disponibilidad: la disponibilidad de nuestro servicio nunca puede ser mayor que la de los servicios de los que depende. Si dependemos de una API externa con una disponibilidad del 99 %, ese será, como máximo, nuestro techo teórico.

De ahí la importancia de definir con claridad qué significa “disponible” en nuestros SLA.

Otra forma de medir la disponibilidad es mediante el número de peticiones exitosas frente al total de peticiones. Si un servicio recibe 1000 peticiones en un día y 990 son exitosas, la disponibilidad sería del 99 %.
Esta métrica refleja mucho mejor la experiencia real del usuario.

Pero también tiene sus trampas. No es lo mismo estar caído una hora en plena hora punta que una hora de madrugada. Si el tráfico es uniforme durante 24 h, esta métrica es bastante representativa. Si no, hay que interpretarla con cuidado.

Por último, podemos medir la disponibilidad a partir del tiempo medio entre fallos (MTBF) y del tiempo medio de reparación (MTTR). El MTBF mide cuánto tiempo funciona un sistema sin fallar; el MTTR, cuánto tarda en recuperarse cuando falla. Cuanto mayor sea el primero y menor el segundo, mayor será la disponibilidad.

De esto hablamos en el Principia #1: Fiabilidad (Reliability). Si un servicio tiene un MTBF de 1000 horas y un MTTR de 1 hora, su disponibilidad aproximada será del 99,9 %, calculada como:

Esta métrica es especialmente útil porque es menos sensible al “ruido”. Se declara un fallo cuando el sistema deja de funcionar, algo que podemos detectar directamente mediante alertas o indirectamente a través de quejas de usuarios. Una vez detectado el fallo, medimos cuánto tardamos en recuperarnos.

Si ocurre un fallo que no se detecta, no afecta a la métrica de disponibilidad, aunque sí puede afectar brevemente a la experiencia del usuario… que normalmente se encargará de avisarnos si el problema se alarga demasiado.

En resumen, la disponibilidad es una métrica imprescindible para evaluar tanto la fiabilidad como la experiencia de usuario de un sistema o servicio. Pero, como casi todo en ingeniería, su valor depende de cómo la definamos y de qué estemos midiendo realmente.

Porque, al final, igual que con el árbol de Berkeley: si el servicio deja de funcionar cuando nadie lo utiliza… ¿está realmente disponible?

¡Muchas gracias por leerme!

Era una organización puramente reactiva, con un equipo de ingeniería que operaba en modo caja negra y reportaba directamente a los jefes de producto. Y esa estructura se veía reflejada en la arquitectura del producto, que era un monolito difícil de mantener, con límites difusos, sin ownership y con decisiones impulsadas por quien gritara más fuerte ese día.

Aunque igual esto no te sorprende. Si has trabajado en una organización con una comunicación lenta, difusa o caótica, habrás visto cómo las decisiones técnicas se vuelven rehenes de las decisiones organizativas. Equipos bloqueados porque dependen de otro equipo, que a su vez depende de otro equipo, que a su vez depende de… vete tú a saber quién. Cosas mal parcheadas porque “ese componente lo toca otro equipo y no puede hacerlo ahora mismo”. Retrasos, frustración y esa sensación de que “esto podría ir mucho más rápido, pero algo nos está frenando”.

Ese “algo” tiene nombre desde 1968: la ley de Conway. Y es implacable.

O, dicho de otro modo, la organización de la empresa se refleja en la arquitectura del sistema que esta produce.

Unos meses antes de que yo llegara, la empresa había contratado a un CTO que ya había empezado a trabajar en el problema del desorden, separando al equipo de ingeniería del de producto, con sus propios líderes (yo incluido) y procesos. Esta separación permitió que ingeniería recuperara autonomía y gobierno para priorizar la calidad, la arquitectura y la infraestructura, y no únicamente las nuevas funcionalidades.

Pero esto solo no resuelve el problema. Según la ley de Conway, si no diseñas tu organización para producir la arquitectura que quieres, te impondrá una arquitectura que no quieres. Y eso es precisamente lo que pasaba.

El equipo de ingeniería recibía peticiones de todas partes: jefes de producto, VPs, COO, CEO… Con tantos canales de entrada, el software estaba fragmentado, con prioridades cambiantes, decisiones inconexas, sistemas acoplados y una arquitectura infumable.

Aunque inicialmente entré para liderar infraestructura, a los pocos meses me convertí en director de ingeniería. Esto me permitió tener una visión mucho más global de todo y la verdad es que el paisaje era desolador. Pero también me brindó la oportunidad de trabajar en uno de los retos más interesantes en mi carrera profesional. Con la salida del CTO, vino una reorganización y mi compañero James y yo terminamos por tomar las riendas del caballo desbocado. Teníamos clara la visión arquitectónica que queríamos: pasar del monolito a un conjunto de dominios bien definidos, cada uno con sus servicios, su modelo mental y su equipo de liderazgo.

Suscríbete ahora

La respuesta vino de aplicar la ley de Conway inversa, aunque nosotros no sabíamos que se llamaba así. Simplemente la dedujimos a base de cabezados, y darnos cuenta de que como la información fluía tenía un impacto directo en lo que produciamos. Esta idea fue formalizada por Jonny Leroy y Matt Simons, de ThoughtWorks, en 2010. La resumen así:

Esta es la tendencia hoy en las empresas tecnológicas. Se organizan los equipos según la arquitectura del servicio que queremos construir, no según funciones genéricas (p. ej., frontend, backend, database, sysadmins…). Esto es la espina dorsal de Team Topologies, de Manuel Pais y Matthew Skelton (muy buen libro si necesitas ideas para organizar equipos).

James y yo terminamos por organizar los equipos de Epos Now en distintas tribus: Money, Data, POS, Integrations… que a su vez tenían distintos flujos de trabajo: mobile app, Web app, hardware, payments, my account… Cada equipo con ownership claro, fronteras bien definidas, un product manager único como punto de entrada, autonomía técnica y responsabilidad absoluta sobre su servicio. La diferencia fue inmediata. Había menos confusión, priorizaciones más claras, menos bugs, ciclos de desarrollo más cortos… y equipos más motivados.

Y casi como por magia, la arquitectura que queríamos empezó a alinearse con la nueva organización. Pero no era magia, era simplemente la ley de Conway funcionando a nuestro favor.

Reorganizar equipos implica quitar poder, cambiar hábitos y poner límites a quien antes podía pasar por encima del proceso. Eso no gustaba. Hubo resistencia. Mucha. Especialmente fuera de ingeniería. Pero con transparencia, diálogo, paciencia y resultados, la mayoría entendió que esta organización no era un capricho, sino una necesidad.

¡Muchas gracias por leerme!

Hace tres años esto era impensable. Cuando aparecieron los primeros LLMs con potencial real, nuestra reacción colectiva fue claramente defensiva. Nos pusimos tiquismiquis. Les pedíamos a los desarrolladores que no los usaran para programar, sino que, como mucho, para generar esqueletos de documentos o de proyectos. Los veíamos casi como un riesgo que había que contener.

Hoy hemos dado un giro de 180 grados. Sabemos que quien utiliza la IA correctamente tendrá una ventaja competitiva. Queremos que los desarrolladores se apoyen en ella para todo: revisión de código, scaffolding, investigación de problemas, documentación, comprensión de proyectos… Especialmente útil para quien se incorpora a un equipo y necesita entender en días lo que antes llevaba semanas.

Pero si queremos que todo esto ocurra con garantías, sin exponer la propiedad intelectual ni los datos de los clientes, y priorizando la calidad sobre la cantidad, necesitamos políticas claras en la empresa para la adopción de estas tecnologías. En Technosylva acabamos de lanzar una, esponsorizada directamente por el equipo ejecutivo, lo que le confiere un peso especial. No es una iniciativa de ingeniería, sino algo transversal que afecta a toda la organización.

Hablando con compañeros de otras empresas, el panorama es de lo más variado:

• Algunas todavía no tienen una postura definida.

• Otras han estandarizado herramientas como GitHub Copilot, Cursor, etc.

• Y otras prefieren que cada desarrollador elija la suya entre una lista permitida.

No creo que exista una respuesta universal. Es demasiado pronto para sacar conclusiones sólidas, y cada empresa tiene una cultura, un nivel de madurez y una estrategia distintos en el uso de la IA. Lo que sí está claro es que nadie quiere quedarse atrás. La IA ha venido para quedarse (y no como aquella gilipollez del Blockchain).

Y, pese a este entusiasmo generalizado, seguimos siendo muy reacios a preguntar en entrevistas si los candidatos utilizan IA en su día a día. Queremos mantener la pose de “empresa purista”, de “ingenieros de verdad”. Y desde la perspectiva del entrevistado, preguntar si está permitido puede interpretarse como algo negativo —como si admitiera que necesita ayuda para hacer su trabajo. Cuando precisamente es todo lo contrario. Para ambas partes.

Esto me lleva a pensar en todos esos ingenieros top, con años de experiencia, que utilizan la IA generativa de forma eficiente, integrada, casi invisible. Que producen resultados de altísima calidad. Son ingenieros 3x, pero se sienten cohibidos al preguntar si en esa empresa podrán trabajar así. O directamente, no aplican a ofertas porque no se menciona nada sobre el uso de IA, las herramientas permitidas ni si existe un presupuesto asignado a licencias.

Y ahí, creo, estamos perdiendo la oportunidad de atraer talento.

Pero ya no solo hablar abiertamente sobre el uso de la IA durante la entrevista, sino que también deberíamos permitirla en las entrevistas de trabajo que requieran un code challenge. Que, dado un proyecto open source random con cientos de archivos, durante la entrevista sea capaz de entender la estructura del proyecto, implementar un cambio, revisarlo, darle feedback a la IA, etc. O transformar un pequeño proyecto PHP en Golang. ¡Estaría guay!

Suscríbete ahora

Quizá ha llegado el momento de normalizar la pregunta. De dejar de fingir que seguimos trabajando como hace una década. De escribir en las ofertas de trabajo —con la misma naturalidad con la que hablamos de remoto, stock options o presupuesto de formación— algo como:

En esta empresa creemos que la inteligencia artificial es una herramienta que mejora la productividad y ofrece una ventaja competitiva.

Fomentamos su uso responsable para acelerar el trabajo, mejorar la calidad del software y reducir la fricción del día a día. Ponemos a disposición de cada desarrollador las herramientas adecuadas, políticas claras de uso y el soporte necesario para integrarla de forma segura en su flujo de trabajo.

A lo mejor no es solo un detalle. A lo mejor es lo que marca la diferencia entre atraer a un ingeniero del montón… o a ese 3x que ya vive en el futuro. ¿O estoy desvariando mucho?

¡Muchas gracias por leerme!

DevOps, DevSecOps, FinOps… cada una de estas capas culturales que nos ha traído la nube acaba cayendo, de una forma u otra, sobre los equipos de desarrollo. Y aunque está más que demostrado que un modelo de responsabilidad compartida funciona mejor, este no se adopta de la noche a la mañana.

Si un equipo nunca ha trabajado con observabilidad porque dependía del equipo de SRE, no puede asumir mañana que la latencia y los errores son su responsabilidad. Si nunca ha tenido que mirar la factura, no va a optimizar costes de repente. Si nunca ha tenido que pensar en seguridad, no va a integrar escáneres en los pipelines por arte de magia.

La clave, como casi siempre, es ir poco a poco. Hoy os cuento la metodología que que siempre me ha funcionado, y que consta de tres fases muy bien definidas.

Concienciación

Lo primero es concienciar al equipo. Y nada es tan efectivo como enseñarles lo que hay debajo de la alfombra. Un dashboard con errores, latencias, costes o vulnerabilidades, y explícales que, a partir de ahora, esos números importan... y son su responsabilidad.

Créeme. Nadie es realmente consciente del estado de su software hasta que ve las entrañas así, sin filtros. Y cuando lo ven, se asustan. Y está bien que se asusten. Ese impacto es el que queremos, porque lo que buscamos es un cambio de mentalidad.

Además, cuando empiezan a mover una métrica y ven resultados —menos latencia, menos vulnerabilidades, un 20% menos de costes— aparece un refuerzo positivo que los puede motivar a continuar.

Durante esta fase es esencial crear un entorno seguro. Nada de culpas, nada de señalar. Solo entendimiento y responsabilidad compartida. Mostrar que lo que hacemos tiene un impacto directo en el negocio cambia completamente la actitud del equipo.

Y luego está que a ningún equipo le gusta que sea su servicio el que está siempre en rojo.

Remediación

Una vez visto el estado real de las cosas, toca actuar. Pero no a lo loco.

La intención aquí no es abrir diez frentes a la vez, sino priorizar. En esta fase suelen aparecer muchas iniciativas, pero sin foco se pierde dirección. Por eso es importante establecer objetivos SMART: concretos (specific), medibles (measurable), alcanzables (achievable), relevantes (relevant) y con un plazo claro (time-bound).

Ejemplos típicos:

• Reducir un 30% las vulnerabilidades críticas en el próximo trimestre.

• Identificar las 3 cargas más caras y elaborar un plan de optimización.

• Definir y activar alertas básicas de SLO para los servicios clave.

Aquí también es donde se destapan las carencias de conocimiento. Y hay dos caminos:

1. Formar al equipo, y hacerlo bien.

2. Traer el conocimiento, ya sea mediante consultoría o contratación.

Y, por supuesto, proporcionar buenas herramientas.

Responsabilidad

Cuando el equipo ya sabe qué mirar, cómo mejorarlo y cuenta con las herramientas y habilidades necesarias, llega la fase final: la responsabilidad plena. En este caso me refiero a responsabilidad como accountability, que implica que se asuman consecuencias si no se cumplen con los objetivos.

A partir de aquí, estas áreas dejan de ser “trabajo adicional” y pasan a ser parte natural del día a día:

• Todo está monitorizado correctamente.

• Hay reportes periódicos que se revisan en equipo.

• Los costes se entienden y se gestionan.

• La seguridad está embebida en todo el ciclo de desarrollo.

• La calidad está instrumentada, no asumida.

Esta es la auténtica madurez. Cuando la mejora continua está integrada y alineada con los objetivos del departamento y del negocio.

Llegar aquí lleva tiempo —meses o incluso años— y depende mucho del punto de partida, la inversión en herramientas y la formación. Pero es un destino al que merece la pena llegar. Cuanto más control tengamos sobre la calidad, seguridad y costes de nuestro software, más competitivo será nuestro producto y más capacidad tendremos para innovar y adaptarnos.

¡Muchas gracias por leerme!

Uno de esos problemas me ha acompañado en todos los equipos donde he trabajado y aparece cada vez que intentas introducir una práctica nueva en un equipo de ingeniería: una plataforma, un modelo de QA, una cultura DevOps o cualquier cambio profundo en la forma de trabajar.

Yo lo voy a a llamar resistencia al cambio causado por el Engineering Momentum. Otros autores se pueden referir a algo parecido como fricción o arrastre, pero creo que eso tiene una connotación más cultural que lo que voy a tratar hoy.

El paralelismo con la física

En física, el momento (o cantidad de movimiento) es proporcional a la masa y la velocidad de un objeto .

Un tráiler cargado a 90 km/h tiene mucho momento: no puedes girar 90° de golpe sin que el vehículo intente seguir recto, y de cuatro vueltas de campana. Para cambiar su dirección, a esa velocidad, necesita aplicar una fuerza suave, pero constante, en la dirección a la que quieres ir, y durante más tiempo.

En los equipos de ingeniería pasa exactamente lo mismo.

Los equipos de desarrollo tienen una masa:

• personas

• hábitos adquiridos

• procesos heredados

• herramientas legadas

• stack tecnológico

• interdependencias entre equipos

• decisiones históricas que nadie recuerda del todo

Y tienen también una velocidad:

• roadmap agresivo

• deadlines

• presión de negocio

• promesas hechas

• carga operativa

Cuanto mayor es la masa y la velocidad, mayor es el momento del equipo. Y, por tanto, más difícil es cambiar su trayectoria.

Esto no es una mera metáfora simpática. Es exactamente lo que sucede con cualquier transformación, concretamente en equipos de ingeniería.

Ignorando el problema subyacente

Aquí es donde muchos equipos de plataforma ―y muchas iniciativas de mejora― se estrellan. Se asume que, si la solución es buena, la adopción llegará por sí sola. Pero se está ignorando el momento del equipo. La dificultad intrínseca de cambiar su trayectoria.

En la práctica, nunca partes de una pizarra en blanco sobre la que diseñar una plataforma ideal. Siempre hay un ecosistema legado y enredado de sistemas, expectativas, procesos y rutinas. Y precisamente los problemas en ese ecosistema son los que motivaron a crear la plataforma en primer lugar. Para simplificar, para estandarizar… Por lo tanto, no se puede empezar a desarrollar una plataforma ignorando esos problemas y prometiendo que se solucionarán cuando, mágicamente, todo se migre a la plataforma.

Una plataforma introduce fricción organizacional, aunque esté perfectamente diseñada.

Da igual lo buena que sea la plataforma. Si exige esfuerzo en un momento de alta carga, el equipo que tiene que adoptarla ofrecerá resistencia.

Y a veces esa resistencia ni siquiera es consciente. Es cultural. Es fricción. Es el propio momento del equipo.

La fuerza correctiva

He experimentado este problema varias veces. Y visto con perspectiva, es uno de los desafíos más complejos y fascinantes del trabajo de plataforma. Puede llegar a ser incluso más agradecido y reconfortante que el propio reto tecnológico.

Porque una plataforma va a cambiar la forma en que trabajan los equipos. Introduce nuevos flujos, nuevas herramientas, nuevas reglas. Y eso afecta a la velocidad, al esfuerzo mental y a la seguridad psicológica de los equipos. No es extraño que aparezca lo que algunos llaman change fatigue (cansancio acumulado ante cambios constantes).

Por eso no puedes desaparecer durante un año, construir “la plataforma ideal” y volver diciendo: “Ya podéis migrar”. Si en un mes no estás dando soluciones, tu mánager puede invitarte a salir por la misma puerta por la que entraste. La inversión en el equipo de plataforma no tiene sentido.

La plataforma debe nacer acompañando, no imponiendo.

Tenemos que empezar ayudando en los problemas actuales, incluso si “no son de plataforma”. Tenemos que ganar credibilidad resolviendo fricción real. A medida que esa credibilidad crece, podemos aplicar esa “fuerza suave pero constante”:

• guía

• empatía

• documentación clara

• ejemplos

• golden paths

• soporte humano

• colaboración

• pequeños wins

Poco a poco, el momento del equipo cede. La trayectoria empieza a cambiar. Y el cambio deja de sentirse como una obligación para convertirse en una mejora evidente.

Escuchar, respetar, acompañar

Hay que escuchar más que imponer.

Hay que respetar su carga antes de pedirles un esfuerzo.

Hay que demostrar valor antes de exigir adopción.

Los equipos de plataforma no somos los policías de los procesos de ingeniería. Ni dictadores que imponen ideales. Somos socios estratégicos.

Y con el tiempo, esa combinación de respeto, constancia y colaboración tiene un efecto inevitable. El momento del equipo de ingeniería deja de ser una barrera y se convierte en energía que empuja en la misma dirección.

Cuando eso ocurre, todo empieza a fluir.

¡Muchas gracias por leerme!