#14 | Sunday reads for EMs
My favourite reads of the week to make your Sunday a little more inspiring.
👋 Hey, it’s Stephane. This is a new series in which every Sunday I share with you my favourite reads of the week. To accelerate your growth see: 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.
A Deep Dive into Developer Experience Surveys
tl;dr: Developer experience surveys should be short, anonymous, and run every 8–12 weeks for ICs (and optionally product or design). Start simple and always share, discuss, and act on results so responses feel meaningful. Over time, you can add benchmark data, custom tools, and follow-ups.
How can I deal with a team member who is always complaining?
tl;dr: Instead of silencing complainers, redirect their energy with one question: "What would you like to see instead, and what part of that are you willing to take on?". The research-backed insight is that people complaining about process failures usually care deeply about outcomes. This reframing technique can change the dynamic from criticism to ownership.
The evolving role of DevProd teams in the AI era
tl;dr: Developer productivity teams have a massive opportunity to own AI adoption across the org, but most are missing it. Focus on creating paths for AI tools, measuring impact properly, and applying AI to workflow problems at scale rather than hoping individual developers figure it out on their own.
Expert Generalists
tl;dr: Your most effective people are "Expert Generalists" who combine deep fundamentals with broad curiosity and collaborative skills. This piece breaks down specific hiring and career progression changes needed to identify these people. In the AI era, these generalist skills become even more valuable as the foundational patterns matter more than specific tool expertise.
On Good Software Engineers
tl;dr: A good engineer is simply someone you can trust to progress a project consistently by working with the team and delivering quality - the definition scales from junior to staff level based on scope. The non-obvious takeaway is that good engineers proactively embed quality practices (like refactoring as part of feature work) rather than asking permission, and they adapt their approach based on organizational context.
On meetings
tl;dr: "Solve it now" instead of scheduling a meeting. Send information async instead of meeting requests, include specific goals and deadlines, and default to 20-minute calls with clear agendas when meetings are actually needed.
Most popular from last Sunday
The Management Skill Nobody Talks About
What did you read recently that you would like to share?