Managing Team Conflict and Helping Engineers Gain Confidence

Problem

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.

Actions taken

I was not prepared for what had happened at the one-on-one and I almost panicked at 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 a junior engineer with about four years of experience, who had to deal with very direct and matter-of-fact feedback from one of the 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 how he delivers his feedback. Over the next couple of months, I worked with him on adding empathy and understanding to his communication style.

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 developer to seek design feedback earlier (design reviews, etc).

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.
  

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 a different very senior engineer had to override the junior’s technical decision on a fairly complex technical 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.

Lessons learned

• Listen. You don’t have to try and fix “it” now. Frequently the important part is to listen and empathize.
• Do problem solve. But at a later time or day, after you’ve listened and established some trust, and gathered feedback and context from multiple sources.
• Being good at delivering feedback with empathy is a skill that can be learned. 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.