Managing & coaching personal conflict
The second day after I joined a new company one of my new reports burst into tears at a seemingly innocuous “How is it going?” at the beginning of our first one-on-one. Though I was vaguely aware (it was my second day) that there were some bad vibes on the team, this emotional reaction caught me completely by surprise.
The story
I was not prepared for what had happened at the one-on-one and I almost panicked in the moment. Luckily, I remembered a management article that talked about similar situations and how it’s important to just listen. So I focused on listening and empathizing without trying to jump to solutions. It took me a few more meetings to better understand the whole picture.
This person was an engineer with about four years of experience, who had to deal with very direct and matter-of-fact feedback from one of the more senior engineers. In addition, she frequently felt talked over, disrespected, and never listened to in general. I’d like to add (as a side note), that this is a somewhat common problem in engineering where juniors (who are naturally less confident in their tech skills) feel disrespected when faced with a lot of direct feedback. And being a female in tech is also a factor to be mindful of.
After chatting with the senior engineer, I came away with the feeling that he didn’t mean to be harsh or disrespectful, but at the same time, it was obvious that he could improve on how he delivers his feedback. Over the next couple of months, I worked with him on adding empathy and understanding to his communication style.
This helped some and at the same time, I started to coach the junior on how to receive critical feedback and on some of the work processes that she could leverage to overcome conflict. For example, instead of waiting for feedback during a code review (which may ask the author to rewrite significant portions of the code), I pushed the junior developer to seek design feedback earlier (design reviews, etc).
Over time I also introduced several other process changes like:
Everyone gets a chance to speak during group discussions (as opposed to only the loudest voices in the room).
Ideas are debated around their pros/cons and trade-offs instead of around being good or bad.
If a debate gets too heated (we’re all human after all), take a break and come back to it in a few hours or the next day. It has the additional benefit of being able to sleep on the ideas and get a better or a new understanding of them.
Our regular coaching sessions and my willingness to listen helped the junior engineer improve her skills, but more importantly, gain trust and confidence in herself and the team. She became more comfortable with professional conflict and debating various engineering decisions. She also learned to be less and less stressed while doing so.
There was an occasion that I’d like to highlight where I basically had to pull rank. I and another very senior engineer had to override the junior’s technical idea on a fairly complex topic after a long and heated debate. I had a follow-up chat with her and we chatted about how this made her feel like a junior. Towards the end of the conversation (and after listening), I pointed out that the very senior dev and I have 40 years of experience combined vs. her five years. And while I don’t like using this as an argument, sometimes it’s very hard to explain the totality of your experience and why it necessitates certain decisions (but you should try anyway). That conversation (including my remark) ended well and I attribute that to the trust I’ve built up to that point.
Starting with our initial one-on-one, the junior engineer made steady progress and over time became one of the star performers on the team who wasn’t shy of getting into debates and pushing for her opinion (in a productive kind of way). I was proud of her accomplishments and, at a later date, she went on to work for a major Silicon Valley company.
What I’ve learned
Writing this blog, it feels like some of these lessons are obvious and maybe even trite. And yet, in the moment, it can be hard to remember them and apply them in practice. I hope that this little summary is at least a helpful reminder.
Listen. You don’t have to try and fix “it” now. Frequently the important part is to listen and empathize. Which helps to build trust in the longer term.
Do problem solve. But at a later time and day, after you’ve listened, established some trust, and gathered feedback and context from multiple sources.
Delivering feedback well can be learned. Like all other soft/people/EQ skills it’s not the easiest to learn but it’s possible. You can be both direct and empathetic at the same time (radical candor ftw). Invest time in teaching developers how to do it.
Set good (equitable) team practices. Everyone needs a chance to speak, decisions need to be transparent, etc. This is helpful for everyone, not just juniors.
Pulling rank is ok. But only very occasionally. And only after you discuss the decision first and explain why you chose to pull rank in the end. And that assumes that you’ve already built some trust that you can rely on.
Personal change takes time. This whole story took place over a two year period. As a manager you need to be patient and supportive throughout.