Listen to Your Team

stamp character set

For any software team, there are many customers. Some customers are external to the organization. Some customers are internal, such as the leadership team, marketing, and sales. The list seems endless at times. As a team member, you share all the responsibility of keeping the customers happy. There is one customer that every team has that has not been mentioned yet, that customer is each team member on your team. For this post, we will focus on the most important customer, your teammates.

I recently wrote some code to add additional functionality to our API. In total, there were about 75 lines of change. Our development process requires a review of the changes before it can be deployed to a production environment. One engineer looked at the changes and hated a decision I had made. In reading the comments I could have handled the situation in many ways. The extreme options were to get defensive or just do as the comment suggested.

I opted to split the extreme options down the middle. I wanted to understand why the comments were made and what the reviewer thought of my decisions. What I learned was the team has a general distaste for the framework feature I chose to use. Preferring a different approach. My personal opinion was to make no changes from the comments, as my approach was more readable with maximum separation. While the proposed solution was more coupled and didn't read as well.

After a few moments of discussion, an agreement was reached. The final solution that went to production was not my preferred solution. I refactored the code to the proposed solution in the comments. But why? My first thought was all about support. As the lead of the team, my time writing software is not consistent. The review and comments came from a developer who writes software all day long. The odds of me supporting this implementation in the future is low compared to the reviewer. Secondly, I don't have to be right. We are software engineers, this is a team sport. This is not a mission-critical decision. No one is getting fired over this low-level decision. It does not matter one bit how this implementation is written. Me conceding to this young engineer is a win for them. That win gives a stronger sense of ownership and a sense of contribution to the overall project. Finally, being a little selfish, I could learn a thing or five about new features and patterns. Everyone can always learn something.

Take care of that team relationship, and continue working on it. Your actions today, shape the leaders of tomorrow.