Saturday, September 26, 2026

Good talks/podcasts (Sep II)

These are the best podcasts/talks I've seen/listened to recently:
  • The OKR TRAP Most Companies Fall Into 🔗 talk notes (Dan North) [Company Culture, Management, Strategy, leadership] [Duration: 00:08] (⭐⭐⭐⭐⭐) Dan North traces OKRs back to Drucker's management by objectives and to Andy Grove's rework of them at Intel, then shows the three places organizations break them: defining objectives as activities, tracking work done instead of distance to the goal, and scoring key results at the end of the quarter as if they had been targets.
  • 34. Pensar en sistemas - Donella Meadows - Libros en 20 minutos 🔗 talk notes (Andrés Aguilar, Donella Meadows) [Mental models, Strategy, Systems Thinking] [Duration: 00:21] (⭐⭐⭐⭐⭐) Recorrido por Pensar en sistemas, el libro póstumo de Donella Meadows: qué es un sistema, cómo los bucles de refuerzo y de equilibrio con sus demoras producen comportamientos que nadie quiso, y por qué los puntos de apalancamiento que de verdad cambian algo son los menos obvios.
  • The CTO's Guide to Fixing Slow Delivery 🔗 talk notes (Dave Farley) [Continuous Delivery, Feedback cycles, Management, Nature of Software Development, Small Safe Steps (3s)] [Duration: 00:13] (⭐⭐⭐⭐⭐) Every obvious lever a technology leader reaches for when delivery feels slow — more people, more pressure, more checkpoints — tends to make it slower, because software development is discovery rather than production. Dave Farley makes the case for optimising the speed of learning instead, and letting delivery speed fall out of it.
  • Residues: Time, Change & Uncertainty in Software Architecture 🔗 talk notes (Barry M. O'Reilly) [Architecture, Evolutionary Architecture, Mental models, Resilience, Systems Thinking] [Duration: 00:46] Randomly stressing an architecture produces designs that are more likely to survive events nobody predicted than requirements engineering or risk management manage. Barry M. O'Reilly explains why through complexity science — Kauffman networks, attractors and criticality — and walks through the stressor analysis, the incidence matrix and the PhD experiment built to falsify the whole thing.
  • Building Software That Survives 🔗 talk notes (Michael T. Nygard, Charles Humble) [Architecture, Engineering Culture, Legacy code, leadership, team topologies] [Duration: 00:38] From the 3 a.m. outages that produced Release It to running architecture enablement at Nubank, Michael T. Nygard talks with Charles Humble about autonomy as something you grant per activity rather than wholesale, about Conway's law being a law about communication and not org charts, and about how much a leader changes by what they celebrate rather than by reorganising.
  • Product Thinking on Data and Platform Teams: Is It Worth It? 🔗 talk notes (Jacqueline Lee) [Data Engineering, Legacy code, Observability, Platform engineering, Product] [Duration: 00:41] Product thinking was built for external customers, and porting it to internal data and platform work breaks in specific ways. Jacqueline Lee contrasts a greenfield bank for underbanked Canadians with getting 37 teams off a legacy table at Yelp, and lands on a developer-friendly definition: understanding the user, the business and the tech, and writing code that lets you test, learn and adapt fast.
  • Thinking in Product Outcomes | The Shift Every Engineer Needs to Make 🔗 talk notes (Peppe Silletti) [Feedback cycles, Lean Product Management, Mental models, Product, Product Engineer] [Duration: 00:25] Business outcomes are lagging indicators an engineering team cannot move directly; product outcomes are leading indicators tied to user behaviour that it can. Peppe Silletti works through the difference, the four tests of a good product outcome, and what an engineer can actually do to stop taking orders — with the key concepts mirrored in engineering analogies.
  • The creator of OpenClaw: "I ship code I don't read" 🔗 talk notes (Peter Steinberger, Gergely Orosz) [AI Assisted Engineering, Developer Productivity, Engineering Career, Generative AI, Technical Practices] [Duration: 01:54] Peter Steinberger spent thirteen years building PSPDFKit, burned out, sold his shares and disappeared for three years — then came back straight into Claude Code having missed the years everyone spent deciding AI was useless. He explains to Gergely Orosz why he no longer reads most of the code he ships, why closing the loop is the whole secret, and why he now calls pull requests prompt requests.
  • Beyond the Warehouse: Why BigQuery Alone Won't Solve Your Data Problems 🔗 talk notes (Sarah Usher) [Architecture, Big Data, Cloud, Data Engineering, Software Design] [Duration: 00:44] Scale-ups buy the idea that one tool can do everything and make the warehouse that tool, which works beautifully until latency forces the first team to bypass it — and then everyone copies that bypass. Sarah Usher redraws the architecture around a raw / curated / use case lifecycle, argues that a single source of truth is a place you design rather than a system you own, and makes one request she repeats twice: store your raw data.
  • B2B Startup Metrics | Startup School 🔗 talk notes (Tom Blomfield) [Business models, Lean Startup, Management, Product, startup] [Duration: 00:23] Launching without metrics is flying an aircraft with no instruments, but a dashboard of 500 metrics at a few thousand users is just as useless. Tom Blomfield picks the handful that matter for a B2B startup — revenue, burn, runway, then retention, net dollar retention and gross margin — and explains what each one hides when you get it wrong.
  • How To Start A Dev Tools Company | Startup School 🔗 talk notes (Nicolas Dessaigne) [Business models, Devex, Management, Product Strategy, startup] [Duration: 00:32] Algolia's co-founder, now a YC group partner, walks through the whole arc of a developer tools company: why runtime ideas beat build-time ones, why you almost certainly do not need a business co-founder, when open source is mandatory rather than optional, and why at a dev tools company the documentation, the support queue and the marketing should all be done by engineers.
  • Starting A Company? The Key Terms You Should Know | Startup School 🔗 talk notes (Dalton Caldwell) [Business models, General, Management, startup] [Duration: 00:17] A plain-language glossary of the vocabulary founders are expected to already know — MVP, venture capital, angel, burn rate, seed and series rounds, product market fit, bootstrapping, SAFEs and convertible notes, equity, TAM, valuation, IPO and ARR — with the caveats that matter more than the definitions.
Reminder: All of these talks are interesting, even just listening to them.

You can explore all my recommended talks and podcasts on the interactive picks site, where you can filter by topic, speaker, and rating: Related:

Sunday, September 20, 2026

Good talks/podcasts (Sep I)

These are the best podcasts/talks I've seen/listened to recently:
  • Susanne Kaiser on DDD, Wardley Mapping, & Team Topologies 🔗 talk notes (Susanne Kaiser) [Architecture, DDD, Flow, Strategy, Team Topologies, Wardley maps] [Duration: 00:33] Susanne Kaiser details a holistic framework for designing adaptive socio-technical systems by integrating Wardley Mapping, Domain-Driven Design, and Team Topologies to optimize for a fast flow of change — aligning business strategy with architecture while managing team cognitive load and delivering continuous value.
  • Is Your AI assisted Coding Strategy Quietly Backfiring? 🔗 talk notes (Antony Marcano) [AI Assisted Engineering, Agile, Devops, Flow, Performance, WIP] [Duration: 00:11] Antony Marcano examines how AI-assisted coding acts as a performance magnifier that can inadvertently increase work-in-process and expose systemic bottlenecks in software delivery — with practical guidance on using DORA metrics and flow optimization so AI-driven code generation results in genuine organizational throughput.
  • Save HOURS Of Work & Automate Your AI Agent's Feedback Loop (Do This) 🔗 talk notes (Dave Farley) [AI Assisted Engineering, Continuous Delivery, Developer Productivity, Feedback cycles, Quality, Technical Practices] [Duration: 00:13] Dave Farley shows how meta-automation leverages AI agents to create deterministic feedback tools and custom linting rules, replacing unreliable 'markdown prayers' with automated loops — enabling teams of any size to scale advanced engineering practices and maintain project consistency across different AI models.
  • A Conversation with Amazon CTO Werner Vogels 🔗 talk notes (Werner Vogels) [Architecture, Business models, Cloud, Engineering Culture, Evolutionary Architecture, Programming language] [Duration: 00:48] Amazon CTO Werner Vogels details the principles of 'frugal architecture', offering a pragmatic framework for aligning technical costs with business value and revenue growth — with insights on building sustainable, evolvable systems while navigating the trade-offs of technical debt and reliability at high scale.
  • Software engineering with LLMs in 2025: reality check 🔗 talk notes (Gergely Orosz) [AI, AI Assisted Engineering, Developer Productivity, Engineering Culture, Generative AI, Nature of Software Development] [Duration: 00:25] Gergely Orosz cuts through the executive hype to give a grounded 'reality check' on how engineers across AI startups, Big Tech, and independent work actually use LLMs in 2025 — finding a genuine but nuanced shift, and arguing the right response is to experiment more and learn what has become cheap versus expensive.
  • Turing Award Winner: Data Abstraction, Dijkstra, Distributed Systems | Barbara Liskov 🔗 talk notes (Barbara Liskov) [Architecture patterns, Diversity, Engineering Career, OOP, Programming language, Software Design] [Duration: 00:34] Turing Award winner Barbara Liskov offers a profound look into the creation of modern software engineering, detailing how her pioneering work on data abstraction and distributed systems solved the 1970s 'software crisis' — with lessons on building reliable systems through strict encapsulation and modularity, and a career philosophy of solving fundamental problems rather than incremental ones.
  • Augmented Coding: Mapping the Uncharted Territory 🔗 talk notes (Lada Kesseler) [AI, AI Assisted Engineering, Developer Productivity, Generative AI, Mental models, Technical Practices] [Duration: 02:34] (⭐⭐⭐⭐⭐) Lada Kesseler offers a practical framework for mastering AI-assisted coding, turning unpredictable LLMs into reliable, structured partners through patterns like knowledge checkpoints and specialist agents — with actionable strategies for managing context and non-determinism so developers harness AI's creative breadth without sacrificing technical precision.
  • Marty Cagan on the Current "Golden Era" for Product Management (Full Interview) 🔗 talk notes (Marty Cagan) [AI, Agile, Generative AI, Product, Product Discovery, Product Strategy] [Duration: 01:01] (⭐⭐⭐⭐⭐) Marty Cagan explores the disruptive impact of AI on product management, arguing for a shift from project-driven output to strategic, outcome-oriented discovery and 'building to learn' — while stressing the indispensable role of human judgment and 'product sense' in achieving business viability.
Reminder: All of these talks are interesting, even just listening to them.

You can explore all my recommended talks and podcasts on the interactive picks site, where you can filter by topic, speaker, and rating: Related:

Tuesday, September 08, 2026

El ebook ya está en Leanpub

Hace unos días dije que en breve el ebook estaría en Leanpub. Ya está: https://leanpub.com/menos-software-mas-impacto

Compras una vez y te llevas el EPUB y el PDF, sin DRM. El PDF es lo que no te da el Kindle, y en un libro con diagramas y tablas se agradece.

El precio son 14,99 dólares, con el IVA aparte, porque Leanpub vende en dólares. La ficha deja pagar más si alguien quiere aportar algo más porque considera que le aportalo que escribo y comparto.

Lo digo porque en Leanpub hay muchos libros en curso y este no lo es. Está terminado y cerrado.

Si ya lo tienes en Kindle o en papel, no hagas nada. Esto es para quien no quería pasar por Amazon, o quería el PDF para leerlo en el ordenador y subrayarlo en la tablet.

Te cuento la parte que me toca, porque si no parece que cambio de tienda por capricho: en Leanpub me queda bastante más por copia que en Kindle, sin que tú pagues más. El papel solo está en Amazon y ahí seguirá, así que no te voy a pedir que dejes de comprar allí. Pero si te da igual dónde, ya lo sabes.

Ebook descargable general (pdf, epub), en leanpub: https://leanpub.com/menos-software-mas-impacto

En papel o kindle, en Amazon:

Lo del precio sigue en pie: si no encaja con lo que se cobra en tu país, o con el momento en el que estás, escríbeme y lo arreglamos. No hace falta que me cuentes nada.

— Eduardo Ferro Aldama
Menos software, más impacto

Wednesday, September 02, 2026

El viernes subo el precio del libro

 

El viernes 4 de septiembre suben los precios de Menos software, más impacto en Amazon: el Kindle pasa de 9,99 € a 12,99 € y la tapa blanda de 19,99 € a 24,99 €.

Lo aviso ahora porque sé que hay gente que lo tiene en la lista de "algún día lo compro". Si es tu caso, hasta el viernes sigue como está. Y si me lees el sábado, tampoco pasa nada: el libro no se va a ningún sitio.

Por qué lo subo, por si te interesa el detalle. Puse el precio de salida a ojo, sin tener ni idea de cómo iba a funcionar un libro técnico en castellano autopublicado. Tres meses y cerca de 400 copias después sé bastante más. Y Amazon ha subido el coste de impresión tres veces desde junio, así que cada copia en papel me deja hoy bastante menos que el día del lanzamiento. Con el precio nuevo el libro se parece más a lo que cuesta cualquier otro libro técnico de este tamaño, y me paga el tiempo que le sigo echando: los recursos de la web, las correcciones que me van llegando.

Hay algo que me importa más que el número. Lo pongo mirando lo que se cobra en el sector aquí, y eso no vale para todo el mundo: hay países y hay momentos de carrera en los que 25 € significan otra cosa completamente distinta. Si es tu caso y quieres leer el libro, escríbeme y buscamos cómo. Lo que quiero es que acabe en manos de quien le vaya a servir, y el precio no debería ser lo que lo impida. No hace falta que me cuentes nada.

Esa misma semana hay otro cambio: el Kindle sale de Kindle Unlimited. Si lo tenías apuntado para leerlo con la suscripción, estos días son los últimos.

Si lo quieres antes del viernes:

Y gracias a toda la gente que lo ha leído y se ha tomado el rato de escribirme para contarme qué le ha servido y qué no. Esa parte no me la esperaba y es la que más me está gustando de todo esto.

— Eduardo Ferro Aldama
Menos software, más impacto

Sunday, August 02, 2026

Ya está la grabación del AMA con Agile Sur y FullStack Sevilla

Hace unos días hicimos una charla + AMA sobre «Menos software, más impacto» con las comunidades Agile Sur y FullStack Sevilla. Prometí que quien no pudiera conectarse tendría la grabación, así que aquí está.

Son casi dos horas, en formato entrevista y con preguntas del público en directo. No hace falta verlo entero ni por orden.

De todo lo que salió, hay una respuesta que no llevaba preparada y que me ha estado dando vueltas desde entonces. Preguntaron cómo explicar el coste basal a alguien de negocio, y mientras respondía me di cuenta de que el problema no es que no lo entiendan: es que la metáfora con la que todos pensamos el software está rota.

Decimos que construimos software, y esa metáfora viene de levantar edificios, donde el grueso del coste es la obra inicial y el mantenimiento es residual. Con software es al revés: cada cosa que existe cuesta capacidad cada día, se toque o no. Nadie va al cirujano a pedirle que le abra un poco más porque paga bien, pero en software sí presumimos de cuánto hemos construido.

Lo desarrollé entero en Nadie va al cirujano a pedirle que le abra un poco más, que se lee en cinco minutos y no hace falta ver el vídeo.

Algunas de las cosas que salieron

  • El coste basal explicado tres veces: a alguien técnico, a negocio y a dirección.
  • Por qué existe la tendencia a escribir código de más.
  • Si con IA construir es casi gratis, ¿por qué dejar de construir?
  • «Esto en mi empresa es imposible»: resistencias y cómo sortearlas.
  • Juniors, universidad e IA.
  • Autonomía, slack e impacto.

Y si prefieres algo más corto para empezar, la entrevista con Emilio Carrión son 40 minutos y funciona bien como puerta de entrada. Las dos están en la lista de charlas y entrevistas sobre el libro.

Gracias a Agile Sur y a FullStack Sevilla por organizarlo, y a todas las personas que se conectaron un 29 de julio a las 18:30 y se quedaron hasta el final.

El libro es Menos software, más impacto, y en menos-software.eferro.net están los recursos por capítulo, gratis y abiertos.

Nadie va al cirujano a pedirle que le abra un poco más

 Hace unos días hice una charla con preguntas abiertas del público, organizada por las comunidades Agile Sur y FullStack Sevilla. En algún momento alguien preguntó algo que me hacen mucho: cómo explicar el coste basal del software a una persona de negocio, de esas que escuchan «mantenimiento» y desconectan.

Respondí lo que suelo responder, pero mientras lo decía me salió otra cosa que no llevaba preparada, y creo que es la parte importante: el problema no es que no lo entiendan. El problema es que la metáfora con la que todos pensamos el software está rota, y ellos la usan igual que la usamos nosotros.

Heredamos la metáfora de la construcción

Decimos que construimos software. Levantamos arquitecturas, ponemos cimientos, montamos features. Todo el vocabulario viene de la construcción de edificios, y con él viene una idea de fondo que casi nunca hacemos explícita: que el grueso del coste está en la obra inicial y que el mantenimiento posterior es un porcentaje pequeño y previsible.

Bajo esa metáfora, construir más siempre es mejor. Más metros por el mismo presupuesto. Más entregado por el mismo equipo.

Con software el reparto es justo el contrario. Cada cosa que existe cuesta capacidad cada día, se toque o no. Hay que entenderla cuando alguien la lee, mantenerla compatible cuando llega lo siguiente, explicarla a quien entra nuevo en el equipo, actualizarla porque cambia el mundo alrededor aunque nadie la cambie por dentro. Y el mundo alrededor cambia mucho más rápido que hace veinte años.

A ese gasto continuo por el mero hecho de existir lo llamo coste basal, por analogía con el metabolismo basal: lo que consume un organismo solo por seguir vivo. No es deuda técnica. La deuda técnica es una decisión que tomaste y que puedes pagar. El coste basal lo pagas siempre, también con el código bueno.

Para negocio, es inventario

Cuando lo explico fuera de tecnología, lo que mejor funciona es hablar de inventario.

La imagen mental que tiene mucha gente de negocio es secuencial: hacemos una funcionalidad, la entregamos, pasamos a la siguiente. Como si lo anterior desapareciera del coste al terminarlo. Pero no desaparece: se queda en el almacén, y el almacén hay que sostenerlo. Cada cosa que dejas ahí resta un poco de la capacidad con la que vas a construir lo siguiente.

En las fases de expansión fuerte esto no se nota, y por eso engaña tanto. Si el equipo se satura, creas otro equipo. Divides, contratas, sigues creciendo y todo el mundo contento. Pero en cuanto dejas de crecer, aquello se hace bola: cada trimestre el equipo va un poco más lento, y nadie sabe señalar qué ha pasado porque no ha pasado nada en concreto. Solo se ha acumulado.

La prueba de la cirugía

La forma más rápida que conozco de enseñar que la metáfora está rota es cambiarla por otra donde el absurdo se ve solo.

Nadie va al cirujano y le pide que le abra un poco más. Nadie dice «hazme más puntos, que para eso te pago y además eres muy bueno». En cirugía todos entendemos, sin que haga falta explicarlo, que la intervención es el coste y que lo que importa es el resultado. Cuanta menos cirugía haga falta para conseguirlo, mejor cirujano.

En software hacemos justo lo contrario. Presumimos de cuánto hemos construido, medimos equipos por lo que entregan, celebramos el volumen. Enseñamos la cicatriz como si fuera el resultado.

La metáfora que sí ayuda

La que a mí me sirve es la de cultivar algo: sembrar, regar, podar, limpiar, de forma continua. Y tiene dos consecuencias que me parecen mucho más útiles que la del edificio.

La primera es que no hay que esperar señales de alarma. Si tienes un jardín y no vas nunca a cuidarlo, no necesitas un indicador que te avise: puedes dar por seguro que en unos meses estará despendolado. Es entropía, va en la naturaleza del sistema. Nuestro trabajo no es reaccionar cuando la complejidad ya duele, es gestionarla todo el rato para que no llegue ahí.

La segunda es que cambia la conversación sobre añadir. Quien sabe lo que cuesta mantener un terreno productivo durante todo el año no mete más plantas porque sí. Le pone un precio al año entero, no al día que siembra. Con software casi nunca hacemos esa cuenta: valoramos lo que cuesta construir algo, no lo que va a costar sostenerlo mientras siga vivo.

Ninguna metáfora es perfecta, y esta tampoco. El software no crece solo, y podar código es bastante más incómodo que podar un seto. Pero al menos pone el foco donde está el dinero: en lo continuo.

Qué cambia cuando cambias la metáfora

En los equipos donde este cambio ha calado, lo que he visto cambiar es esto:

  • Decidir no construir algo deja de parecer una rareza defensiva y pasa a ser parte del trabajo.
  • Antes de decir que sí, aparece la pregunta por el coste de sostenerlo, no solo por el de hacerlo.
  • Eliminar deja de leerse como destruir valor. Quitar una funcionalidad muerta es recuperar capacidad, igual que podar.
  • El trabajo de gestión de la complejidad se hace visible, y se puede defender en una priorización.

Y hay una implicación que se ha vuelto urgente. Si construir se abarata mucho, como está pasando con la IA, la parte cara no baja igual: entender, integrar, operar y sostener siguen costando lo mismo o más, porque ahora hay más cosas vivas. Abaratar la construcción sin cambiar la metáfora no resuelve el problema. Lo acelera.

La conversación completa

Todo esto salió en una charla de casi dos horas, en formato entrevista y con preguntas del público en directo. Además de las metáforas se habló de cómo explicar el coste basal a dirección, de por qué existe la tendencia a construir de más, de qué hacer cuando en tu empresa «esto es imposible», y de juniors, universidad e IA.

Y si quieres tirar del hilo, el libro es Menos software, más impacto, y en menos-software.eferro.net están los recursos por capítulo, gratis y abiertos.