Posted on June 16th, 2020
"I know it was a mistake, but you merged changes that..." The words cut deep. My heart rate was up. I wasn't sure how to take what was being said. I held my breath as I opened up the PR diffs for the fix to see what had happened. What I saw relieved some stress but added a new kind too.
Naturally, I was feeling defensive. I'll spare you the details, but I got a third dev's perspective, and he agreed I was in the clear. That didn't change the fact that another person on the project was frustrated and had spent time debugging a problem.
I saw two choices. I could defend my reputation, respond in public where he'd called out my supposed mistake, and point out his actual mistake. Or I could take it on the chin, help him fix it, and point out the root issue later one-on-one.
Coach in Private
Some conversations go better in front of people than others. Conflict is like wildfire: it spreads quickly and easily. The more fuel there is nearby, the faster it will spread. And most anything can be fuel. So when there is conflict, I do my best to reduce the amount of what can become fuel in two ways: rehearse and have the actual conversation with as few participants as possible.
Leaders who rehearse hard conversations avoid harder outcomes. Let's face it. Our first solution when we code is rarely the perfect one. We plan, execute, review, and
push refactor then push. Then we rebase. And then we get a review before merging upstream. Why wouldn't we do the same thing with hard conversations?
Rehearsing hard conversations helps us deal with our own emotions beforehand. It also helps us say what needs to be heard when we have the real conversation. It helps us avoid relational damage to our team members.
This is especially true where leadership is concerned. Most team members feel that even in a push situation with their leaders, where both parties agree to disagree, they still lose. As leaders, we know the equally difficult truth that even when we "win" an argument, we can still "lose" confidence, effectiveness, and rapport with our team members. Ultimately it's about winning our team members over to an aligned perspective.
Praise and Apologize in public
That's why I don't stop at coaching in private. When there's good to share about any team member's work, I share it in public. It doesn't need to be laid on thick, or it can come off as schmoozing. And I don't do this if people really don't like it. But if they're cool with it, I share.
It might be a quick "thank you" between other updates if it's small. It can be a shout-out in a channel when they share a great resource. However it comes out, I make sure I say thank you to that person, acknowledge the work they did and its benefit so the team knows that person is a solid contributor.
And I also make sure to apologize in public. When someone else makes a mistake, I leave it to them how they want to handle it, as long as the mistake itself gets fixed. But for myself, I make it a point to own my mistakes at a relevant public level. I mis-explained deep cloning to a few teammates months back. I apologized to them and the others on the team publically for two reasons. First, I wanted to correct it for them and any others they had, in turn, shared it with. Second, if they made the same mistake, I didn't want them to take the fall. I misled. So I owned it.
The third part of this is that I hold people to appropriate standards. I can't expect everyone to do what I do. Everyone has their own code and communication preferences. Leaders don't make copies of themselves. They help others become the best versions of themselves. They lead by being secure in their values and executing, regardless of how hard the course is. The goal is that over time truth will out, and everyone (including leaders) shed their less helpful values and replace them with ones that they see as more helpful.
All opinions are my own and are not necessarily held by my employer.