#29 | Sunday reads for EMs

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

Jan 04, 2026

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

10 Prioritization Traps (John Cutler)

tl;dr: John names the specific prioritisation failures most teams fall into. Each one comes with a concrete “Do This Now” action. I found this one great to keep in mind: “How cheaply can we increase confidence?” rather than just scoring confidence at a single point in time.

How differently do software developers perceive the same communication? (Lizzie Matusov)

tl;dr: Research shows ~65% of messages risk being perceived completely differently than intended - and it’s not random, it’s systematic. Two distinct perception groups exist: one values “emotional resonance” (emojis and casual language = positive), the other values “helpfulness and informativity” (casual = unprofessional). Demographics don’t predict which group someone falls into, but just five polarizing statements can predict which group you fall in with 100% accuracy.

The Precious Eyeblink (Kent Beck)

tl;dr: Modern dev tools have unconsciously traded speed for completeness, and it’s killing flow state. The Doherty Threshold (400ms) is where feedback keeps you in the zone; beyond that, your brain starts context-switching to email.

When Change Outruns Us (Mike Fisher)

tl;dr: The “acceleration trap” is when orgs push change so fast they outpace their ability to absorb it - Nokia died this way, not from complacency but from reorg exhaustion. Growth requires absorption intervals where teams make meaning of changes, rebuild trust, and integrate lessons.

Your Career Needs A Breaking Change (Steve Huynh)

tl;dr: Goals are “hope-based planning” because they assume static conditions. Instead, run a 15-minute Stop/Keep/Start exercise on behaviors rather than outcomes.