Managing Engineers Egos During Change

Problem

My company recently put a much more formal code review process into place. This helped to protect our systems, ensured code quality, and ensured the team was working together and supporting one another. At the same time, we onboarded a new, more senior engineer, who was very competent but had out-of-date coding practices.

The problem lay in the code reviews themselves. The new engineer had previously worked closely with the business and was trying to get features out, but the mid-level engineer who had been at the company for a while was resisting a lot of the changes that the new engineer was putting through. Code reviews were turned into huge debates, with 10-15 lengthy comments.

Actions taken

After recognizing the issue, I realized that putting new processes in place could come with some baggage. I also realized that hiring a new engineer who wasn't used to these processes while, at the same time, learning how to put the systems in place, created difficulties and uncertainty.

There were technical debates happening in the code reviews, which is a good sign for a technical organization. However, the technical debate itself was taking far too much time. A debate can sometimes look technical from the surface, but it actually can relate more to people, egos, and fundamental disagreements.

I decided to tackle this problem in two parts. First, we needed to have an arbitrator. I asked our senior architect to act as the arbitrator to look over code reviews and, more importantly, work with the new engineer at the start of a task to ensure that his work would meet our quality standards. Giving someone a bit more authority for those moments helped things to move forward.

Beyond that, because this wasn't simply just a technical debate, I had individual conversations with the engineers and found out that one of the engineers had thought another was much more senior than he was, so had assumed he should know certain things. He was extremely frustrated and was feeling overwhelmed by the work he had to take on. I listened to him and was sympathetic, but also let him know that he needed to be supportive of new engineers and that he was feeling overwhelmed he needed to let me know.

The new engineer had a skills gap, so I provided him with a list of references and books, so he could understand what he was doing and why he was doing it. After talking to them, I got them in the same room together. This was really impactful, as having people come face-to-face to have a conversation encourages real dialogue. It's very important not to turn this step into a technical debate and, instead, let each side speak while the other listens. This helped to diffuse the pent-up emotions they both had.

Lessons learned

Since having those discussions, things have been going a lot more smoothly. We've seen significant improvements in the code reviews and the pipeline is no longer blocked. Changing processes in organizations will result in some chaos. It's important at that time to be extra supportive, and to communicate to your team ahead of time that they need to be supportive of new engineers coming in at the same time.