🇪🇸 (10’) Emilio Carrión alerta sobre un trade-off poco discutido: la IA acelera la escritura de código, pero aumenta la opacidad operativa. Cada línea aceptada sin una comprensión profunda reduce el modelo mental del sistema y encarece la depuración. No es código “malo”; es código que nadie entiende del todo y esa opacidad se acumula como una nueva deuda técnica. Defiende que la ventaja ya no está solo en producir más, sino en saber operar a ciegas: construir modelos mentales rápidos, diagnosticar bajo incertidumbre y documentar las decisiones que la IA no explica.

🇬🇧 (6’) Eduardo Ferro nos cuenta cómo ha pasado de acumular reglas en CLAUDE.md a encapsular su experiencia en “skills” reutilizables para Claude Code, activables bajo demanda y sin saturar el contexto. A partir del trabajo de Lada Kesseler con skill-factory y augmented-coding-patterns, amplía el repositorio con 11 nuevas habilidades centradas en el rigor del testing. Lo que nos deja Eduardo me lleva a preguntarme: si ya repites estos principios a nuestros equipos, ¿por qué no “enseñárselos” a la IA?

🚀 El ofertón: la oferta de trabajo que más me ha llamado la atención esta semana

Ashby, un SaaS de reclutamiento con clientes como Notion, Shopify o Snowflake y que crece >100 % YoY, busca un Staff Platform Engineer/SRE para llevar su infraestructura al siguiente nivel. Trabajarás en AWS con TypeScript, Postgres y Kubernetes, diseñando el “paved road” para que los equipos de producto desplieguen de forma rápida y segura.

¡Me interesa!

💰 €141k-226k + equity | 📍Remoto en la UE 🇪🇺 | 🧑‍💻 AWS, TypeScript, Postgres, SRE / Platform

🇬🇧 (5’) Galo Navarro nos lanza una reflexión sobre cómo las code reviews ya no escalan en un contexto de producción acelerada por IA: las Pull Requests se acumulan y el modelo artesanal deja de encajar en una “fábrica” industrial de software con agentes. Defiende que los objetivos — transferencia de conocimiento, consistencia y ownership— siguen siendo críticos, pero requieren nuevas infraestructuras. Una lectura muy interesante.

🇬🇧 (9’) Pratik Rasam y Ralph Sylvain, del equipo de Spotify, cuentan cómo dejaron de añadir parches con IA para abordar un problema estructural en Publicidad: la fragmentación de la planificación entre canales. Su solución fue una capa de decisión unificada con arquitectura multiagente que entiende objetivos en lenguaje natural, orquesta APIs como herramientas y genera planes optimizados en segundos a partir de datos históricos. Han conseguido menos complejidad, decisiones coherentes y un giro claro hacia APIs para agentes, testing conductual y observabilidad centrada en el porqué de cada decisión.

🇬🇧 (4’) Aleix Morgadas defiende que la estrategia de ingeniería no puede separarse de su ejecución: dividir “decidir” y “hacer” rompe el feedback loop y fomenta la microgestión o equipos desalineados. Propone apoyarse en equipos ad hoc, formados por las personas adecuadas según el contexto, con autoridad, conocimiento de negocio y comunicación rápida, que diseñen y ejecuten la estrategia de forma conjunta. Un artículo muy interesante para los engineering managers que están planteando su estrategia técnica.

Publicaciones en X

🇪🇸 (4’) Fran Moreno nos cuenta cómo creó hace diez años una extensión de Chrome para Testing Exploratorio con el objetivo de evitar el cambio constante de contexto y mantener todo dentro del navegador. Tras años sin actualizarla, la ha retomado gracias a la IA, añadiendo recortes y anotaciones de capturas, sin perder su filosofía de sencillez y utilidad para la comunidad.

Fran Moreno

Retomando un proyecto personal 10 años después

Hace ya 10 años (2016) empecé a desarrollar una extensión de Chrome para ayudar en las sesiones de Testing Exploratorio. ¿Por qué lo hice? Pues por la misma razón que se crearon 17 frameworks de JavaScript distintos. Ninguna de las herramientas que había disponibles me convencía del todo, así que me hice la mía…

Read more

2 months ago · 8 likes · Fran Moreno

🇬🇧 (8’) Jordi Villar nos comparte en primera persona lo que supusieron más de cuatro años en Tinybird, aprendiendo en profundidad sobre sistemas, ClickHouse e infraestructura de datos en tiempo real. Celebra la cultura de escritura, el “bias for action” y el talento que le rodeó, pero también reconoce el desgaste acumulado por los cambios estratégicos constantes, la rotación de las personas clave y la pérdida de ciertas dinámicas culturales.

🇬🇧 (2’) Simon Willison nos explica por qué el patrón “red/green TDD” encaja especialmente bien con agentes de código: al escribir primero los tests, comprobar que fallan (fase roja) y luego implementar lo necesario hasta que pasan (fase verde), se reduce el riesgo de que el modelo genere código incorrecto o innecesario.

🚀 El ofertón: la oferta de trabajo que más me ha llamado la atención esta semana

Affirm, fintech internacional con un modelo “buy now, pay later” busca un Staff Site Reliability Engineer para liderar la estrategia de fiabilidad, resiliencia e incident management en sus sistemas distribuidos a gran escala. Tendrás impacto transversal, definiendo SLOs, mejorando procesos de despliegue y on-call, elevando el listón de observabilidad y colaborando con equipos de producto e infraestructura, en una organización remote-first con una cultura fuerte de ownership técnico.

¡Me interesa!

💰 €101k–€131k + equity | 📍 🇪🇸 Remoto (España) | 🧑‍💻 SRE, AWS, Kubernetes

🇬🇧 (7’) Andrius Semionovas y Heorhii Popov cuentan cómo, en Vinted, migraron toda su enorme base de código Android a Metro, un framework de inyección de dependencias basado en Kotlin. La transición fue dura, pero les permitió adoptar K2, activar la compilación incremental y reducir notablemente los tiempos de compilación.

🇬🇧 (8’) Danilo Veljovic y Mohit Karekar, del equipo de Zalando, cuentan cómo una conversación informal dio lugar a un guild interno para leer y debatir papers de ingeniería de software centrados en sistemas distribuidos, bases de datos y compiladores. El objetivo es entender mejor las abstracciones que usan a diario. Un año después, el impacto es tangible: una mejor comprensión de herramientas como DynamoDB o Flink, debates técnicos transversales y una cultura de ingeniería más sólida. Me ha parecido, además, un blueprint práctico para que otras empresas implementen iniciativas similares.

Publicaciones en X

(5’) 🇪🇸 Rafa Moral, Engineering Manager en IFCO Systems, reflexiona sobre la “luna de miel” de la IA en Frontend. Todo parece fantástico: más velocidad, más componentes generados en segundos. Pero Rafa nos advierte del riesgo de degradar la arquitectura, la consistencia y la calidad si aceptamos sin criterio lo que propone el modelo: la IA promedia patrones, no diseña y puede introducir divergencias silenciosas en la estructura, el estado o el testing.

Rafa Moral

IA y la tendencia al desastre en Frontend

Estamos en plena luna de miel con la Inteligencia Artificial. No hay día en el que no leamos sobre cómo nuestra productividad se ha disparado, sobre cómo ahora somos “diez veces más rápidos” o sobre cómo alguien ha montado un ERP de zero en dos días y está ganando miles de dólares al mes. Y es verdad, si lo que mides es cuánto tardas en montar una funci…

Read more

2 months ago · 1 like · Rafa Moral

(8’) 🇬🇧 Tanat Lokejaroenlarb cuenta cómo han integrado métricas en su Kubernetes interno (SCHIP) como parte del “golden path”: los equipos solo anotan sus workloads y la plataforma se encarga de recolectar, aislar y enviar métricas de infraestructura y de aplicación a Grafana Cloud, resolviendo retos de multi-tenancy, cardinalidad y alta disponibilidad sin que los desarrolladores gestionen nada de observabilidad.

(7’) 🇬🇧 ¡Tenemos doblete! En este artículo, Galo Navarro, sostiene que la IA rompe el modelo clásico de Kubernetes basado en infraestructura “fungible”: en entrenamiento e inferencia, los reinicios, la latencia y la topología de las GPUs tienen un impacto enorme en el coste y el rendimiento. Como el hardware es caro y heterogéneo, no basta con pedir “una GPU”. Hay que considerar la ubicación, las particiones y las redes. La conclusión es que no se abandona el modelo automatizado, pero sí hay que extenderlo con schedulers y herramientas específicas para gestionar adecuadamente esta complejidad.

🚀 El ofertón: la oferta de trabajo que más me ha llamado la atención esta semana

Zynap, una startup española de ciberseguridad, busca un Senior Python Developer para diseñar y escalar su plataforma core, liderando nuevas funcionalidades y decisiones de arquitectura en un entorno distribuido y orientado a la seguridad, con impacto directo en el producto y con mentoring técnico.

Como bonus, trabajarás con cracks como Daniel Solís (ex-Blueliv, adquirido por Outpost24) y Jordi Miró (ex-The Hotels Network).

¡Me interesa!

💰 40-55k | 📍 🇪🇸 Barcelona (híbrido) | 🧑‍💻 Python, ElasticSearch, Cloud (AWS/GCP)

(22’) 🇬🇧 Matt Shumer, fundador de HyperWriteAI , nos lanza una advertencia directa sobre la velocidad a la que están evolucionando modelos como los de OpenAI y Anthropic: según su experiencia, la IA ya ha pasado de ser una herramienta útil para ejecutar trabajo técnico completo con criterio propio, y el salto en capacidades se está acelerando mes a mes. Matt sostiene que esto tiene implicaciones inmediatas para empleos cualificados, desde derecho hasta finanzas o ingeniería.

(10’) 🇬🇧 Kévin Platel, Global Principal Architect en leboncoin.fr, nos trae novedades muy top. Nos explica cómo pasaron de observar con cautela el auge de los agentes de IA a lanzar una app oficial en la tienda de ChatGPT conectada a sus sistemas reales, equilibrando innovación y responsabilidad en una empresa con millones de usuarios. Me gustó especialmente cómo afrontaron los retos de latencia, seguridad y calidad.

Publicaciones en X

¡Esto es todo por hoy! Si te ha gustado, dale al like. Si quieres seguir recibiendo el mejor contenido tech en español, suscríbete.

— João

El soporte no es solo una función operativa ni un coste inevitable para que todo siga funcionando. Es una herramienta fundamental para construir confianza con quienes usan la plataforma a diario. Confianza en que el sistema es fiable, en que el equipo detrás responde cuando algo falla y en que hay una preocupación real por la experiencia de uso, no solo por la arquitectura o la tecnología de moda.

Esa confianza se construye, en gran parte, estando cerca de los usuarios. El soporte pone al equipo de plataforma en contacto directo con los problemas reales, con los puntos de fricción que no aparecen en los diagramas y con decisiones de diseño que parecían razonables, pero que, en la práctica, generan complejidad innecesaria. Cuando eso ocurre, la conversación deja de ser teórica y pasa a estar anclada en el uso real de la plataforma.

La gestión de incidentes es el ejemplo más evidente. No solo importa cómo se resuelven desde el punto de vista técnico, sino también cómo se comunican, cómo se analizan después y qué acciones se toman para evitar que vuelvan a repetirse. Para los equipos que dependen de la plataforma, esa respuesta define gran parte de la percepción de fiabilidad y madurez del equipo que la mantiene.

Pero el soporte no se limita a los incidentes. También está en el acompañamiento diario, en cómo se responde a una duda, en si alguien siente que hay un equipo al otro lado que escucha y se preocupa. Ese tipo de interacción transmite algo muy potente: que la plataforma existe para servir a los equipos de producto y no al revés.

Y en este punto, siempre suele aparecer la misma conversación dentro de los equipos de ingeniería. No suele pasar en una reunión formal ni en un documento bien estructurado, sino en una charla cualquiera con alguien del equipo. Pongamos que se llama Raúl, nombre ficticio:

Raúl: Vale, pero si nos centramos en soporte, no vamos a desarrollar ninguna feature nueva

João: Eso es cierto si el soporte se convierte en apagar fuegos sin parar

R: Exacto, es justo lo que me preocupa. Que acabemos viviendo en el Help Center

J: Entonces el problema no es el soporte, sino qué hacemos con él. Si solo cerramos tickets, no aprendemos nada

R: ¿Y qué propones? Porque los tickets no se van a resolver solos

J: Que cada ticket sea una señal. Algo que nos dice dónde falta automatización, dónde la documentación no funciona o dónde el producto obliga a hacer cosas a mano

R: Pero eso sigue quitando tiempo

J: A corto plazo, sí. A medio plazo, no. Si usamos ese feedback para eliminar clases enteras de problemas, el volumen de soporte baja

R: ¿Y de verdad pasa eso?

J: Pasa cuando dejamos de ver el soporte como trabajo reactivo y lo usamos para tomar decisiones de producto y plataforma

R: Entonces el objetivo no es hacer más soporte, sino necesitar menos

J: Exacto. Menos tickets y más tiempo para construir las features que realmente hacen la vida más fácil a quienes usan la plataforma

Ahí está, para mí, el punto clave. El soporte no debería competir con el desarrollo de nuevas capacidades. Debería ser uno de los principales factores para decidir qué construir, qué mejorar y qué dejar de hacer.

Cuando se trata de esta forma, ocurre algo casi contraintuitivo. A medida que la plataforma mejora de forma estructural, la carga de soporte disminuye. Y con menos fricción, el equipo gana foco y tiempo para invertir en las mejoras que de verdad aportan valor.

Por eso creo que, en plataformas internas, el soporte no es una distracción del trabajo importante. Es una de las formas más claras de asegurarse de que ese trabajo importa de verdad.

— João

Hola! Antes de seguir con “El doble clic”, quería explicar que el artículo pensado para salir pasado el jueves… no salió. Saldrá en breve. Estoy trabajando en mi consistencia y, a veces, pasan cosas así.

(5’) 🇪🇸 En su artículo semanal, Simon Muñoz escribe sobre el hundimiento del SaaS como síntoma de algo más grave. El mercado ha dejado de creer que estos negocios duren “para siempre”y la IA rompe su valor terminal: si los proveedores de modelos se convierten en la capa donde viven los agentes y los datos, muchos SaaS pasarán de ser infraestructuras imprescindibles a piezas reemplazables, con valoraciones, salarios y ambiciones propias de un sector maduro y en retirada.

Estrategia de Producto

El valor terminal del SaaS es cero

El sector del software ha tenido otra semana horrible en los mercados. Y ya van unas cuantas en 2026, que se suman a un 2025 que, de por sí, ya fue pésimo. Aquello lo contamos apenas hace un mes en El Fin del SaaS 15 meses después…

Read more

2 months ago · 20 likes · 3 comments · Simón Muñoz

(10’) 🇬🇧 Léon Hollender nos explica cómo un bug sutil en las transacciones de la base de datos en Go le llevó a crear un linter a medida. Nos explica, paso a paso, cómo detectar fugas de transacciones mediante análisis estático y defiende la idea de escribir linters propios cuando hay patrones de código fáciles de romper y difíciles de revisar a ojo.

🚀 El ofertón: la oferta de trabajo que más me ha llamado la atención esta semana

Cubbo, una startup de logística y software que ya mueve millones de pedidos para grandes marcas, busca un/a Software Engineer con mentalidad de producto para construir y escalar Cubbo Engage, su nueva capa de agentes de IA para ventas y soporte, trabajando en un squad pequeño con ownership real y foco en el impacto en el cliente.

¡Me interesa!

💰 50-70k | 📍 🇪🇸 Barcelona (60% remoto) | 🧑‍💻 Ruby on Rails, React, SQL, AWS, IA aplicada

(5’) 🇬🇧 Jose Moreno nos habla de cómo usar Skills para dejar de repetir contexto a los agentes de código — instrucciones empaquetadas y reutilizables que se cargan solo cuando hacen falta — y de las ideas básicas para que funcionen bien: buena descripción, alcance pequeño y tratarlas como software, no como prompts largos.

(5’) 🇬🇧 Galo Navarro, Principal Engineer en Midokura, escribe sobre cómo las “pruebas de concepto” crean un sistema de incentivos perversos: ingenieros relajando estándares “porque es solo un PoC” y el negocio empujando a producción algo que nunca debió llegar allí. También defiende que la forma de evitar el desastre no es dejar de experimentar, sino tratar estos trabajos como software real desde el primer día, con los mismos guardrails de calidad y una escala razonable, para no convertir cada demo exitosa en deuda técnica, frustración y fuegos en producción.

(5’) 🇪🇸 Ignacio Arriaga nos explica el batacazo del SaaS como el ajuste de cuentas de una industria que durante años abusó de sus clientes: precios opacos, subidas salvajes y crecimiento a base de exprimir los “asientos” de los usuarios. También defiende que no es el vibe coding quien lo hunde, sino la IA dando por fin una vía de escape: no desaparecerá el software, pero sí caerán los SaaS que confundieron encierro con fidelidad y descubren ahora que los agentes tienen la llave de la celda.

Publicaciones en X

Nos vemos mañana, 10 de febrero. Y también el próximo jueves 12 de febrero, con mi artículo semanal. Recuerda: si te ha gustado la newsletter, dale al “like” y suscríbete.

— João

🇪🇸 (2’) Javi Santana nos cuenta que siempre ha tenido una relación incómoda con llamarse “programador” y repasa cómo empezó automatizando trabajos por pura necesidad, cómo fue pasando por muchos roles técnicos y de liderazgo casi sin buscarlos, y acaba aceptando que probablemente no volverá a programar de forma profesional, porque su aportación real está en otros ámbitos y porque el contexto tecnológico también ha cambiado.

Javi Santana

Programador

Cuando vas al notario, además de sentirte ajeno a todo aquel ritual, te preguntan tu nombre, DNI, estado civil y, por razones que ChatGPT me ha aclarado, tu profesión. Siempre es un momento complicado y responder “programador” me cuesta. Y lo tengo que reconocer, es así porque creo que van a pensar que soy “un cualquiera”. Hay que ser gilipollas, aunque…

Read more

2 months ago · 36 likes · 8 comments · Javi Santana

🇬🇧 (15’) George Wilson, Head of Engineering en Paddle, nos explica cómo pasaron de una libertad total para cada equipo —que al principio aceleró mucho— a un nivel de complejidad que empezó a frenar al negocio, y cómo encontraron el equilibrio creando un “golden path”: un conjunto de librerías, plantillas y herramientas tan bien pensadas que los equipos quieren usarlas sin imponerlas, logrando más consistencia, mejor onboarding y cambios globales rápidos, mientras los ingenieros pueden centrarse en resolver problemas reales y no en debatir arquitectura.

🇪🇸 (5’) Jaime Novoa, de Kfund, escribe sobre cómo Dealflow ha pasado de ser una newsletter escrita totalmente a mano a un proceso en gran parte automatizado con LLMs y Claude Code, manteniendo el criterio humano donde más valor aporta: la selección de noticias y el contexto final. Explica cómo hoy casi todo ocurre entre Terminal y Google Sheets — guardar textos completos, resumir con agentes, clasificar y generar el HTML— y cómo esto le ha permitido ahorrar mucho tiempo y escalar la newsletter.

Nota: recomiendo suscribiros a Dealflow. Es la mejor newsletter sobre la actividad y las noticias de las startups en España.

🚀 El ofertón: la oferta de trabajo que más me ha llamado la atención esta semana

Maisa, una startup española de IA en plena fase de crecimiento tras cerrar una ronda seed de $25M, busca un Site Reliability Engineer para construir y escalar la plataforma que soporta su producto de agentic process automation, con foco en fiabilidad, observabilidad y despliegues enterprise, tanto en la nube como on-prem.

¡Me interesa!

💰 60-75k (+ stock options) | 📍 🇪🇸 Remoto o híbrido desde Valencia | 🧑‍💻 AWS, Kubernetes, Terraform

🇬🇧 (8’) Sinan Tang nos cuenta cómo en ImmoScout24 llevaron a producción su primer servidor MCP para análisis inmobiliario y qué aprendieron por el camino: que construir sistemas con agentes de IA exige patrones muy distintos al software tradicional, desde diseñar herramientas pensadas para agentes (datos estructurados, instrucciones explícitas y ejemplos claros), hasta asumir que el mayor reto no es desarrollar sino evaluar correctamente estos sistemas, y que además hace falta un cambio de mentalidad para experimentar con nuevas interfaces y prototipos rápidos.

🇬🇧 (15’) Desde el blog de Leboncoin, proponen ver el fraude como algo inherente a cualquier marketplace que funciona a escala, no como un fallo puntual, y analizan cómo se manifiesta a lo largo de todo el recorrido del usuario — desde el alta, los anuncios y la mensajería hasta el pago y la posventa —, mostrando que cada decisión de producto define qué es “normal” y cuánto espacio queda para el abuso. La conclusión es clara: el fraude no se elimina con reglas o tecnología aisladas, sino mediante el diseño de experiencias coherentes que reduzcan la ambigüedad, aprendan del mal uso y refuercen la confianza sin castigar al usuario legítimo.

Publicaciones en X

Nos vemos el próximo jueves 5 de febrero, con mi artículo semanal. Recuerda: si te ha gustado la newsletter, dale al “like” y suscríbete.

— João

Por eso llama la atención ver a ingenieros históricamente escépticos como Salvatore Sanfilippo (Redis) o Ryan Dahl (Node.js) reconocer que los LLMs cambian el significado de “construir” en el día a día. Y por eso también es significativo que un CEO como Tobi Lütke (Shopify) esté programando más que nunca. No, no es que crea que el CEO lo vaya a hacer todo él solito. Pero la realidad es que el umbral de entrada ha bajado lo suficiente como para que “hacer una herramienta” vuelva a ser una acción normal, no un proyecto.

La consecuencia de esto es fácil de describir y difícil de gestionar: se va a crear mucho más software dentro de las empresas y no solo desde ingeniería. Prototipos que se convierten en flujos reales. Automatizaciones internas que pasan de “hack” a “esto lo usa todo el equipo”. Integraciones que nacen en una tarde y, de casualidad, se convierten en infraestructura de facto.

Y ahí aparece la pregunta que me interesaba: si crear software deja de ser el cuello de botella, ¿qué pasa con las plataformas?

Me metí en el barro

Durante unos días, actué como si fuera un desarrollador más. La idea era hacerlo yo solo, sin recurrir al pair programming ni al conocimiento tribal. Seguí el onboarding estándar y desplegué un servicio backend de punta a punta, utilizando documentación y plantillas de autoservicio.

No lo hice para evaluar herramientas ni para sacar conclusiones del tipo “esto hay que migrarlo a X”. Lo hice para entender dónde aparece la fricción cuando intentas avanzar con lo que hay, y qué tipo de fricción es la que de verdad te frena.

El camino estándar™ tenía agujeros

Lo básico estaba: crear el repositorio, tener una plantilla, hacer la build, desplegarlo y verlo correr. Había pipelines de integración y despliegue continuos (CI/CD) para compilar, desplegar y ejecutar, así como métricas y logs. Vamos bien, ¿no? Pues no tanto. Cuando todo “más o menos funciona”, es fácil confundir la existencia con la coherencia y la dirección.

Por ejemplo, el soporte estaba repartido entre varios canales de Slack, lo cual no es grave hasta que te obliga a adivinar de antemano quién es responsable de qué. En la práctica, el sistema no te resuelve el problema: te pide que entiendas la organización para poder usarlo. Esto es una forma bastante típica de exportar carga cognitiva. No es que falte soporte. Es que el coste de “saber dónde preguntar” lo paga el usuario. Y ese coste no se ve en ningún dashboard, pero se nota en cada interrupción, en cada pregunta repetida y en cada minuto que inviertes orientándote en vez de avanzar.

Lo mismo me ocurrió con el onboarding. Se asumían demasiadas cosas: qué perfil de Spring Boot seleccionar, qué herramientas tener instaladas y qué configuraciones locales ya debían existir. Y como esas suposiciones no se validaban al principio — en las plantillas de autoservicio —, el sistema me dejaba avanzar hasta que, de repente, no podía. El resultado fue bastante tonto: cinco o seis idas y vueltas con CI que no eran bugs, sino prerrequisitos disfrazados.

Ahí es donde me vino a la cabeza la idea de leaky abstraction. En teoría, tenía una “plantilla estándar”. En teoría, esa abstracción estaba para que yo no tuviera que pensar en lo de siempre. En plan: genero el servicio, sigo el camino estándar y ya está. Pero tenía agujeros. Y cada agujero te empujaba a hacer justo lo contrario de lo que promete una plataforma: bajar de nivel, entender qué hay debajo y probar hasta acertar. Un ejemplo tonto pero real: si no elegías ciertas configuraciones o librerías “por definición”, el sistema no te lo decía pronto ni te guiaba hacia el valor por defecto correcto. Y entonces tocaba investigar, ajustar, volver a probar. En vez de construir, estaba adivinando. Y una plataforma existe precisamente para que no tengas que adivinar.

Hasta aquí, podríamos llamarlo fricción normal. El punto en el que esto se vuelve interesante es cuando aparece la automatización.

¿Qué es una plataforma?

“Plataforma” es una palabra con demasiada carga. En algunas empresas significa “infra”. En otras, es una excusa elegante para decir “el equipo que no entrega funcionalidades”.

A mí me sirve una definición más operativa:

Una plataforma es un conjunto de building blocks y caminos recomendados que permiten que equipos autónomos construyan y operen software sin tener que negociar cada detalle ni aprenderlo todo desde cero.

La palabra clave ahí no es “herramientas”, sino “coherencia”. Es una forma de tomar decisiones por adelantado para que no tengas que tomarlas cada vez. De hecho, si lo pensamos, los productos de plataforma que funcionan suelen compartir el mismo patrón: convierten decisiones repetidas en defaults razonables.

Un ejemplo genérico: imagina que un equipo quiere crear un nuevo servicio. En una empresa sin plataforma, ese equipo tiene que decidir mil cosas: cómo se despliega, cómo se observa, cómo se configura, qué librerías son estándar, cómo se gestionan los secretos, qué implica “listo para producción”. En una empresa con plataforma, gran parte de eso ya está resuelto en forma de plantillas, pipelines, guardrails y estándares ejecutables. No porque alguien quiera controlar, sino porque repetir esas decisiones una y otra vez es caro y, además, genera entropía.

La plataforma, en el fondo, es el mecanismo que permite la autonomía sin fragmentación.

Suscríbete ahora

En un mundo post-IA, automatizar deja de ser el problema

En el flujo de despliegue había varios puntos que pedían automatización a gritos. El ejemplo más obvio era el aprovisionamiento de una base de datos. Es el típico paso mecánico que, en cuanto lo haces dos veces, piensas: “vale, esto debería estar automatizado”.

Lo interesante es que hace unos años, ahí, la conversación solía morir. Automatizarlo bien podía implicar tocar el tooling, mantener scripts, pelearse con los permisos, integrarlo en la CI o empaquetarlo en un CLI. Y si estabas en un equipo de producto, era fácil justificar lo contrario: “esto es una distracción, ya lo haremos cuando duela más”. El coste era suficientemente alto como para que, por definición, la actitud fuera dejarlo manualmente.

Ahora el coste ha bajado muchísimo. No solo por los LLMs, sino también porque construir automatizaciones pequeñas resulta más accesible para más gente. El punto ya no es si alguien puede hacerlo. El tema es saber dónde hacerlo para que sume y no genere una solución paralela.

Y ahí me quedé bloqueado. Me empecé a preguntar: ¿Esto vive en un CLI? ¿En una plantilla? ¿En el pipeline? ¿Qué se considera “el sitio correcto” en esta empresa para automatizar este tipo de tareas? Cuando la respuesta no está clara, el sistema empuja a dos comportamientos muy humanos: o lo dejas manual, o lo automatizas en local “para salir del paso”. Y lo gracioso es que, en un mundo donde automatizar es barato, ambos caminos salen caros. Uno, porque desperdicia capacidad, y el otro, porque fragmenta. Empiezan a aparecer golden paths privados, scripts que funcionan “en mi máquina” y automatizaciones que no encajan con el resto de la plataforma.

En cambio, cuando hay dirección y principios explícitos, el efecto es el contrario. Si el estándar es algo tan concreto como: “los golden paths de aprovisionamiento se construyen con Scaffolder en Backstage”, de repente la empresa entera puede empujar en la misma dirección. No hace falta coordinar a veinte equipos. Hace falta que la regla sea clara, el camino sea fácil y los guardrails estén donde toca.

Ese es, para mí, el cambio grande post-IA: la capacidad de crear automatización se dispara, pero solo se convierte en velocidad real cuando la plataforma ofrece un sitio, un patrón y límites. Ahí es cuando pasas de tener automatizaciones sueltas a contar con una plataforma que acumula automatizaciones, refuerza los defaults y reduce el coste de moverse rápido sin romper cosas.

Las plataformas más importantes que antes, no menos

Durante años hemos hablado de plataformas internas como una inversión para acelerar la ingeniería: reducir el toil, estandarizar buenas prácticas y permitir que los equipos de producto entreguen sin pelearse con la infraestructura. Eso tenía sentido porque el cuello de botella era la escasez de ingeniería y el coste de construcción.

Si ese cuello de botella se debilita, podrías pensar que las plataformas pierden relevancia. Pues no. Es justo lo contrario.

Cuando se va a crear mucho más software, desde muchos más sitios, el problema principal deja de ser la velocidad de un equipo y pasa a ser la coherencia del conjunto. La plataforma se convierte en el mecanismo que hace que un aumento de la capacidad de creación se traduzca en valor y no en un mosaico de automatizaciones incompatibles, decisiones repetidas y deuda organizativa.

¿Cómo cambia el trabajo de los equipos de plataforma?

Aquí es donde creo que muchos equipos de plataforma se van a equivocar por inercia. No nos engañemos. Somos ingenieros y la respuesta fácil es construir más cosas. Más tooling, más features en la plataforma, más abstracciones. Eso tranquiliza porque se parece a lo que siempre hemos hecho: “vemos fricción, construimos una herramienta”.

Pero el trabajo crítico no es “hacer más”. Es hacer que otros puedan hacerlo sin desalinearse. El resultado no es solo software. Es claridad operativa.

• Building blocks sólidos y reutilizables para que la empresa no tenga que reinventar lo básico cada vez.

• Golden paths que no sean “recomendaciones”, sino caminos que el sistema haga naturalmente fáciles, porque ya incluyen los defaults correctos.

• Guardrails ejecutables allí donde de verdad importe la consistencia, porque si algo depende de que la gente lea un documento, en la práctica depende del azar.

• Principios y límites explícitos: qué se automatiza, dónde se ubica esa automatización y qué significa “bien” en ese contexto.

En el fondo, lo que la empresa necesita no es más libertad para crear. Eso ya está llegando. Lo que necesita es un marco en el que esa libertad no genere entropía.

Cerrando el círculo

Sí, al final desplegué el servicio. Pero lo que más me interesaba no era “si se podía”, sino qué hice después de ver dónde estaban los agujeros. Porque ahí es donde, para mí, se decide si esto se queda en una anécdota o se convierte en plataforma. Hice dos cosas:

1. Abrí dos Pull Requests (PRs) para mejorar los guardrails del camino estándar. No eran cambios heroicos. Eran los típicos checks que evitan que el sistema te deje avanzar con una configuración incompleta y estrellarte diez minutos después en CI. Total, hoy puedes ponerte a iterar rápido — sí, incluso con Claude en un tab del terminal — y convertir ambigüedades en defaults ejecutables.

2. Documenté un conjunto de recomendaciones para los equipos que mantienen la plataforma. No en plan “hay que rehacerlo todo”, sino en plan “estos son los sitios donde el sistema está exportando carga cognitiva, y estas son las decisiones que convendría cerrar para que la empresa entera pueda empujar en la misma dirección”.

En resumen: pude desplegar el servicio. También pude abrir dos PRs para mejorar los guardrails del camino estándar. Eso, hoy, es barato. Lo caro es seguir dejando que cada persona pague el coste de orientarse, de probar hasta acertar y de reinventar el estándar en local.

Compartir

Vale… ¿y ahora qué?

Cuando “hacer software” deja de ser una actividad rara y cara, la pregunta deja de ser “¿cómo hacemos para construir más?”. Pasa a ser: “¿cómo hacemos para que lo que se construye no se convierta en un puzzle imposible?”.

En ese mundo, las plataformas no desaparecen. Se convierten en el sitio donde decides qué va a escalar en tu empresa: la capacidad de creación o la complejidad de mantenimiento.

Y lo más frustrante es que no se decide con un gran rediseño ni con una migración épica. Se decide cerrar unas pocas cosas, hacerlas explícitas y convertirlas en caminos y guardrails ejecutables. Lo suficiente como para que automatizar sea barato, sí, pero también acumulativo.

— João

🇪🇸 (8’) En un artículo muy interesante, Alex Vaughtton cuenta su primer año haciendo proyectos reales con IA desde NocodeHackers y cómo eso les obligó a cambiar por completo su forma de trabajar. Explica que la IA ha reducido mucho los tiempos de desarrollo, pero ha hecho más difícil estimar, definir procesos y elegir herramientas, porque todavía no hay buenas prácticas claras. También destaca que ahora el perfil clave no es solo técnico, sino también gente autónoma, con criterio, capaz de tratar con clientes y de dar buen contexto a la IA. La conclusión es bastante directa: la IA acelera mucho, pero no elimina la complejidad, solo la mueve hacia la toma de decisiones, la gestión del proyecto y la responsabilidad sobre lo que se entrega.

🇬🇧 (6’) Dries Buytaert, creador de Drupal, escribió un artículo sobre cómo los agentes de IA empiezan a ser realmente útiles cuando el éxito está muy bien definido desde el principio. A partir de ejemplos llamativos (dejar a una IA programando durante horas mientras uno hace su vida), explica que la clave no es la “magia” del modelo, sino tener criterios claros para saber si algo está bien o mal, normalmente a través de tests. Cuando eso existe, la IA puede iterar sola y avanzar mucho; cuando no, sigue siendo imprescindible el juicio humano. La idea de fondo es potente y bastante intuitiva: el valor del trabajo se está desplazando de la ejecución a la decisión sobre qué significa hacerlo bien.

👋 Hola, soy João. Hoy estreno una pequeña novedad en esta newsletter semanal: una minisección llamada el ofertón. La idea es sencilla: destacar cada semana una oferta de trabajo en una empresa europea que merezca la pena, bien pagada y que construya tecnología interesante.

Nacho González, fundador de InfoJobs, Mailtrack y Hireflix, busca su primer ingeniero full-stack para construir Hirevoice desde cero, con ownership y uso intensivo de IA en el día a día.

¡Me interesa!

💰 60k–80k |📍 Barcelona (3 días en la oficina) | 🧑‍💻 Python/React

🇬🇧 (2’) Aleix Morgadas reflexiona sobre una frase muy común en retrospectivas: “la próxima vez hay que planificar mejor” y cuestiona la idea de que siempre se puede saber todo de antemano. A partir de su experiencia, defiende que el verdadero aprendizaje llega haciendo, avanzando con información imperfecta y aceptando cierta fricción como parte del proceso.

Engineering Strategy

"We just need to plan it better next time"

I heard this sentence multiple times during my career, and sometimes said by myself…

Read more

3 months ago · 2 likes · Aleix Morgadas

🇬🇧 (8’) Chris Gregori plantea que, aunque hoy crear código es más fácil y barato que nunca gracias a la IA, construir software que de verdad funcione, perdure y aporte valor sigue siendo difícil. Describe un cambio claro hacia el “software personal”: herramientas pequeñas, hechas para resolver un problema concreto y a veces pensadas para usarse y tirarse, frente al modelo clásico de SaaS. En ese contexto, la programación deja de ser el cuello de botella y lo importante pasa a ser entender bien el problema, tomar buenas decisiones y asumir la responsabilidad de lo que se construye y ahí la experiencia, el criterio y el gusto siguen siendo insustituibles.

🇬🇧 (30’) Martín García nos cuenta cómo pasar el progreso de un juego de un móvil a otro, sin cuentas ni servidores, le llevó a una odisea de un día entero que terminó revelando algo más profundo. El verdadero límite no era el software, sino la realidad física de cómo se comunican los dispositivos. A través de la prueba y el error, con muchas ideas descartadas, acaba creando una forma ingeniosa de conectar dos teléfonos cara a cara usando solo códigos QR, demostrando que entender bien el problema y cuestionar las “buenas prácticas” pueden abrir la puerta a soluciones.

Publicaciones en X

Nos vemos el próximo jueves 29, con mi artículo semanal. Recuerda: si te ha gustado la newsletter, dale al “like” y suscríbete.

— João

Este artículo es una traducción y adaptación de otros dos que escribí, en inglés:

• “Disasters I’ve seen in a microservices World” (2021)

• “Disasters I’ve seen in a microservices World, part II” (2025)

Hype Driven Development

A principios de la década de 2010, muchas organizaciones estaban desesperadas por mejorar su ciclo de desarrollo. Los equipos con decenas o cientos de ingenieros sufrían entornos pesados, pruebas lentas y despliegues programados. El libro “Continuous Delivery” de Fowler ayudó a poner luz sobre esos problemas y muchos se dieron cuenta de que sus monolitos majestuosos estaban generando cuellos de botella organizativos.

Los microservicios sonaban a solución perfecta: más pequeños, más ágiles, más modernos. Era más fácil empezar con una entrega continua desde cero que intentar introducirla en un monstruo de 200.000 líneas de código.

Así, los equipos comenzaron a dividir sus sistemas en tres, diez o cien microservicios. Casi todos hablaban entre sí usando “JSON sobre HTTP” (otros lo llamaban RESTful 😉). Parecía sencillo y, de repente, podían desplegar en producción en menos de 15 minutos. Se acabó aquello de “el equipo A ha roto la CI y no puedo desplegar”. Pura felicidad.

Hasta que llegó el baño de realidad. Resolver un problema organizativo a nivel de arquitectura también introducía complejidad. Una distinta. Las falacias de los sistemas distribuidos empezaron a hacerse muy reales: latencias, caídas parciales, consistencia eventual, logs imposibles de seguir. Lo que antes era un único sistema estable se convertía en un ecosistema de piezas que fallaban por separado. Y, como no, todas a la vez.

#1 Servicios demasiado pequeños

La posibilidad de crear nuevos servicios cada día desató la creatividad.Una nueva funcionalidad: ¡bam! Un servicio nuevo. En poco tiempo, equipos de 20 personas mantenían 50 microservicios. Uno por cabeza… y algunos sobraban.

Cada servicio tenía su propio ciclo de vida, dependencias, versiones y frameworks. Propagar una actualización de librerías o frameworks era una pesadilla. Peor aún: algunos servicios dependían de que otros se desplegaran a la vez. Y hubo quien incluso escribió microservicios solo para generar CSV. Sí, un network hop para un fichero de texto.

Lo llamamos servicitis: una fiebre que multiplica servicios sin control y hace imposible razonar sobre el sistema. Abrir el IDE ya no bastaba. Había que tener seis proyectos abiertos para entender algo.

#2 Entornos de desarrollo imposibles

¿Quién no ha escuchado esto?

“Oye, necesitamos arreglar los entornos de desarrollo, la gente se está quejando todo el tiempo.”

En sistemas distribuidos, los entornos de desarrollo son una pesadilla cara y frágil:

• ¿Cuánto cuesta levantar 200 servicios en la nube?

• ¿Y mantenerlos sincronizados con producción?

• ¿Qué pasa con los datos de prueba, coherentes entre los servicios?

• ¿Y con las feature flags y las configuraciones por región?

Hacerlo bien requiere una infraestructura de lujo que pocas empresas pueden permitirse. Y hacerlo mal significa frustrar a los equipos día sí, día también.

#3 Los test end-to-end

Antes, con un monolito, bastaba con un entorno de staging y un par de baterías de pruebas de Selenium para dormir tranquilo. Con microservicios, eso murió. Ahora solo puedes afirmar que “una combinación concreta de versiones y configuraciones funciona hoy”. Mañana, quién sabe.

Era muy difícil convencer a la gente de que no podíamos tener más que un par de estas pruebas. Encima, muchos equipos seguían corriéndolas en CI, una vez al día, como si eso sirviera de algo. La realidad es que deberían ejecutarse de forma continua, incluso en producción, como defendía Cindy Sridharan en su mítico artículo “Testing in production, the safe way”.

#4 La gran base de datos compartida

El paso lógico para “romper el monolito sin romper los datos” fue mantener una base de datos común. Parecía lo más fácil: menos carga operativa, consistencia asegurada… hasta que no. ¿Un usuario por servicio? ¿Permisos granulares por tabla? ¿Qué pasa si alguien borra un índice? ¿O si un servicio empieza a escribir donde no debe?

La base de datos compartida se convirtió en un cuello de botella y, muchas veces, en el verdadero monolito escondido. Migrar o desentrelazar todo eso, años después, fue una pesadilla en diferido.

#5 El API Gateway como el nuevo monolito

El API Gateway suele presentarse como una capa “neutral”: autenticar, enrutar y poco más. En la práctica, acaba siendo el lugar donde todo el mundo pone lo que no sabe dónde encajar.

Y llegan las agregaciones específicas para el frontend, las excepciones “temporales” que nunca se van, los versionados ad hoc, etc. Cada equipo empuja un poco porque es más barato hacerlo ahí que tocar su servicio. El resultado no es solo técnico, es organizativo:

• Un equipo central que se convierte en cuello de botella, o un gateway “de todos” que en la práctica no es de nadie

• Cambios que requieren alineamiento transversal, pero sin un responsable claro de aceptar el riesgo

• Un sistema cuyo ritmo de evolución queda limitado por el riesgo percibido de modificar el gateway

Lo que debía ser una capa ligera terminaba convirtiéndose en un cuello de botella crítico. Y, por supuesto, en un único punto de fallo.

#6 El gateway como hotspot operativo

Autenticación, autorización, validación de tokens, multitenancy, rate limiting, traducción de protocolos. Cada request ejecuta lógica cara, a menudo con criptografía, sobre runtimes generalistas y configuraciones por defecto.

Aquí el problema no es el ownership, es la física del sistema:

• thread pools que se agotan

• I/O bloqueante en el peor sitio posible

• Timeouts mal calibrados que provocan fallos en cascada

He visto gateways caer sin un solo bug. Simplemente llegó más tráfico del esperado y nadie había tocado la configuración. El sistema no falló: hizo exactamente lo que le pedimos hasta que ya no pudo más.

Construir gateways fiables no es cuestión de YAML ni de declaraciones de intención. Es entender cómo se comporta el sistema cuando la presión no baja: qué pasa con las colas, dónde se acumulan las esperas y cómo reacciona el runtime cuando todo va justo. Y eso, casi siempre, se descubre demasiado tarde.

#7 Timeouts, reintentos y resiliencia

Los sistemas distribuidos están en estado de fallo parcial constante. Cuando el servicio A no puede comunicarse con el B, la reacción natural es “hagamos un reintento”. Pero ese pequeño gesto te mete en la madriguera del conejo.Aumentar los timeouts, ignorar colas saturadas o malconfigurar los thread pools puede convertir un fallo puntual en un colapso total.

He visto equipos generar sus propias denegaciones de servicio distribuidas (DDoS) desde los móviles de los usuarios porque sus reintentos de conexión no tenían backoff ni jitter. Y sí, todo empezó con “solo vamos a reintentar tres veces”.

Suscríbete ahora

#8 Más servicios que ingenieros

He perdido la cuenta de los equipos con más servicios que personas. Y no me refiero a “un poco más”, sino a cuatro o cinco servicios por ingeniero. Sobre el papel suena bien: “hemos modularizado todo”. En la práctica, significa que cada persona es dueña, operadora y responsable de media docena de sistemas distribuidos.

En gigantes como Google o Uber, con plataformas internas potentes y automatización avanzada, puede funcionar. En el resto del mundo, es un desastre a cámara lenta: cada nuevo servicio añade sobrecarga cognitiva, pipelines, dashboards, alerts, secrets y dependencias. Cuando llega una reorg, esos servicios se quedan huérfanos, corriendo solos en la oscuridad.

#9 El zoo tecnológico

Muchas empresas dicen valorar la autonomía de ingeniería, pero pocas se detienen a definir qué significa en la práctica y qué límites tiene en su contexto. Cuando se ejerce sin fricción ni criterios compartidos, la autonomía no suele traducirse en decisiones explícitas, sino en acumulación: un servicio en Kotlin porque era lo más cómodo en ese momento, otro en Go por rendimiento, otro en Node por rapidez, varias bases de datos distintas y, con el tiempo, sistemas que solo una persona sabe operar con soltura.

No es dejadez ni falta de profesionalidad, sino una consecuencia natural de equipos bienintencionados que optimizan localmente. El problema es que cada stack nuevo añade carga operativa, superficie de ataque y coste de incorporación, y ese coste rara vez es visible al principio.

Suele aparecer más tarde, cuando hay que rotar equipos, integrar a gente nueva o modificar servicios que llevan años funcionando sin tocar. Es entonces cuando esos sistemas, que parecían razonables de forma aislada, se convierten en puntos frágiles del conjunto.

Con el tiempo, muchas organizaciones han empezado a introducir mecanismos de contención como catálogos internos, revisiones de arquitectura o tech radars. No eliminan la entropía, pero ayudan a hacerla visible antes de que se convierta en un problema sistémico.

Compartir

#10 Cuando el organigrama dicta la arquitectura

Relacionado con el anterior, pero aún más perverso: diseñar tu arquitectura en función del organigrama. Imagina la situación: tenemos un equipo de “Pagos” con su namespace en Kubernetes, su stack de Terraform y sus alarmas en su canal de Slack. Todo limpio… hasta la próxima reorg.

Entra un nuevo VP con nuevas ideas y una nueva estructura. De repente, “Pagos” y “Suscripciones” se separan, pero toda la infraestructura sigue compartida. Opciones: compartirlo todo (y crear un infierno de dependencias) o migrarlo todo (un proyecto de seis meses sin valor para el usuario).

Así nace una de las deudas técnicas más costosas: el drift arquitectónico provocado por la evolución organizativa. Y sí, suele triplicar cualquier presupuesto no planificado.

La nueva normalidad

Han pasado más de diez años y muchos de los problemas se repiten. Cambian los frameworks y el tooling, pero no la naturaleza del sistema. Seguimos construyendo sistemas distribuidos y siguen comportándose como tales.

Ahora el foco está en los agentes de IA: componentes con estado, que toman decisiones y se comunican entre sí. El paralelismo es evidente. De nuevo aparecen los mismos puntos ciegos: latencia, consistencia, observabilidad, comportamiento no determinista. El hecho de que el componente “razone” no elimina ninguno de ellos.

El patrón suele ser el mismo: entusiasmo inicial, soluciones creativas para problemas reales y, con el tiempo, una acumulación de complejidad difícil de revertir. No es una cuestión de modas, sino de límites.

Seguiremos aprendiendo, como siempre. Y, como casi siempre, lo haremos después de que los sistemas fallen de formas que ahora mismo parecen obvias.

— João

🇪🇸 (8’) Félix López, VP of Engineering de Technosylva, nos trae una propuesta muy práctica para impulsar la adopción de IA en una empresa grande y regulada: facilitar pruebas rápidas con reglas claras, presupuesto limitado y aprendizaje documentado, y acompañarlo con champions por departamento que acerquen la IA a cada contexto de trabajo. El enfoque se completa con procesos simples para escalar herramientas, visibilidad compartida y un AI Board que vela por que la adopción sea real, útil y sostenible.

🇬🇧 (10’) Alberto Romeu y Pablo Abella, de Tinybird, nos cuentan cómo han creado su propio Wrapped — al estilo de Spotify — para que cada cliente pueda ver un resumen anual de su uso de la plataforma. Explican cómo aprovechan los datos que ya tenían, los integran desde distintas regiones y los presentan de forma rápida, segura y visualmente atractiva, convirtiendo una idea de producto muy reconocible en una funcionalidad real construida en apenas unos días.

🇬🇧 (5’) Fabián Sellés, de Adevinta, explica cómo una actualización de Kubernetes destapó un problema latente en KIAM: unos tokens de servicio que dejaron de renovarse como antes y provocaron fallos intermitentes en pods críticos. Un buen ejemplo de cómo cambios aparentemente menores en la plataforma pueden romper dependencias antiguas y de por qué la deuda técnica en componentes de autenticación e infraestructura acaba pasando factura.

🇬🇧 (4’) Matheus Lima defiende que el crecimiento profesional no siempre llega de la mano de proyectos “estrella” asignados por tu manager, sino de saber transformar tareas normales en oportunidades de mayor impacto. A partir de un ejemplo muy concreto, argumenta que el trabajo con más palanca suele ser visible, ayuda a otros y compone en el tiempo, y que buscar ese tipo de mejoras en tu jornada es una de las formas más efectivas de avanzar en tu carrera.

🇬🇧 (10’) Sergio Visinoni, autor de “Sudo make me a CTO”, propone un enfoque más intencional y realista para planificar el año, alejándose de los propósitos clásicos y apostando por pocos objetivos bien elegidos repartidos entre distintas áreas de la vida, no solo el trabajo. La idea es revisar el año anterior, definir una prioridad clara por ámbito, reducir esos objetivos a hitos trimestrales y respaldarlos con un sistema sencillo de hábitos y revisiones periódicas, de forma que el progreso sea sostenible y no se quede en buenas intenciones.

Sudo Make Me a CTO

Setting your 2026 goals

I do believe in planning, as that’s how we become increasingly intentional with the use of our time…

Read more

3 months ago · 12 likes · Sergio Visinoni

Publicaciones en X

¡Esto es todo! Nos vemos el próximo jueves 22, con mi artículo semanal. Recuerda: si te ha gustado la newsletter, dale al “like” y suscríbete.

— João

Yo ya he dicho lo que pensaba y no ha cuajado. Allá ellos.

Seguramente Cristian lo ha dicho en una reunión, lo ha dejado por escrito en un documento y lo ha explicado en Slack, con contexto y argumentos. Y aun así, el equipo — u otros Staff Engineers, arquitectos, etc. — ha seguido otro camino o no ha hecho nada.

Desde dentro, eso se vive como frustración. Desde fuera, muchas veces, como ruido. La mayoría de los TL no llega a esta situación por dejadez ni por falta de criterio. Llega porque se implica, ve riesgos y siente responsabilidad tanto por el sistema como por el equipo. Precisamente por eso, esta situación duele tanto.

Aquí hay una distinción incómoda que cuesta aceptar: decir lo que piensas no es ejercer el liderazgo técnico.

Ni tener razón, ni advertir riesgos, ni opinar con criterio son suficientes. Y cuando un TL siente que la aguja no se mueve, empieza a compensar. Ahí es donde aparecen los antipatrones: no como fallos evidentes ni como malas intenciones, sino como respuestas razonables a una frustración real que se va acumulando cuando el criterio no consigue mover nada.

Nota: en este punto el plan era hablar de cinco antipatrones. Luego Fabián — Tech Lead y cómplice habitual en estas revisiones — me señaló uno más. Tenía razón y, por lo tanto, esto empieza en el #0. Aprovecho para agradecer su revisión del artículo.

#0 El que no ejerce el rol

Antes de los antipatrones visibles, suele haber otro que lo sea menos. A veces no hay fricción ni conflictos visibles. El equipo entrega, las reuniones se llevan a cabo y las decisiones se toman. Precisamente por eso, este escenario pasa desapercibido durante demasiado tiempo.

El problema no es lo que ocurre hoy, sino lo que no ocurre. Nadie está mirando el sistema en su conjunto. Nadie está empujando una dirección técnica clara. Nadie está convirtiendo las decisiones locales en coherencia global.

Suele pasar cuando el TL anterior se fue y nadie ha ocupado realmente ese espacio. O cuando el ingeniero más senior heredó el título sin que se redefiniera el rol. O en fases de crecimiento rápido, cuando se promociona a quien más produce porque “ya conoce el sistema”.

En el día a día, el TL está presente, pero no ejerce dirección. No empuja principios, no anticipa riesgos y no articula decisiones técnicas que vayan más allá de lo inmediato. No bloquea, pero tampoco desbloquea. No es que decida mal. Simplemente, no decide.

El efecto no es inmediato. Cada ingeniero empieza a optimizar en su parcela. Las decisiones se toman de forma local y el criterio se fragmenta. Y cuando aparece un problema estructural, nadie siente que le corresponda asumirlo.

Esto suele confundirse con la autonomía, pero en realidad es un vacío. El equipo no depende del TL, pero tampoco crece en torno a una dirección compartida. Avanza, pero sin acumular criterio ni velocidad a largo plazo.

#1 El opinador, sin ownership

Hay un momento muy reconocible en el que empieza este antipatrón. Cristian sigue participando en las conversaciones, señalando riesgos y aportando criterio.

Cristian empieza a refugiarse en una idea tranquilizadora: “Yo ya he cumplido con mi parte”. Ha dado su opinión, ha dejado constancia y ha advertido de los riesgos. Si la decisión sale mal, no será por falta de aviso. Ese razonamiento es comprensible, pero peligroso.

A partir de ese punto, Cristian deja de empujar decisiones y se limita a emitir diagnósticos. Su criterio sigue siendo bueno, pero ya no genera movimiento. Está presente en la conversación, pero no en el resultado.

Ese desfase entre cómo Cristian se ve a sí mismo y cómo empieza a percibirse suele aflorar en conversaciones incómodas. A veces, en un 1:1:

João: Oye, ¿cómo ves al equipo últimamente?

Cristian: Bien, más o menos como siempre. Yo ya he dicho lo que pensaba sobre el tema de la latencia y el diseño nuevo. Si luego se decide otra cosa…

J: Ya. El problema es que, desde fuera, da la sensación de que opinas mucho, pero que no estás empujando nada en concreto.

C: ¿Cómo que no empujo? Si llevo semanas avisando de los riesgos.

J: Sí, pero avisar no es lo mismo que liderar una decisión. El equipo sale de las reuniones sabiendo lo que no te convence, pero sin saber qué harías tú distinto ni qué estás dispuesto a priorizar para cambiarlo.

C: … (se le ve enfadado)

J: No te lo digo como reproche. De hecho, tu criterio es bueno. Pero ahora mismo tu opinión no está ayudando a que el equipo decida más rápido. Al contrario, les deja en una especie de tierra de nadie.

Con el tiempo, pasan dos cosas:

1. Por un lado, las decisiones se toman a pesar de Cristian, no con Cristian. Su opinión se escucha, pero pierde peso. Por otro lado, la frustración aumenta, porque siente que su criterio no cambia nada

2. Aquí el rol empieza a degradarse sin que nadie lo haya decidido explícitamente. Al asumir que su responsabilidad termina en la opinión, Cristian reduce su impacto sin darse cuenta. Su criterio deja de ser una palanca y pasa a ser un comentario más

Este suele ser el primer paso. Cuando opinar deja de funcionar, la tentación es compensar de otras formas. Y ahí es donde empieza a aparecer el resto de problemas.

Suscríbete ahora

👋 Hola, soy João. Este es el segundo artículo de una serie pensada para Tech Leads y Engineering Managers que quieren liderar con más claridad e intención:

1. “Señales de un buen Tech Lead”

2. “Soy Tech Lead y no me hacen caso. ¿Qué hago?”

3. “Excelencia Operacional, la palanca del Tech Lead”

4. “Antipatrones de un Tech Lead” ← Este artículo

5. Continuará… ← Suscríbete para no perderlo.

Estoy escribiendo “El Manual del Tech Lead”, cuyo lanzamiento está previsto para la primera mitad de 2026. Las ideas de esta serie serán su base.

Si quieres unirte a la lista de espera, recibirás un 25 % de descuento en el lanzamiento. Ya hay más de 100 Tech Leads y Engineering Managers en la lista de espera.

Unirme a la lista de espera

#2 El TL como cuello de botella

Si opinar deja de funcionar, el siguiente paso parece lógico: hacer. Cristian ya no se limita a señalar problemas y empieza a involucrarse más, a revisar más cosas y a estar en más decisiones. No porque quiera control, sino porque quiere que las cosas salgan bien.

Al principio, funciona. Las decisiones mejoran y los riesgos disminuyen. Los incidentes se reducen. El equipo respira y podría percibirse como un liderazgo efectivo.

Pero hay una trampa. Cada vez más decisiones pasan por Cristian. Cada vez más contexto vive en su cabeza. Cada vez más conversaciones esperan su validación para avanzar. Sin darse cuenta, Cristian se convierte en el punto por el que todo tiene que pasar.

El equipo se adapta rápido y aprende qué decisiones puedes tomar por cuenta propia y cuáles no. Aprende cuándo merece la pena esperar y cuándo no. Y poco a poco, deja de decidir en los márgenes.

Desde la perspectiva de Cristian, el día a día se vuelve agotador. Siempre está ocupado. Siempre hay algo urgente o alguien esperando. Y aun así, la sensación de fondo es que el sistema no acelera.

Aquí está la paradoja: cuanto más intenta Cristian desbloquear al equipo, más lo ralentiza. Las señales suelen aparecer tarde:

• Pull Requests que esperan revisión “cuando Cristian tenga un momento”

• Decisiones técnicas que se posponen porque “hay que comentarlo con él”

• Incidentes que nadie se atreve a cerrar sin su visto bueno

Cuando el TL se convierte en un cuello de botella, el problema deja de ser técnico. Es sistémico. El equipo ha externalizado la toma de decisiones y la organización ha concentrado el riesgo en una sola persona.

Y lo más incómodo: Cristian empieza a ser imprescindible. Y eso, lejos de ser una fortaleza, es una fragilidad. Cuanto más depende el equipo de él para decidir y avanzar, menos tiempo tiene Cristian para realizar trabajo de nivel N+1: mejorar el sistema, reducir la incertidumbre o crear las condiciones para que otros decidan mejor. Su agenda se llena de urgencias y el rol deja de escalar.

#3 El criterio vive en la cabeza del TL

Un día, alguien pregunta: “¿esto está bien hecho?” Y nadie sabe responder sin mirar a Cristian. La revisión se convierte en el centro de gravedad. Pull requests, diseños y detalles de implementación acaban pasando por él. No porque el equipo sea inseguro, sino porque no existe una referencia clara de qué significa “bien hecho” sin su visto bueno.

Cristian revisa con buena intención. Quiere mantener el nivel y evitar errores. Pero el feedback empieza a variar según el contexto, el momento o el cansancio del día. Algo que ayer era aceptable hoy se cuestiona. Lo que en un servicio se tolera, en otro se discute.

El equipo aprende rápido. No hay reglas explícitas. Hay que esperar a ver qué dice Cristian. Y aquí ocurre algo sutil pero muy dañino: la gente deja de pensar en cuál es la mejor solución y empieza a pensar en cuál va a pasar la revisión. Se arriesga menos, se proponen menos alternativas y se pregunta más de la cuenta.

El problema no es que haya estándares. Es que no están escritos ni compartidos. Viven en su cabeza y solo aparecen cuando revisa. Mientras Cristian está, el sistema funciona. Cuando no está, el equipo duda.

🎁 ¿Te suena este punto? No es casualidad.

Muchos de estos antipatrones aparecen cuando el criterio no está explícito y el equipo no tiene una definición compartida de “qué significa hacerlo bien”.

Para ayudar a salir de ahí, he preparado un toolkit de alineación gratuito con herramientas prácticas que ya usan otros equipos:

• Para Tech Leads: un semáforo de autoevaluación para identificar dónde estás aportando valor y dónde te estás convirtiendo, sin quererlo, en un cuello de botella.

• Para Engineering Managers: un semáforo de evaluación para dar feedback basado en comportamientos observables, no en sensaciones.

• Para el equipo: un template de principios operativos para sacar el criterio del TL y dejar de discutir las mismas decisiones cada semana.

Nota: Si ya estás suscrito y has pedido el toolkit anteriormente, lo tienes en el mismo documento.

Quiero el toolkit GRATUITO de alineación TL/EM

Ahí se cierra otra trampa. Cuanto más tiempo dedica a revisar, menos tiene para hacer el trabajo que realmente haría crecer al equipo: aclarar principios, reducir ambigüedades y construir un sistema que funcione sin su presencia constante. La revisión sustituye la claridad.

#4 El héroe

A ver… Cristian no se levanta un día pensando que quiere ser un héroe. Simplemente empieza a notar que hay situaciones en las que su presencia marca la diferencia.

Empieza a darse cuenta de que, en los problemas más complejos, suelen contar con él. Que las decisiones delicadas se esperan a que esté presente. Y que, cuando algo sale bien, a menudo ha pasado por sus manos.

Eso se siente bien. Es la confirmación de que su trabajo importa. En un rol en el que el impacto no siempre es visible, esa sensación pesa más de lo que parece.

Poco a poco, Cristian empieza a apoyarse en ella. Ahora, su identidad profesional se va ligando a estar presente, a ser quien desbloquea, a ser quien “salva” la situación cuando todo se complica. Delegar se vuelve incómodo, no por desconfianza en el equipo, sino porque implica desaparecer un poco del centro de la acción.

Documentar decisiones se va dejando para más adelante. Dar espacio para que otros lideren una iniciativa genera una incomodidad difícil de explicar. No hay una intención clara de acaparar nada. Simplemente, siempre está ahí… por si acaso.

El sistema sigue funcionando, pero empieza a hacerlo alrededor de su figura. Y mientras tanto, el rol de Cristian deja de evolucionar. El siguiente nivel exige justo lo contrario: aceptar que muchas cosas funcionen sin su intervención directa, ceder protagonismo y medir el impacto de otra forma.

Este es el punto en el que el crecimiento se frena, porque todo el trabajo importante pasa por estar presente. Cristian se mantiene ocupado, útil y visible, pero cada vez con menos margen para redefinir su rol.

El problema empieza por confundir el impacto con la presencia. Y cuando eso ocurre, el TL deja de crecer.

#5 Ganar todas las discusiones y perder al equipo

Este antipatrón no empieza con un conflicto ni con una discusión dura. Empieza con una sensación de calma. Las reuniones se vuelven más cortas, las decisiones parecen fluir y las conversaciones se cierran rápido. Cristian expone su punto de vista y, la mayoría de las veces, nadie lo cuestiona. Todo puede incluso parecer alineado y eficiente.

Dentro del equipo, sin embargo, algo ha cambiado. Las alternativas aparecen cada vez menos y las preguntas incómodas casi no se formulan. No porque no existan, sino porque el resultado de la conversación se percibe como previsible. El equipo aprende, de forma implícita, qué merece la pena discutir y qué no. Cristian no es consciente de este cambio. Para él, las cosas simplemente funcionan mejor que antes. La primera vez que lo escucha formulado es en una conversación que no esperaba:

J: Hay algo que me ronda desde hace unas semanas y quería contrastarlo: ¿el equipo habla muy poco, no? Las reuniones son muy tranquilas.

C: ¿Y eso es malo? Al final, ir rápido también es buena señal.

J: A veces sí. El problema es cuando la calma no viene de tenerlo claro, sino de asumir que la discusión ya está cerrada antes de empezar.

[Cristian se muestra confundido]

C: No creo que nadie se esté cortando.

J: No es que se corten. Es que saben cómo va a acabar la conversación. Y cuando eso pasa, la gente deja de traer alternativas.

C: …

J: Tienes muy buen criterio y el equipo lo respeta. Pero ahora mismo da la sensación de que tu punto de vista pesa tanto que ocupa casi todo el espacio.

[Cristian asiente despacio]

J: Cuando el equipo deja de pensar en voz alta, algo se está perdiendo. Y suele pasar sin que nadie se dé cuenta.

El equipo sigue entregando y todo (aparentemente) funciona. Pero ya no piensa en voz alta. La responsabilidad por las decisiones se diluye y la implicación se vuelve más superficial. Se ejecuta bien, pero se cuestiona poco.

Ganar todas las discusiones tiene un precio. Cuando el TL se convierte, aunque sea sin quererlo, en la única voz que importa, el rol deja de cumplir su función. Porque el liderazgo técnico no consiste en tener siempre razón, sino en crear el espacio necesario para que otros también puedan desarrollarla.

Suscríbete ahora

Cuando el TL ocupa demasiado espacio

Al releer estos antipatrones, hay una tentación: pensar que son “errores” y ya está. No lo son. La mayoría aparecen, por el contrario, por implicación, por criterio y por una sensación real de responsabilidad cuando el sistema y el equipo parecen ir hacia un sitio peligroso.

El problema es que cuando un TL siente que su voz no mueve nada, empieza a compensar con el comportamiento. Opina con más fuerza, se mete en todo y revisa más. En resumen: se vuelve imprescindible y, sin quererlo, ocupa tanto espacio que el equipo deja de pensar en voz alta.

Si algo une a todos estos escenarios es esto: el liderazgo técnico no se mide por cuántas veces tuviste razón, sino por cuánto criterio y autonomía gana el equipo a tu alrededor.

Y ahí está la pregunta incómoda que merece la pena hacerse de vez en cuando, sobre todo cuando te descubres diciendo “yo ya lo dije”: ¿estoy ayudando a que el equipo dependa menos de mí o estoy construyendo un sistema que solo funciona cuando yo estoy?

— João

Nota: esta semana sale el cuarto artículo de la serie “Tech Lead”. Puedes repasar la serie en estos enlaces

• “Señales de un buen tech lead”

• “Soy Tech Lead y no me hacen caso. ¿Qué hago?”

• “Excelencia operacional, la palanca del Tech Lead”

🇪🇸 (5’) Pascual Montesinos, de Mercadona Tech, explica, de forma muy clara y práctica, dos maneras de integrar IA en una aplicación — usar un LLM como una pieza más de infraestructura o tratarlo como un actor con autonomía dentro del sistema — y por qué esa decisión cambia por completo cómo diseñas, pruebas y evolucionas tu arquitectura.

🇬🇧 (7’) Doblete de Tanat :) Dos semanas seguidas. Hoy nos cuenta cómo una caída aparentemente absurda — pods que dejaban de arrancar de la noche a la mañana— acabó destapando una configuración frágil que llevaba años “funcionando” por pura tolerancia del sistema externo.

🇬🇧 (33’) Adam Wathan, fundador de Tailwind CSS, comparte en este audio una reflexión muy personal sobre uno de los momentos más duros de su carrera: una crisis financiera prolongada que les ha llevado a despedir a la mayor parte del equipo, replantear el negocio desde cero y asumir que la popularidad del open source ya no garantiza la sostenibilidad.

De mientras, explora una paradoja incómoda: la IA es a la vez una amenaza directa para su modelo de ingresos y una herramienta imprescindible para que el proyecto sobreviva con un equipo mínimo.

Suscríbete ahora

🇪🇸 (8’) Simón Muñoz comparte una experiencia probando Claude Code y concluye que, aunque hoy impresiona al resolver gran parte del trabajo y apunta a un cambio profundo en cómo se construye software, sigue chocando con ese último 10% difícil que separa una demo de algo realmente usable.

Estrategia de Producto

Claude Code y la ilusión del 90%

Si tuviese que elegir un término que ha destacado con fuerza en el sector tecnológico durante el parón navideño, sin duda escogería “Claude Code…

Read more

3 months ago · 21 likes · 10 comments · Simón Muñoz

El autor defiende que lo que desplaza el valor de “escribir código” hacia el criterio, la definición del problema, la validación, la calidad y la distribución. Simón también nos recuerda que en un mundo donde construir es cada vez más fácil, decidir bien qué construir sigue siendo lo verdaderamente escaso.

🇬🇧 (3’) Andrew Graham-Yooll comparte el mejor consejo de promoción que ha recibido: “no esperes el título, empieza a hacer el trabajo” y explica que crecer profesionalmente va de asumir responsabilidades antes de que te las pidan, pensar en los problemas del equipo y traer propuestas con solución, de forma consistente, porque los managers no promocionan momentos brillantes sino patrones sostenidos de comportamiento.

Publicaciones en X

¡Esto es todo! Nos vemos el próximo jueves 15 con otro artículo de la serie de Tech Leads. Recuerda: si te ha gustado la newsletter, dale al “like” y suscríbete.

— João

Nota: debido a la Navidad, las siguientes publicaciones serán:

• El doble clic → hoy y el 12 de enero

• El artículo del jueves, de la serie de los Tech Leads → 15 de enero. Puedes repasar la serie en estos enlaces:

  • “Señales de un buen tech lead”

  • “Soy Tech Lead y no me hacen caso. ¿Qué hago?”

  • “Excelencia operacional, la palanca del Tech Lead”

Para el 2026, he decidido compartir con vosotros mis objetivos y propósitos. Puedes verlos aquí. La consistencia es durísima. Espero estar a la altura.

🇬🇧 (10’) Tanat Lokejaroenlarb, SRE en Adevinta, cuenta cómo Claude Code Action convierte a un asistente de IA en un colaborador activo en el repositorio. No solo revisa código, sino que responde a issues o comentarios, crea ramas, aplica cambios, ejecuta tests y deja todo listo para la revisión humana.

🇬🇧 (12’) Oscar Ligthart y Rodrigo Loredo explican cómo, en Vinted, han conseguido escalar pipelines de datos realmente descentralizados sin que la coordinación entre equipos se convierta en un infierno. El texto cuenta el viaje desde un modelo muy autónomo pero frágil hasta una solución basada en la estandarización.

🇬🇧 (10’) Addy Osmani, director de ingeniería en Google, nos comparte 21 aprendizajes que no van de tecnología, sino de cómo tener impacto real en organizaciones grandes: obsesión por el problema del usuario, claridad por encima de la brillantez, quitar trabajo antes que añadir complejidad y entender que el código no se defiende solo. Un texto fácil de leer, lleno de ideas que resuenan con la experiencia.

Compartir Desde mi terminal

🇬🇧 (5’) Desde Leboncoin, Paul Drappier y Alexis Destrez explican cómo una migración a OpenTelemetry que parecía correcta empezó a perder métricas de forma silenciosa al escalar en producción.

El valor del artículo está en la lección: en observabilidad, pequeños matices pueden llevar a decisiones equivocadas si no se entienden bien, y contar abiertamente estos fallos ayuda a que otros equipos no caigan en la misma trampa.

Suscríbete ahora

🇬🇧 (8’) En el blog de ingeniería de Zalando, Conor Gallagher nos cuenta cómo, al operar streaming de eventos a gran escala, se toparon con un problema silencioso que podía llenar discos y bloquear sistemas sin que nadie lo notara. En lugar de aplicar parches internos, decidieron ir a la raíz y colaborar con la comunidad de Debezium, aportando mejoras que hoy benefician a cualquiera que use replicación lógica con PostgreSQL.

Publicaciones en X

¡Esto es todo! Nos vemos el próximo lunes 12 en “El doble Clic”. Recuerda: si te ha gustado la newsletter, dale al “like” y suscríbete.

— João

Hoy el formato es algo diferente. En lugar de cinco artículos y dos posts de X, traigo:

• Tres artículos/charlas que me han gustado esta semana.

• Mis recomendaciones para este 2025: un artículo, una charla y un blog.

Nota: debido a la Navidad, las siguientes publicaciones serán:

• El doble clic → hoy, 29 de diciembre y 5 de enero de 2026

• El artículo del jueves, de la serie de los Tech Leads → 15 de enero de 2026. Puedes repasar la serie en estos enlaces:

  • “Señales de un buen tech lead”

  • “Soy Tech Lead y no me hacen caso. ¿Qué hago?”

  • “Excelencia operacional, la palanca del Tech Lead”

Para el 2026, he decidido compartir con vosotros mis objetivos y propósitos. Puedes verlos aquí. La consistencia es durísima. Espero estar a la altura.

🇬🇧 (20’) Miguel Carranza, CTO de RevenueCat, nos trae una reflexión muy honesta sobre lo que supone decidir no vender cuando todo invita a hacerlo. Miguel cuenta por qué eligió ir a largo plazo con RevenueCat, cómo intentó tomar esa decisión de manera sostenible a nivel personal y de equipo, y qué ha aprendido sobre contratación, cultura, liderazgo y foco en un contexto de crecimiento acelerado.

Me ha gustado especialmente la ausencia de una épica fácil — hay cansancio, errores y concesiones — y la idea de que construir algo duradero no es romanticismo, sino una elección consciente que hay que volver a validar cada año.

🇪🇸 (15’) Cristian Estarlich, Tech Lead en TennisPoint, escribió un artículo muy práctico que me ha recordado que comunicar bien en ingeniería no es algo “blando”, sino una habilidad crítica que se puede — ¡y se debe! — diseñar. El autor conecta la retórica clásica con el trabajo diario en equipos de software, especialmente en el trabajo remoto, y pone la teoría a prueba con un marco claro: pensar siempre en el propósito, la urgencia, el canal y la audiencia antes de hablar o escribir.

Me ha gustado mucho cómo aterriza esto con situaciones reales — bloqueos con otros equipos, cambios técnicos que afectan al planning, feedback delicado entre compañeros — y cómo insiste en algo que todos hemos sufrido: en remoto, si no queda por escrito, no existe. Una lectura muy recomendable para cualquiera que quiera que los proyectos fluyan menos por heroísmo técnico y más por una comunicación consciente y bien pensada.

🇬🇧 (47’) Solo esta semana he tenido la oportunidad de ver esta auténtica charlaza de Ignasi Marimon-Clos. En ella, defiende que la documentación no es un mal necesario, sino una habilidad que se aprende y se practica con método, y que emplea una narrativa muy bien hilada para explicar cómo escribir mejores docs pensando en quién las va a leer. Me quedo con varias ideas potentes:

1. Documentar también es comunicar. Escribirla antes de programar ayuda a pensar mejor el sistema.

2. Separar claramente tutoriales, guías, explicaciones y referencia evita muchos malentendidos.

La charla desmonta, con ejemplos reales, los argumentos clásicos contra la documentación y deja claro algo que todos hemos vivido: el código dice qué hace algo, pero la documentación explica por qué, cuándo y con qué matices. Muy recomendable si quieres tomarte en serio la documentación como parte del trabajo de ingeniería, no como un extra opcional.

Lo mejor de 2025

Tengo la sensación de que todo el mundo me recomienda demasiadas cosas. Por eso, estas recomendaciones son muy selectivas, pero pensadas. Siempre habrá buenos artículos, charlas y blogs que se quedarán fuera. Si hay valor en algo, muchas veces está precisamente en priorizar y decidir compartir solo una cosa bien elegida, en lugar de muchas sin contexto.

El blog

Simon Willison, creador de Django, tiene hoy en día el que considero el mejor blog sobre inteligencia artificial aplicada a la ingeniería de software. También me gusta toda la panoplia de herramientas que ha creado con “vibe coding”.

La charla

En su última keynote en re:Invent, Werner Vogels, CTO de Amazon, se despide dejando una idea muy clara: la IA no sustituye al ingeniero de software, pero sí obliga a evolucionar hacia lo que él llama el Renaissance Developer.

La charla recorre cómo hemos sobrevivido a cada gran cambio en las herramientas y propone cinco pilares muy bien aterrizados: curiosidad, pensamiento sistémico, comunicación clara frente al “vibe coding”. También habla de ownership y de una mentalidad T-shaped, poniendo el foco en algo que me parece clave: con IA escribiremos menos código, pero tendremos que revisar, entender y responsabilizarnos mucho más del resultado. Es una reflexión madura, nada alarmista, sobre el orgullo profesional, los mecanismos frente a buenas intenciones y la excelencia operativa como seña de identidad del buen ingeniero. Muy recomendable para empezar el año 2026 con una perspectiva sobre la IA y el desarrollo de software.

Compartir

El artículo

Sam Rose alía la escritura con excelentes visualizaciones interactivas para explicarnos la notación Big O. No es nada revolucionario, pero sí un artículo claro. También nos explica qué implica cachear resultados o por qué el peor caso importa más de lo que creemos. Me gusta especialmente que insista en que Big O no habla de tiempos absolutos, sino de crecimiento, y que no hay atajos mágicos sin trade-offs.

Un recurso muy recomendable si quieres afinar el criterio técnico y escribir código más consciente, o repasar tus clases de algoritmos y estructuras de datos de la universidad.

Suscríbete ahora

¡Hasta aquí hemos llegado! Espero que disfrutes de estos artículos, charlas y blogs recomendados, tanto como yo disfruto de leerlos y de curar contenido semanalmente.

Nos vemos el próximo lunes para la primera edición de 2026 de “El doble Clic”. Recuerda: si te ha gustado la newsletter, dale al “like” y suscríbete.

— João

Nota: debido a la Navidad, haré una pausa en los artículos largos. Esta sección (“El doble clic”) seguirá activa. Las siguientes publicaciones serán:

• El doble clic → 22 y 29 de diciembre, y 5 de enero de 2026

• El artículo del jueves, de la serie de los Tech Leads → 8 de enero de 2026. Puedes repasar la serie en estos enlaces:

  • “Señales de un buen tech lead”

  • “Soy Tech Lead y no me hacen caso. ¿Qué hago?”

  • “Excelencia operacional, la palanca del Tech Lead”

🇬🇧 (38’) Jorge Manrubia, Principal Engineer en 37Signals (Basecamp, HEY, etc.), nos trae un vídeo en el que nos hace un deep dive en el código de Fizzy, su nuevo producto.

Jorge defiende mantener la lógica de negocio dentro de los modelos — criticando el abuso de los Service Objects y los modelos anémicos — y usar Concerns para organizar comportamientos y reutilizar código sin perder claridad. Todo ello, combinado con clases bien nombradas y callbacks usados con criterio, para reducir la complejidad, mantener el código expresivo y hacer que la arquitectura refleje directamente el problema de negocio.

🇬🇧 (5’) Alex Ferrer, de ManoMano, nos trae un artículo en el que explica cómo han creado un middleware para gestionar tokens, evitar cierres de sesión y mejorar su solución de autenticación para la app móvil.

🇬🇧 (2’) Aleix Morgadas nos trae una reflexión sobre la estrategia de ingeniería, que suele entenderse de forma demasiado limitada — centrada solo en la tecnología y en lo que el equipo cree que controla— cuando, en realidad, su impacto va mucho más allá. Afrontar retos de negocio relevantes exige pensar también en organización, contratación, colaboración con producto y diseño, e incluso en aspectos legales, y usar la estrategia como palanca de influencia para cuestionar y relajar restricciones. A partir de ahí, el verdadero trabajo del estratega es colaborar, alinear y decidir, incluso cuando la mejor solución no es técnica.

🇬🇧 (6’) Eldred nos explica cómo ha migrado sus repos de GitHub a Codeberg debido a su desacuerdo con el rumbo de la plataforma — la presión por productos de IA y las decisiones éticas cuestionables — y describe el proceso. Cómo mover repos sin romper issues ni Pull Requests, actualizar todos los enlaces y los remotos, portar el CI y mucho más.

🇬🇧 (2’) Jorge Cortés, de Cabify, nos introduce en el concepto de “experiencias degradadas” (degraded experiences): situaciones en las que los sistemas “funcionan” y cumplen los SLOs, pero lo hacen a costa de un mayor gasto o de una peor experiencia de usuario mediante fallbacks invisibles.

El problema es que la monitorización tradicional suele ignorarlas, lo que hace que estas degradaciones se vuelvan permanentes y ocultas. La propuesta, ejemplificada con el enfoque de Cabify, es tratarlas como ciudadanas de primera clase desde el diseño: definir degradaciones explícitas, instrumentarlas con métricas y alertas propias y darles visibilidad continua.

Publicaciones en X

¡Esto es todo! Nos vemos el próximo lunes, con una edición especial de “El doble Clic”. Recuerda: si te ha gustado la newsletter, dale al “like” y suscríbete. ¡Ya sabes cómo funcionan los algoritmos de estas plataformas!

— João

Me gusta tu artículo, pero no hablas de KPIs, SLOs…

Este fue parte del feedback de Fabián sobre el primer artículo de la serie de Tech Leads (TL). Y tenía razón. Faltaba la pregunta incómoda: ¿cómo sabemos si vamos bien?

Si eres Tech Lead, en algún momento te van a pedir “más velocidad”. Más features, más proyectos, más impacto. Y tú vas a ver, en paralelo, más incidencias, más ruido de alertas, más incertidumbre, más tiempo perdido en investigar cosas que “no deberían pasar”.

Puedes tener buen criterio e impulsar estándares de calidad. Pero si no puedes medir el estado del sistema ni el coste real de operarlo, operas a ciegas. Y cuando operas a ciegas, todo acaba en discusiones eternas: “yo creo que está bien”, “yo creo que no”, “esto siempre ha sido así”. Para mí, eso es exactamente lo que evita la excelencia operacional.

La excelencia operacional es la capacidad del equipo para entregar valor de forma sostenida, sin degradar la confianza del usuario, sin quemar al equipo y sin que cada incidente reinicie el contador. Es una disciplina, no un proyecto.

Tres tipos de métricas, tres intenciones distintas

Lo primero es separar por intención. Si mezclas intenciones, acabarás con dashboards bonitos y cero decisiones.

1) KPIs

Empecemos separando conceptos. Los Key Performance Indicators (KPIs) no son solo métricas de negocio. Hay KPIs de negocio — conversión, retención, ingresos, adopción — y KPIs internos de equipo (lead time, frecuencia de despliegue, volumen de incidentes, coste por petición, ruido de la guardia). Ambos importan, pero responden a preguntas distintas.

• Los KPIs de negocio indican si la organización está obteniendo valor.

• Los KPIs internos indican a qué costes operativos y humanos se asocia ese valor.

Un Tech Lead opera principalmente en este segundo plano. No porque ignore el negocio, sino porque su palanca es hacer que el sistema técnico sea sostenible mientras el negocio crece.

2) SLIs: “¿cómo se comporta el sistema?”

Un SLI (Service Level Indicator) es una medida observable del comportamiento de tu servicio. Ejemplos típicos:

• Disponibilidad (peticiones correctas vs. total).

• Latencia (p50, p95, p99).

• Tasa de errores (por tipo, por endpoint, por causa).

• Frescura de datos (si hay colas, procesos en batch, replicación).

• Saturación (CPU, memoria, pool de conexiones, cola, límites de peticiones).

Los SLIs describen la realidad. No te dicen si esa realidad es aceptable.

3) SLOs: “¿qué significa ‘suficientemente bueno’ para el usuario?”

Un SLO (Service Level Objective) es un objetivo explícito sobre un SLI en una ventana de tiempo. Ejemplo:

En 30 días, el 99,9 % de las peticiones del flujo de checkout deben completarse correctamente en menos de 300 milissegundos.

Los SLOs son una forma de contrato. No legal. Operativo. Un “esto es lo que garantizamos como equipo”. Una parte importante: los SLOs no son binarios. No se trata de “cumples o fallas”. Aquí entra el concepto clave: el “presupuesto de errores” (error budget).

Si tu SLO es del 99,9 %, estás aceptando explícitamente que el 0,1 % de las peticiones puede fallar o tardar dentro de esa ventana. Es un fallo permitido por el diseño, no un accidente. Mientras el consumo de ese “presupuesto” esté bajo control, el sistema está “dentro de SLO”, aunque haya incidentes. Un incidente no significa automáticamente que estés fuera de budget.

Una buena herramienta de negociación

En mi experiencia, la mayoría de las fricciones entre TL, Engineering Manager (EM) y Product Manager (PM) nacen de lo mismo: no hay una definición compartida de “bueno”:

Las tres son legítimas. El problema es que si no hay un mecanismo, la discusión se convierte en política. Los SLO y los error budgets forman parte de ese mecanismo. Si el consumo es bajo, el equipo tiene margen para asumir riesgos, implementar cambios y impulsar nuevas funcionalidades. Si el error budget se quema rápido, es una señal clara de que hay que parar, estabilizar y pagar deuda.

Desde la perspectiva del Tech Lead, los SLOs y el presupuesto de errores son una de las palancas más potentes para negociar velocidad, alcance y calidad sin recurrir a opiniones ni a la jerarquía.

Esto no elimina las conversaciones difíciles, pero sí les da un poco de orden.

No es hacer más ops, es reducir incertidumbre

Aquí viene la parte importante para un Tech Lead: la excelencia operacional no es “ser SRE” ni “vivir en Grafana”. Es diseñar un sistema operativo para el equipo que minimice la incertidumbre.

Un TL lidera excelencia operacional cuando consigue que:

• Detectar problemas sea rápido.

• Diagnosticar sea menos artesanal.

• Mitigar sea repetible.

• Aprender sea real (no un incident review que nadie ejecuta).

• La carga de on-call sea sostenible.

• Los trade-offs se deciden con datos.

Suscríbete ahora

👋 Hola, soy João. Este es el segundo artículo de una serie pensada para Tech Leads y Engineering Managers que quieren liderar con más claridad e intención:

1. “Señales de un buen Tech Lead”

2. “Soy Tech Lead y no me hacen caso. ¿Qué hago?”

3. “Excelencia Operacional, la palanca del Tech Lead”. ← Este artículo

4. “Antipatrones de un Tech Lead” ← enero de 2026. Suscríbete para no perderlo.

5. Continuará…

Estoy escribiendo “El Manual del Tech Lead”, cuyo lanzamiento está previsto para la primera mitad de 2026. Las ideas de esta serie serán su base.

Si quieres unirte a la lista de espera, recibirás un 25 % de descuento en el lanzamiento.

Unirme a la lista de espera

¿Qué debe liderar? ¿Qué debe influir?

Aquí conviene ser nítido, porque si no, el TL intenta abarcarlo todo y se convierte en un cuello de botella.

El TL debería liderar

• Definición de SLIs y SLOs que representen la experiencia de usuario, no de métricas de vanidad.

• Filosofía de alertas: alertar por síntomas visibles para el usuario, no por causas internas del sistema.

• Instrumentación mínima: logs, trazas, métricas y estándares de diagnóstico.

• Higiene en la gestión de incidentes: runbooks claros, alertas con contexto e incident reviews estructuradas.

• Cadencias: revisión periódica de los SLOs y de las acciones.

El TL debería influir

• Política de error budget y cómo afecta al roadmap (con PM/EM).

• Priorización: cuánto tiempo se dedica a la fiabilidad vs. a las nuevas funcionalidades (con EM/PM).

• Definición de KPIs técnicamente medibles y no “deseos” (con PM).

• Inversión en herramientas (con EM y el equipo de plataforma correspondiente, si corresponde).

El TL no debería cargar solo

• Gestión de rotaciones y límites de guardias (EM).

• Comunicación externa, decisiones sobre el roadmap y la narrativa de producto (PM).

• Acuerdos transversales a toda la organización, negociación política con stakeholders de otros equipos (EM/PM, según contexto).

El TL participa en todo. Pero no “posee” todo.

Diferentes tipos de equipo, el mismo rol

Hasta ahora he hablado de KPIs, SLIs y SLOs de forma relativamente abstracta. En la práctica, su diseño depende en gran medida del tipo de equipo en el que estés. Más concretamente: ¿dónde está el centro de gravedad del equipo?

No suele haber equipos “puros”. La mayoría opera en un punto intermedio. De hecho, si usas el marco de Team Topologies, lo que suele cambiar no es tanto el tipo de equipo, sino su centro de gravedad: algunos equipos están más orientados a construir y operar plataformas y otros a entregar valor directo al producto. El marco es el mismo. Lo que cambia es el foco.

Equipos de Plataforma

En equipos de Plataforma — infraestructura en la nube, componentes compartidos, servicios multi-tenant — , tu usuario principal suele ser otro equipo. Eso cambia cómo defines “bueno”.

Empezando por SLIs y SLOs. Un SLI agregado a nivel global suele ocultar problemas reales. Necesitas visibilidad por tenant, por clúster o por una partición lógica del sistema.

Además, el soporte forma parte explícitamente del servicio. El tiempo de primera respuesta o de resolución puede ser SLO perfectamente legítimo. Lo mismo ocurre con la documentación y el self-serve: reducen los tickets, las interrupciones y la incertidumbre. También forman parte de la fiabilidad.

En este contexto, los KPIs que más palanca le dan a un TL suelen ser internos y operativos:

• Número de equipos o integraciones activas.

• Volumen de tickets y capacidad de deflexión (cuánto se resuelve sin intervención humana).

• Coste unitario: por petición, por tenant o por operación clave.

• Ruido operativo: incidencias recurrentes, alertas, carga de guardias.

Estos KPIs no miden directamente el éxito de negocio. Miden si la plataforma es escalable y sostenible a medida que la organización crece.

Antipatrón habitual

Optimizar la estabilidad y el coste sin una señal clara de adopción ni de valor real para los equipos usuarios. El sistema funciona, pero nadie lo usa. La excelencia operacional sin impacto también es deuda.

Equipos de Producto

En equipos de Producto — que lanzan y mantienen funcionalidades orientadas al usuario final —, el foco se desplaza hacia la experiencia de ese usuario.

Aquí, los SLOs (p.ej., disponibilidad) no deberían definirse por servicios o endpoints, sino por flujos críticos: buscar, pagar, publicar, reservar. La latencia media importa poco si el paso clave del funnel es lento o falla. La corrección también se define a nivel de negocio. Un HTTP 200 no sirve de mucho si el resultado es incorrecto.

Esto no significa que en los equipos de Producto no existan KPIs internos. Los hay, y son igual de importantes. Desde la perspectiva del TL, conviven aquí dos planos.

Por un lado, KPIs internos operativos:

• Número y severidad de incidencias.

• Ruido de alertas y de carga de guardias.

• Lead time, frecuencia de despliegue y fallos en producción. (ej. métricas DORA )

• Coste operativo por petición o por usuario.

Por otro, señales técnicas muy cercanas al producto:

• Sesiones sin crashes.

• Rendimiento por dispositivo, versión o segmento.

• Errores funcionales que no generan fallos técnicos evidentes.

Estos KPIs internos no sustituyen a los KPIs de negocio, pero los condicionan. Si el sistema es lento, inestable o caro de operar, la conversión, la retención y los experimentos acaban degradándose, aunque al principio no lo sea.

Aquí conviene ser explícito sobre los límites del rol: el PM persigue el resultado. El TL garantiza que el sistema puede perseguirlo sin que se rompa.

Antipatrón habitual

Optimizar la conversión y la experimentación mientras los KPIs internos se degradan. Al principio todo parece ir bien. Luego la velocidad cae en picado y cada cambio cuesta el doble.

El punto común

Independientemente del centro de gravedad, el trabajo del Tech Lead es el mismo: definir qué significa “bueno”, medirlo con honestidad y convertir esas señales en decisiones.

Lo que cambia no es el rol del TL, sino el lugar donde la excelencia operacional genera un mayor impacto.

Un sistema simple que funciona

La mayoría de los equipos no falla por falta de métricas. Falla porque esas métricas no cambian ninguna decisión. No porque no tenga métricas, sino porque no consigue que influyan en el trabajo real del equipo. La clave no es la herramienta ni el nivel de sofisticación, sino cerrar el ciclo: medir, decidir y actuar.

En la práctica, los equipos que lo hacen bien comparten un patrón común: pocos indicadores bien elegidos, objetivos explícitos y una cadencia regular para convertir señales en decisiones. Normalmente esto implica:

• Un conjunto reducido de SLIs que representen el comportamiento real del sistema.

• Uno o dos SLOs por flujo crítico.

• Alertas que indiquen cuándo el sistema de verdad se está degradando.

• Una regla clara sobre qué hacer cuando eso ocurre.

• Revisiones periódicas que se traduzcan en acciones concretas.

🎁 ¿Quieres aterrizar esto en tu equipo?

A lo largo del artículo he hablado de KPIs, SLIs y SLOs, y de cómo usarlos para tomar mejores decisiones. Pero la diferencia no está en entender los conceptos, sino en ponerlos a trabajar en el día a día del equipo. Para eso he preparado dos plantillas prácticas que uso con los equipos:

• Definir KPIs, SLIs y SLOs y dejar claro qué significa “bueno” en tu contexto.

• Revisión mensual para convertir esas métricas en decisiones reales, no en dashboards.

No son frameworks teóricos ni recetas universales. Son artefactos simples para cerrar el ciclo: medir, decidir y actuar.

Suscríbete y rellena este formulario para que te los envíe. Gratis.

Descargar guía de SLIs, SLOs y revisión mensual

Nota: si ya has pedido acceso al toolkit de alineación EM/TL, no es algo nuevo que tengas que descargar. Los templates de KPIs, SLIs y SLOs, y la revisión mensual forman parte del mismo documento que ya tienes: el toolkit con el semáforo de autoevaluación, que acompaña al plan de 90 días para Tech Leads.

La excelencia operacional es cómo compras velocidad

Volviendo a lo que contaba en mytaxi, aprendí algo bastante simple: tener razón no sirve de mucho si no puedes mover al equipo. Y mover al equipo no consiste en explicar mejor las cosas, sino en cambiar el marco en el que se toman las decisiones.

Cuando trabajas con SLIs, SLOs y KPIs bien definidos, dejas de pedir fe y de discutir sensaciones. Empiezas a operar con un sistema que hace visibles los trade-offs y facilita la toma de decisiones.

Ese es, para mí, uno de los mayores aportes de un Tech Lead: convertir conversaciones difusas en decisiones repetibles y decisiones repetibles en una velocidad que se puede sostener.

Porque el objetivo nunca fue tener menos incidentes por orgullo técnico. El objetivo es entregar valor de forma constante, sin quemar al equipo y sin vivir con la sensación de que cualquier lunes a las nueve de la mañana puede estallar todo.

— João

Nota: debido a la Navidad, haré una pausa en los artículos largos. Esta sección (“El doble clic”) seguirá activa. Las siguientes publicaciones serán:

• El doble clic → 22 y 29 de diciembre, y 5 de enero de 2026

• El artículo del jueves, de la serie de los Tech Leads → 8 de enero de 2026. Puedes repasar la serie en estos enlaces:

  • “Señales de un buen tech lead”

  • “Soy Tech Lead y no me hacen caso. ¿Qué hago?”

Lo mejor de la semana

🇪🇸 (5’) Jero nos ofrece una introducción práctica sobre cómo extender Spring Batch para trabajar directamente con ficheros Parquet. El artículo explica por qué este formato columnar encaja mejor con las arquitecturas modernas de Data Lake y cómo Carpet facilita integrarlo en procesos batch en Java sin recurrir a otros stacks.

🇪🇸 (6’) Un repaso muy personal del año de Javier Santana. Mezcla de lecturas, frases que se le han quedado grabadas y momentos tanto profesionales como emocionales. Destaca aprendizajes sobre liderazgo y energía (Snowflake), el equilibrio entre trabajo remoto y eficacia (Vercel), la trampa de trabajar mucho sin preguntarse si es lo correcto (Jason Fried) y la idea de que no se puede competir con quien disfruta de lo que hace.

🇬🇧 (5’) Bojan y Alessandro, de Subito, cuentan cómo han incorporado la accesibilidad en su pipeline de tests usando Playwright y Axe: una combinación ligera que aprovecha su batería de tests E2E existente para detectar problemas básicos en páginas críticas y generar informes en cada despliegue.

🇬🇧 (5’) Pablo Santos nos trae un nuevo artículo que sostiene que, con cada vez más código generado por asistentes de IA, los sistemas de control de versiones deben registrar no solo qué cambió y quién lo cambió, sino también si lo produjo una IA y bajo qué prompt o intención.

Esa procedencia (provenance en inglés) enriquecería el annotate/blame, facilitaría el cumplimiento normativo, permitiría regenerar código a partir de la intención original con modelos más recientes y convertiría el historial de commits en una base de conocimiento consultable vía RAG.

🇪🇸 (1h 10’) Os dejo una conversación amplia con Julio César Pérez sobre qué define una buena cultura de ingeniería: tratar a los ingenieros como solucionadores de problemas, cuidar a las personas y apostar por la mejora continua. Defiende la motivación basada en el propósito, la autonomía y la maestría. Julio critica el “clasismo” que minusvalora a quienes provienen de consultoras y propone una calidad “suficiente” según el contexto del negocio.

Habla también de liderazgo realista — entre las presiones del negocio y las necesidades del equipo —, de procesos de selección más humanos y eficaces, y del valor que aportan los juniors incluso en plena era de la IA. Su receta es resolver problemas reales, avanzar en pequeños pasos y no esperar permiso para mejorar las cosas.

Publicaciones en X

¡Esto es todo! Nos vemos el jueves, con el tercer artículo de la serie de Tech Leads y la semana que viene. Recuerda: si te ha gustado la newsletter, dale al “like” y suscríbete. ¡Ya sabes cómo funcionan los algoritmos de estas plataformas!

— João

Ese rol tenía un doble componente:

1. Liderazgo técnico de backend (TL) mediante buenas prácticas y con énfasis en la mejora continua. En esa época, mytaxi crecía bastante en tráfico. Algunos de sus servicios — por ejemplo, el que se usaba para incentivar a los conductores a hacer más carreras — presentaban picos de tráfico significativos y requerían mejoras, rearquitecturas, etc. Por otro lado, había unos 200 y pocos servicios que gestionar, en total.

2. Gestión de personas, de forma horizontal. La idea era que los backends reportaran todos a mí o a Ariel — el otro Chapter Lead —, independientemente del equipo. No es un set-up muy ortodoxo, pero en esa época entraban quizá 3-5 backends cada mes y había la necesidad de hacer que esta gente se volviese productiva lo más rápido posible, alinear la arquitectura y el producto no paraba!

Yo venía sin ningún tipo de experiencia previa (formal) como Tech Lead y creo que nunca leí tanto en mi vida como ese mes en que anuncié que dejaba mi trabajo anterior y entraba en mytaxi. No solo eso, sino que nunca había tenido un TL de verdad del que aprender. ¿Qué podría salir mal?

El primer día fue muy divertido. Entro a Slack y me presento al manager de infraestructura/plataforma. Y me dice:

Oye, por cierto, tenéis un incidente en el servicio X. Lo podrías mirar?

Así, en frío. Son las nueve de la mañana de un lunes y tenemos un incidente. ¡Que no sé ni dónde están los logs, Henning! Pasado ese susto inicial, soy capaz de dar con el equipo responsable, que identifica el problema, lo soluciona y todo queda arreglado.

Esta primera interacción me hace ver varias cosas:

1. Ninguno sabe gestionar incidentes, documentar los problemas encontrados ni comunicar el avance. ¡Empezamos bien!

2. No hay cultura de hacer una “retrospectiva” (incident review) ni de sacar acciones que eviten ese tipo de incidentes en el futuro

3. Hay cierto acoplamiento entre dominios. En este caso, se utilizaba el concepto de Impuesto sobre el Valor Agregado (IVA) para dos casos de uso totalmente distintos. Y un cambio en uno de ellos provocó el incidente en el otro.

4. Mucha gente no sabe depurar (debugging). Me miran como si los logs hablaran conmigo o si fuera Harry Potter.

La parte buena es que había, claramente, mucho que arreglar. Yo tenía bastante claro cómo se podría mejorar la cultura de ingeniería. Encima, tenía el título de Tech Lead. ¡Estaba chupado! O no…

👋 Hola, soy João. Este es el segundo artículo de una serie pensada para Tech Leads y Engineering Managers que quieren liderar con más claridad e intención:

1. “Señales de un buen tech lead”

2. “Soy Tech Lead y no me hacen caso. ¿Qué hago?” ← Este artículo

3. “KPIs, SLOs y excelencia operacional”. Próximamente. Suscríbete para no perderlo

4. Continuará…

Estoy escribiendo “El Manual del Tech Lead”, cuyo lanzamiento está previsto para la primera mitad de 2026. Las ideas de esta serie serán su base.

Si quieres unirte a la lista de espera, recibirás un 25 % de descuento en el lanzamiento.

Unirme a la lista de espera

La confianza

Después de ese incidente, creé un documento de incident review y sugerí una pequeña revisión de las tareas que deberían priorizarse para evitar que se repitiera. Me vine arriba y creé una primera presentación para los demás Chapter Leads de backend con una estrategia para el backend. Ya no me acuerdo al 100%, pero había arquitectura hexagonal, una pirámide de pruebas (tests) que incluía tests de contrato para no romper las APIs que usaban las aplicaciones móviles, y más. Pasan los días y pienso:

Mierda, nadie me hace caso. ¡Sí, me he currado un montón las diapositivas y la estrategia!

La razón, hoy en día, me parece obvia: los títulos no confieren influencia. Para influir, es necesario generar confianza. Y yo aún no me la había ganado lo suficiente como para proponer algo tan fundamental. Ya sea a través de mi propia experiencia o de sesiones de coaching, este error lo he visto clavado en varias otras ocasiones a lo largo de mi carrera.

Años más tarde descubrí la célebre ecuación de la confianza de Maister, Green y Galford. Me habría venido de maravilla en aquella época. Dice lo siguiente:

La primera vez que la leí, me explotó la cabeza porque describía exactamente lo que me estaba pasando. Vamos a desglosarla:

• Credibilidad: saber de lo que hablas. Tener criterio técnico. Que cuando dices algo, la gente sienta que está bien fundamentado. En 2018 quizá tenía parte de esta credibilidad, pero aún no estaba demostrada en ese contexto, con esa gente, con esos sistemas. Venía de fuera. Y la credibilidad importada siempre vale menos — a menos que vengas de una FAANG o te hayas construido una marca personal — que la credibilidad ganada en el terreno.

• Fiabilidad: cumplir lo que dices. Ser constante. Estar cuando toque. En un entorno de alto ritmo como el de mytaxi, esto pesa muchísimo. En esos primeros días yo aún estaba aprendiendo dónde estaban los logs. Es difícil demostrar fiabilidad si ni siquiera controlo el mapa.

• Intimidad: que la gente sienta que puede hablar contigo, que no la vas a dejar vendida y que entiendes sus miedos y dudas. Esto, para un TL, es más importante de lo que parece. Sin esta parte, cualquier propuesta técnica se percibe como un juicio. Y cuando las personas se ponen a la defensiva, todo se frena.

• Y luego está el denominador: la autoorientación. Cuando tus propuestas parecen responder más a tu agenda que a las necesidades del equipo, la confianza se derrumba. Ese fue mi error. Llegar con una estrategia demasiado pronto, sin haber escuchado, sin haber visto qué necesitaban ellos, sin haberme ganado aún el derecho moral a plantearla.

En otras palabras: aunque mis ideas no fuesen malas, la ecuación no me salía. Tenía algo de credibilidad, un poco de fiabilidad para construir, intimidad aún por crear y demasiada autoorientación. El resultado era obvio: poca confianza.

Dos momentos clave

Con el tiempo me di cuenta de que la confianza no se construye con grandes discursos, sino con acciones concretas que resuelven problemas reales del día a día. Mirando atrás, hubo dos momentos muy claros que aceleraron ese cambio en cómo el equipo me percibía.

Complejidad regulatoria

Como mytaxi competía con Uber en un sector tan regulado como el del taxi, y además con normativas muy locales en toda Europa, la aplicación necesitaba soportar múltiples variantes del mismo flujo. Eso llevó a la proliferación de decenas y decenas de configuration flags repartidas por todos los servicios. El resultado era un caos: nadie sabía con certeza qué estaba activado en cada ciudad, qué afectaba a iOS, qué afectaba a Android o dónde estaba realmente definida cada opción. Para colmo, la configuración vivía dispersa entre unos 200 servicios distintos.

Un día, Maria — Agile Coach — me habló de este dolor de forma muy directa. Y yo hice lo que mejor sabía hacer en ese momento: construir. Monté un portal — un poco cutre, si os soy honesto —, que consultaba las APIs de configuración de todos los servicios y agregaba esa información por funcionalidad, país o ciudad.

De repente, con un vistazo, cualquiera podía saber qué estaba activado y dónde. No era bonito, pero resolvía un problema. Y, sobre todo, demostraba que estaba allí para ayudarles a trabajar mejor (credibilidad), no para imponer una agenda técnica abstracta. Al poco tiempo, otros equipos comenzaron a usar el portal, incluyendo Product Owners, QA y hasta gente de Operations. Sin quererlo, se convirtió en una herramienta de alineamiento organizativo. Y llevó a algo aún más interesante: otros ingenieros empezaron a contribuir.

Al ver el valor que generaba, varios compañeros propusieron mejoras, corrigieron pequeños fallos y añadieron funcionalidades que yo ni había considerado. Uno de ellos creó incluso una pequeña web para visualizar las Zonas de una ciudad, algo que resolvía un dolor histórico para los equipos que trabajaban con geofencing o la asignación de conductor a pasajero. Otro automatizó parte del proceso de actualización de flags. Alguien más añadió métricas para detectar configuraciones inconsistentes entre plataformas.

De pronto, lo que había empezado como un apaño rápido se convirtió en un pequeño ecosistema de herramientas internas que reducía incertidumbre, aceleraba decisiones y, sobre todo, hacía la vida del equipo un poco más fácil cada semana.

Ese efecto dominó me enseñó algo importante: cuando solucionas un problema real y lo haces visible, la gente se suma. La confianza también se construye así, invitando a otros a mejorar lo que empezaste y celebrando que lo hagan mejor que tú.

Depurar

El segundo momento tuvo que ver con algo mucho más humano: ayudar a depurar (debugging). Nunca me he considerado especialmente listo, pero sí he sido siempre muy sistemático al conectar puntos entre mensajes de error, código, hipótesis y comportamiento del sistema. Para mi sorpresa, mucha gente veía esto casi como magia. En realidad no lo era: era una mezcla de experiencia, fundamentos, intuición, saber dónde buscar y no tener miedo de meterme incluso en el código de librerías de terceros.

Empecé a acompañar a compañeros en la resolución de incidentes (intimidad), a enseñarles cómo formular y descartar hipótesis, a leer logs con intención, a diferenciar síntomas de causas. Propuse prácticas de incident review, lo que elevó la calidad de nuestras respuestas y nos ayudó a aprender colectivamente.

Sin darme cuenta, estas dos contribuciones hicieron más por mi reputación que cualquier presentación o strategy deck. Construir algo útil y estar al lado de la gente cuando el sistema arde crea más confianza que cualquier título. Y fue a partir de ahí cuando mis ideas empezaron, por fin, a tener tracción. Curiosamente, estas dos acciones redujeron a cero mi autoorientación. Dejé de pensar en “mi estrategia” y empecé a pensar en “nuestro trabajo”.

Qué dirías a tu yo del 2018?

Al mirar atrás, me quedo con una idea: ningún TL consigue influencia porque “le toca”. Se gana día a día. No con discursos, sino resolviendo los problemas que duelen y estando en los momentos en los que la gente necesita apoyo real.

Si estás en una situación parecida, algunos consejos que me habría gustado recibir en 2018:

• Antes de proponer una estrategia, entiende primero qué le duele a tu equipo.

• Elige una o dos acciones que aporten valor inmediato y ejecútalas.

• Habla menos de arquitectura y más de cómo tu propuesta reduce toil, riesgos o incertidumbre.

• No busques demostrar que eres el más listo; busca que los demás puedan hacer mejor su trabajo.

• El ciclo de feedback, al contrario del código, es más lento. Se mide en semanas, o meses. Hay que tener paciencia.

• Y, sobre todo, recuerda que la confianza es acumulativa. Se gana en cada interacción.

La influencia técnica no empieza con un título, sino con el impacto visible que generas.

Porque cuando un TL no se siente escuchado, la solución no es hablar más fuerte.
Es cambiar la conversación. Y empezar por el único lugar donde de verdad tienes control: tu propio comportamiento.

🎁 ¿Quieres aterrizar esto mañana mismo en tu equipo? Regalo sólo para suscriptores

Muchos Tech Leads no se sienten escuchados porque EMs, TLs y el resto del equipo operan con expectativas distintas que nadie ha explicitado. Esa fricción no se resuelve con más reuniones ni más procesos. Se resuelve con claridad.

Para ayudarte a cerrar esa brecha, he preparado un toolkit de alineación GRATIS con tres herramientas prácticas:

• Para Tech Leads: un semáforo de autoevaluación para combatir el síndrome del impostor y entender con precisión dónde estás aportando valor y dónde te estás quemando.

• Para Engineering Managers: un semáforo de evaluación para dar feedback objetivo basado en comportamientos, no en sensaciones. Ayuda a tus Tech Leads a tener impacto!

• Para el equipo: una plantilla de principios operativos para dejar de discutir las mismas decisiones cada semana y crear criterios compartidos.

Y además, para acompañar este artículo, incluiré un plan concreto para tus primeros 90 días como Tech Lead: qué observar, qué priorizar, qué evitar y cómo generar confianza a través de pequeños pasos visibles. Es exactamente el plan que me habría gustado tener aquella primera semana en mytaxi.

Si ya has descargado el toolkit, no tienes que hacer nada: ya tienes la versión actualizada y recibirás automáticamente el plan de 90 días.

Si aún no estás suscrito, apúntate y te lo envío. Es gratis y te ayudará a pasar de la intención a la acción.

Descargar GRATIS toolkit de alineación EM/TL

— João

En esta newsletter quiero centrarme en empresas que destaquen por una buena tecnología e ingeniería en España y en Europa. Si tienes recomendaciones de charlas, artículos o blogs a seguir, envíame un mensaje a spanish@joaoqalves.net.

Lo mejor de la semana

🇪🇸 (22’) Esta charla de Abraham Vallez relata el golpe emocional y práctico de volver al mercado laboral tras un despido: un entorno saturado, procesos eternos sin feedback y currículums filtrados por bots que obligan a “cambiar de profesión” y a dominar el Application Tracking System (ATS) antes de poder hablar con un humano.

Abraham nos cuenta que sus salvavidas fueron la comunidad y las referencias, junto con una preparación exhaustiva de entrevistas, usando el método STAR y apoyándose en la IA para ordenar su propia historia. El mensaje final es claro: no es un fallo personal, sino un sistema roto, y apoyarse en valores, redes y mentores ayuda a atravesarlo con menos sufrimiento.

🇬🇧 (5’) Pere Villega presenta un repositorio que ofrece una configuración avanzada para usar Claude Code en modo YOLO — con sandbox y salvaguardas — y así obtener una experiencia agéntica potente pero relativamente segura. Incluye scripts para instalar plugins, validar proyectos, sincronizar worktrees y arrancar el agente con el contexto inicializado en Serena.

🇬🇧 (10’) Teo Díaz, Senior Software Engineer en Cabify, nos explica cómo transformaron la experiencia de recogidas en aeropuertos y estaciones — un punto crítico y muy propenso a la frustración — pasando de instrucciones rígidas a una plataforma totalmente autoservicio para los equipos de operaciones. Empezaron añadiendo guías contextuales y luego trasladaron las instrucciones antes de la petición del viaje, lo que mejoró de inmediato el éxito de las recogidas.

El salto llegó con Rider Admin, un backoffice creado en tiempo récord con Phoenix LiveView que permitió al negocio actualizar los puntos de encuentro e instrucciones sin depender del equipo de ingeniería.

🇬🇧 (7’) Miquel Arranz, Expert Frontend Engineer en Typeform, resume cómo trabajar en un equipo guiado por datos le enseñó que un buen entorno de experimentación es clave para tomar decisiones de producto con impacto real. Explica, con un ejemplo reciente, cómo definen hipótesis y métricas, configuran tests A/B con feature flags, monitorizan problemas habituales y analizan resultados con herramientas como LaunchDarkly, Amplitude o GrowthBook.

🇬🇧 (5’) Max Charas y Marc Bruggmann, de Spotify, nos cuentan cómo, tras extender su Fleet Management con un agente capaz de editar código y abrir PRs automáticamente, el foco de la segunda parte es dominar la ingeniería de contexto: cómo escribir prompts y limitar las herramientas para que el agente genere cambios fiables en miles de repos. Tras topar con las limitaciones de los agentes de código abierto y de su propio bucle agente, Claude Code les permitió trabajar con instrucciones más naturales y gestionar tareas complejas sin perderse por el camino. La clave está en prompts claros, con precondiciones, ejemplos y un único cambio por vez, además de un conjunto de herramientas muy reducido para mantener la previsibilidad.

El resultado es un Fleet Management más potente, capaz de ejecutar migraciones reales a escala, aunque aún depende de la intuición y están explorando nuevos feedback loops para hacerlo más sistemático.

Publicaciones en X

¡Esto es todo! Nos vemos la semana que viene. Recuerda: si te ha gustado la newsletter, dale al “like” y suscríbete. ¡Ya sabes cómo funcionan los algoritmos de estas plataformas!

— João

¿Qué es un tech lead? ¿Diferencias con EM?

Seguramente mucha gente ya lo tenga claro, pero explicaré mi visión de estos dos roles:

• Engineering Manager: es el responsable del equipo y la mayor parte de su labor se centra en tres ejes de gestión:

  • Personas: que la gente tenga un buen desempeño y todo lo que eso conlleva (revisión de performance, planes de carrera profesional, etc)

  • Producto/proyecto: que haya un desarrollo sostenible de las funcionalidades requeridas (gestión de stakeholders, expectativas, negociación de scope, riesgos, etc)

  • Procesos: ¿cómo se priorizan los bugs frente a las nuevas funcionalidades? ¿Cómo se decide en qué trabajar esa semana? ¿Cómo se hace mejora continua? Aquí, lo importante no es añadir procesos ad nauseam. Es el equilibrio necesario para que el equipo opere de forma independiente — idealmente sin él — y para poner cierta estructura al caos natural.

• Tech Lead: es el responsable de la dirección técnica del equipo. Su foco está en tres áreas:

  • Arquitectura: definir las decisiones técnicas clave, revisar las propuestas, asegurar que las soluciones escalan y que la deuda técnica sea manejable y, sobre todo, que se asuma de forma consciente y no por accidente.

  • Calidad: mantener un alto estándar en el código, las revisiones, las pruebas y la observabilidad. No es hacerlo todo él, sino elevar el listón del equipo.

  • Mentoría: ayudar a los ingenieros a crecer, desbloquear problemas complejos, compartir contexto y facilitar que todos puedan tomar mejores decisiones técnicas.

Como se puede ver, son roles muy diferentes y requieren un enfoque muy distinto. Es posible que la misma persona desempeñe ambos roles. En cierto modo, el fin de la era de intereses cero (ZIRP, en inglés) y el foco en la eficiencia han vuelto a otorgarle al EM un rol más hands-on.

Nota: en el diagrama he excluido el rol de Product Manager, dado el foco del artículo de hoy. Tu realidad seguramente sea más compleja.

Modelos operativos

Hay varios formatos para contar con alguien que ejerza liderazgo técnico en un equipo:

1. EM y TL son roles oficiales y los tienen dos personas diferentes

2. EM y TL son roles oficiales y los tiene la misma persona

3. EM es el único rol oficial y se espera que los ingenieros del equipo puedan liderar iniciativas técnicas sin ocupar ese rol. Esto hace que, implícitamente, el EM se asegure de que el equipo esté cubierto en las tres áreas del TL.

Hay otras formas de organización, pero estas son las más comunes. Exploraremos el modelo en el que hay un EM cuyo TL reporta a él. Para los demás casos, no es muy diferente, aunque con algunos matices. En el caso del EM+TL, el director debe realizar la evaluación de “¿qué significa bueno?”. En caso de no haber un rol formal de TL, es el EM quien debe ser consciente de las áreas por cubrir y evaluar a los ingenieros en sus distintas facetas.

Nota: hoy no hablaremos de los roles de Staff o de Principal Engineer que se extienden a más de un equipo. Lo dejaremos para otro artículo.

¿Cómo sé que un TL está haciendo bien su trabajo?

En los tres pilares que menciono antes hay algo en común: se espera que el TL tenga un efecto multiplicador en el equipo. Esto significa que es importante que el TL no se vuelva un cuello de botella, sino que ayude al equipo a ser autónomo. Si el equipo, después de un tiempo de adaptación, requiere la figura del tech lead para tomar decisiones, es señal de que hay que ajustar la forma de trabajar y que, seguramente, el TL no está cumpliendo con su rol.

Aun así, esto suena bastante abstracto. En la práctica, un buen TL se parece mucho a un ingeniero Staff+ — ese perfil que trasciende la ejecución de tareas y se enfoca en resolver problemas ambiguos o estructurales — que opera con claridad, criterio y amplitud. Es alguien que aporta dirección técnica, reduce la ambigüedad y empuja al equipo hacia decisiones que benefician al conjunto, no solo a su área.

Define el qué y el cómo cuando hace falta, pero también crea las condiciones para que otros lo hagan. Identifica riesgos, simplifica los problemas abiertos, frena el scope creep y alinea el trabajo técnico con los objetivos del producto. Y, sobre todo, genera velocidad: con principios operativos claros, con artefactos escritos que facilitan la reflexión (Requests for Comments, pruebas de concepto, propuestas de diseño) y con decisiones que otros pueden entender y continuar sin depender de él.

Podemos aterrizarlo con señales muy concretas en cada uno de los tres pilares: arquitectura, alcance técnico y principios operativos.

Arquitectura

Comportamientos que ayudan

• Usar Requests for Comments (RFCs) u otros documentos breves para estructurar debates técnicos y forzar la claridad: problema, alternativas, trade-offs y decisión.

• Identificar cuando una discusión se alarga sin avanzar y proponer una prueba de concepto (PoC) o un experimento acotado para validar los supuestos.

• Hacer explícito cuándo ciertas decisiones generan deuda técnica y por qué se acepta en ese momento.

• Involucrar al equipo en las decisiones clave para que todos comprendan el razonamiento y adquieran criterio.

Comportamientos que frenan

• Tomar decisiones improvisadas en chats o en pasillos, sin dejar constancia.

• Prolongar reuniones interminables sin una síntesis clara ni un siguiente paso.

• Diseñar soluciones sin validar riesgos ni suposiciones mediante un prototipo.

• Ser la única persona que sabe “cómo va todo” y convertirse en guardián del conocimiento.

Alcance (scope) técnico

Comportamientos que ayudan

• Negociar activamente con el EM y el Product Manager el equilibrio entre la deuda técnica y la entrega de valor. Entender las restricciones del negocio y defender que la calidad es la única forma de mantener la velocidad a medio plazo.

• Detectar scope creep técnico: añadidos de complejidad, requisitos no funcionales “extra” o decisiones que hacen que el sistema sea más grande sin aportar valor real.

• Simplificar las soluciones proponiendo fases técnicas razonables: primero, algo que funciona; después, algo que escala. Esto es, identificar el mínimo cambio viable

• Revisar regularmente si el diseño actual sigue alineado con el problema y eliminar piezas que ya no aportan.

• Señalar las dependencias o riesgos técnicos que pueden retrasar al equipo si no se abordan a tiempo.

Comportamientos que frenan

• Añadir requisitos técnicos “por si acaso” y aumentar el coste de la entrega sin motivo alguno.

• Sobrediseñar sistemas que podrían ser mucho más simples.

• Ignorar señales de que el equipo se está metiendo en una solución demasiado grande para el tiempo disponible.

Principios operativos y velocidad del equipo

Comportamientos que ayudan

• Definir principios operativos escritos que sirvan como brújula: qué se prioriza, qué se evita y qué significa “bueno” en el contexto del equipo.

• Ejercer influencia sin autoridad: convencer mediante argumentos y visión, no por la jerarquía. Facilitar el consenso cuando es posible y el “disagree and commit” cuando es necesario para desbloquear al equipo.

• Usar estos principios para acelerar la toma de decisiones y reducir la dependencia del TL.

• Revisarlos periódicamente con el equipo para adaptarlos a la realidad del producto.

• Promover decisiones consistentes para que el equipo gane confianza y se mueva rápido sin pedir permiso.

Comportamientos que frenan

• Tomar decisiones ad hoc que cambian cada semana y confunden al equipo.

• Evitar conversaciones difíciles por miedo al conflicto (artificial harmony) o permitir que debates triviales (bikeshedding) detengan el avance del equipo.

• Guardarse los criterios personales, dejando que cada persona optimice según su gusto sin una dirección técnica común.

El impacto real de un TL

En el fondo, el reto de un Tech Lead no va de saber más que el resto, sino de crear el entorno en el que el equipo pueda pensar mejor, decidir mejor y avanzar mejor. Cada organización y cada equipo necesita algo distinto, así que no hay una receta universal.

Lo que sí podemos hacer es observar cómo fluye el trabajo, cómo se reparten las decisiones y cómo evoluciona la autonomía del equipo. Ahí es donde se ve el impacto real de un TL. Y quizá la pregunta que cada uno debería hacerse no es “¿lo estoy haciendo bien?”, sino “¿estoy ayudando al equipo a depender menos de mí cada mes que pasa?” Esa respuesta suele ser más honesta y útil que cualquier checklist.

🎁 ¿Quieres aterrizar esto mañana mismo en tu equipo? ¡Un regalo sólo para suscriptores!

La fricción entre EMs y TLs suele surgir de expectativas no verbalizadas. Para cerrar esa brecha, he creado un toolkit de alineación GRATIS con tres herramientas prácticas:

• Para Tech Leads: Un semáforo de autoevaluación para combatir el síndrome del impostor y saber exactamente dónde aportas valor (y dónde te estás quemando).

• Para Engineering Managers: un semáforo de evaluación para dar feedback objetivo basado en comportamientos y no en sensaciones.

• Para el equipo: un template de principios operativos para dejar de discutir las mismas decisiones cada semana.

Suscríbete, te enviaré el kit y pasarás de la intención a la acción. ¡Es GRATIS!

Descargar GRATIS toolkit de alineación EM/TL

— João