#23 | Sunday reads for EMs

My favourite reads of the week to make your Sunday a little more inspiring.

Nov 23, 2025

👋 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.

Why Does Development Slow? (
Kent Beck
)

tl;dr: Every feature you ship burns future optionality, and without deliberate investment in restoring options between features, you inevitably code yourself into a corner. Alternate between feature work and “tidying” that restores optionality, perceiving the gap between features as an investment opportunity rather than dead time.

What process inefficiencies have the biggest impact on developer satisfaction? (
Lizzie Matusov
)

tl;dr: Research on 191 developers found that process inefficiencies explain about a third of job satisfaction variance, but which inefficiencies matter is highly unequal. Process unsuitability (workflows that don’t fit actual work) and role ambiguity dominate the impact.

Top 5 Communication Frameworks for Engineers You Must Remember (
Jordan Cutler
)

tl;dr: PREP for persuasive arguments, GROW for mentorship/strategy planning, BLUF for senior leader interactions, Observation-Impact-Question for casual feedback, and Before-After-Bridge for presentations. The BLUF section alone is worth internalizing - senior leaders are filtering while you’re talking, so lead with your point or they’ll tune out before you reach it.

Twenty Tiny Leadership Lessons (Subbu Allamaraju)

tl;dr: A distillation of a Penn State leadership psychology master’s program into 20 principles. Most useful for engineers moving into management: leadership is a situational role (not a trait), followership and team membership are distinct skills from leadership itself, and task-oriented vs. relationship-oriented behavior needs deliberate balancing.

Using Metrics to Measure Individual Developer Performance (Laura Tacho)

tl;dr: The answer to “what metrics should I use for individual performance” isn’t a list, it’s a process. Work backwards from role expectations to find evidence that actually maps to what you need, rather than defaulting to easily-scraped activity data. Lines of code, commits, and story points fail because they’re team/system metrics applied to individuals who can’t control them. It’s appropriate to use team-level metrics for staff+ and managers whose explicit job is to influence those metrics.

An individual can change an organization (Phil Eaton)

tl;dr: A short reflection on watching Drew DeVault transform Linode’s engineering culture despite having no seniority or positional authority, just persistent, well-reasoned argumentation. In orgs with good-faith actors, people often default to what’s popular rather than what’s right simply because no one’s making the case otherwise.