Welcome to another instalment of Stories on Facilitating Software Architecture and Design. In our conversations, we explore the real-world challenges of building software and leading teams. Today, we’re joined by Paul Rayner, a consultant, trainer, and facilitator specialising in Domain-Driven Design and EventStorming.
During a recent discussion, Paul shared a powerful story from his time as a tech lead. It’s a candid account of a well-intentioned decision that had a deeply negative, albeit unintentional, impact on a team member. It serves as a crucial lesson on the gap between intent and impact, and the unseen power dynamics at play in any team.
The Refactoring Session That Went Wrong
Paul set the scene for us. It was the late 2000s, and he was the tech lead for a distributed team with developers in Colorado, Chicago, and Buenos Aires. They were working on a complex system, and Paul was keen to introduce practices like Domain-Driven Design and Test-Driven Development.
"I thought it would be a good idea to get all the development team on a call and pick some code," Paul explained. "To talk through how to refactor it and how to improve it and make it more expressive of the domain concepts."
With the team gathered virtually, Paul, acting as the tech lead, selected a piece of code and began demonstrating refactoring techniques like 'extract method' and showing how to apply test-driven development.
What happened next was unexpected. "Not long after that call," Paul recounted, "one of the developers quit."
He soon discovered the reason. The code he had chosen to publicly critique and refactor had been written primarily by one of the contractors on the team. "He felt very embarrassed and shamed by what I'd done," Paul admitted. "It implied to the rest of the team that the code he'd been involved in was not up to par."
Acknowledging the Real Impact
This is the moment where the story turns from a mistake into a lesson. Paul recognised the gravity of the situation. He reached out to the developer, apologised, and then later extended that apology to the entire team. Fortunately, the developer accepted the apology and returned, continuing as a key member of the team.
Reflecting on the event, Paul was clear about his misstep. "I remember at the time thinking I was doing everything with the right intentions and the right motives, but I just had a complete lack of understanding of how that would be perceived… how my misuse of my power and authority actually caused someone a lot of embarrassment and shame, even though it was unintentional."
This experience became a wake-up call about awareness, the power we wield in leadership roles, and the importance of finding better ways to influence change—ways that involve coming alongside people rather than putting them in a spotlight.
Unpacking the Dynamics at Play
Paul’s story prompted a deeper discussion about the forces at work in such a situation.
1. Power Dynamics and Being 'Rank Blind' Paul held no explicit managing authority over the contractor, but as a tech lead and a full-time employee, he did have ranking authority over the contractor. This power dynamic, whether consciously acknowledged or not, amplified the impact of his actions. As Kenny Schwegler noted during our chat, leaders can often be "dominant blind"—unaware of how their rank and seniority are perceived by others. The more authority you have, the more carefully you must consider the potential impact of your words and actions.
2. Challenging a Person, Not Just Their Code When we critique code, we are not just critiquing lines of text. As Andrew Harmel-Law pointed out, we are challenging the mental models, the understanding, and the effort that went into creating it. For the developer, that code represented their best solution to a problem. Publicly refactoring it without context or consent can feel like a direct challenge to their competence and thinking.
3. Moving Beyond "Good Intentions" It’s easy to defend our actions by saying, "but my intentions were good." This is a form of cognitive dissonance that prevents real learning. The crucial step Paul took was to move past his intentions and focus on the actual impact. How did the other person feel? What damage was done to the relationship and team trust? True leadership involves taking responsibility for the outcome, not just the intent. This means offering a genuine apology—"I was wrong"—rather than a hollow "I'm sorry you feel that way."
Better Ways to Guide and Influence
So, how could this have been handled differently? The conversation highlighted several alternative approaches for guiding teams toward better practices.
- Meet people where they are. Instead of imposing a new technique, start by understanding their current perspective. As Paul now advocates, you have to "meet them where they're at and really hear their concerns."
- Treat resistance as a resource. When someone pushes back against a new idea, it’s not just an obstacle. It’s a signal. Dale Emery’s article, "Resistance is a Resource," explains that resistance provides valuable information. Is the person feeling threatened? Do they not understand the proposal? Exploring the "why" behind the resistance is more productive than simply pushing back harder.
- Externalise the model. Techniques like Event Storming or Domain Storytelling are powerful because they get ideas out of our heads and onto a shared space. By putting sticky notes on a wall, we externalise our internal mental models. The focus shifts from a "me versus you" debate to a collaborative exploration of a shared artefact. We can point to it, move things around, and discuss it without it feeling like a personal attack.
- Explore multiple options. To diffuse tension between two competing ideas, try introducing a third option. As Paul suggested, "at least come up with three different options on the table, because then it's not me versus Kenny." This simple technique shifts the dynamic from conflict to a more objective evaluation of possibilities.
Paul's story is a humbling reminder that leadership is fundamentally about people. The technical practices we champion are only effective if we can introduce them with empathy, awareness, and respect for the individuals we work with. Making mistakes is inevitable, but it is our willingness to learn from them, repair the harm, and share the lesson that truly defines our growth as leaders.
