#46 | Sunday reads for EMs
My favourite reads of the week to make your Sunday a little more inspiring.
👋 Hey, it’s Stephane. Every Sunday I share with you my favourite reads of the week.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.
Barely Treading Water (Michael Lopp)
tl;dr: Even though the company looked successful from the outside, he was personally overwhelmed and slowly failing at prioritizing, delegating, and managing expectations. A trusted colleague confronted him: leaders fail too, and the solution is to honestly admit it, ruthlessly prioritize, delegate more work, and say no to things the team realistically cannot do.
From Metrics to Meaning (Mike Fisher)
tl;dr: Metrics alone rarely inspire action because numbers without context do not create meaning. Great leaders turn data into stories by explaining what the team believed, what the metric actually revealed, and what action or change is now needed.
AI Productivity Debate (Justin Reock)
tl;dr: How senior engineering and research leaders think AI is changing software engineering, from coding and code review to hiring and team structure. The overall view is that AI will not replace engineers, but it will change the work engineers do, shifting more focus toward reviewing, guiding, prioritizing, and managing AI-generated output.
Distilling Leadership Wisdom (James Stanier)
tl;dr: How you can use AI to “distill” the thinking of leaders you admire by feeding interviews, podcasts, and writing into a custom AI role you can talk to anytime. Instead of copying their opinions, the goal is to use their mental models and questions to challenge your own thinking and make better decisions.
Software’s Centaur Era (Richard Marmorstein)
tl;dr: Even if AI becomes better at writing code, software engineers will still matter as long as humans working with AI outperform AI working alone. It compares the current moment to chess “centaurs”, where the strongest results came from humans and AI collaborating together rather than either operating independently.
Learning Software Architecture (Alex Kladov)
tl;dr: Software architecture is mostly learned through building real systems and dealing with real constraints, not through theory alone. The quality and structure of software are heavily shaped by incentives, team structure, and organizational pressures, not just technical skill.
Most popular from last time
The slop cannons in your engineering org
If you enjoy articles like these, you might also like some of my most popular posts:
What did you read recently that you would like to share?









