In this episode of Stories on Facilitating Software Design and Architecture, we are joined by Paul Rayner, a seasoned consultant and expert in Domain-Driven Design and EventStorming. Paul shares a candid "war story" from his time as a tech lead that completely changed how he views leadership and influence. He recounts a well-intentioned refactoring session where he publicly critiqued a team member's code, aiming to teach better practices. The result was unexpected and severe: the developer felt shamed by the experience and quit shortly after.

This experience served as a harsh wake-up call about the "unseen authority" leaders wield and how easily the "blast radius" of our actions can damage team psychological safety, even when our motives are pure. Paul opens up about the "dominant blindness" that often affects technical leaders—where we fail to see how our rank amplifies our words, turning a simple suggestion into a crushing directive.

We dive deep into the power dynamics of technical leadership, exploring why simply having the "right" technical solution isn't enough. The conversation covers how to move from "fixing" people's work to facilitating their growth, why resistance should be treated as a valuable resource rather than an obstacle, and how methods like EventStorming can help externalize conflict.

Key Learning Points:

1. The Gap Between Intent and Impact: Why "I meant well" is never a sufficient excuse when a team member feels alienated or embarrassed by your actions.
2. Dominant Blindness: How leaders often underestimate the heavy weight of their rank and the pressure it puts on colleagues, especially when navigating contractor-employee dynamics.
3. Resistance is a Resource: Instead of pushing harder against pushback, view it as a signal to understand the underlying fears, threats, or misunderstandings driving the resistance.
4. Challenging Mental Models: Recognizing that when you criticize code, you are often challenging the deep-seated mental models and hard work of the person who wrote it.
5. Externalizing the Problem: How using visual tools like sticky notes (e.g., in EventStorming) can shift the focus from "me vs. you" to a collaborative discussion about the problem on the wall.