Empathy Driven Development: How Engineers Can Tap Into This Critical Skill
Goulet, an engineer and communications consultant, argues that empathy is an engineering practice — not a personality trait, but a set of disciplines that change how code reviews, pair programming, incident post-mortems and customer-feedback conversations are conducted.
The piece is a good companion to Manrubia's "Radiating Programmer" from the same tradition: both are about engineers working in the open with care for the humans on the other side.
For product direction the value is in the specific mechanisms — First Round Review pieces tend to be long on concrete practice, and this one delivers.
Goulet's broader work on communication for engineers is worth exploring.
Central argument
Goulet argues that empathy is not a soft personality trait but a concrete engineering discipline — a set of learnable, repeatable practices that can be embedded into the everyday rituals of software work. She applies this argument to specific technical moments: code reviews, pair programming, incident post-mortems, and customer-feedback conversations, showing how each can be conducted differently when empathy is treated as method rather than temperament. The central thesis is that framing empathy as practice rather than character removes the excuse that it belongs outside engineering's scope.
Critique
The piece's strength — its focus on concrete individual and team practices — is also its limitation: it largely sidesteps the structural and incentive conditions that make empathic engineering either sustainable or impossible. An engineer who wants to run empathy-informed post-mortems inside an org that punishes vulnerability or rushes incident resolution has no practice to fall back on; the article risks implying that disposition and technique are sufficient when organizational design may be the binding constraint.
Why it matters for product
For a CPO, the article's real value is diagnostic: if engineering rituals like code review and post-mortems are conducted without the mechanisms Goulet describes, those rituals are producing friction and signal loss that compound into poor product decisions — bugs that don't surface customer impact, retros that don't generate learning, handoffs that erode trust between product and engineering. It also bears directly on team structure decisions around embedded engineers in discovery: engineers who treat empathy as craft are far more effective partners in customer research than those who treat it as someone else's job.