Giving feedback

Leading teams

One of your jobs as an engineering manager is to constantly provide feedback about your team member's performance, both about the work they do for clients and their interactions with other team members here at Nebulab.

While we all love giving out compliments and telling people what a good job they're doing, it's far less fun to tell them when they're not doing so well. However, communicating constructive criticism is the most important responsibility you have towards your mentees, the clients and the company, and learning to do it well is essential for your success as a mentor.

Here's some advice, but keep in mind every person is different and responds to feedback differently, so you should always adapt your communication style to the receiver:

  • Give feedback immediately. When you see someone underperform, it can be tempting to wait for the next one-on-one to tell them, so that you can monitor the situation for a longer time and collect your thoughts. However, this can actually be damaging, because it allows the issue to become even larger. Learn to trust your gut and communicate feedback immediately, or after a short consideration.
  • Praise in public, criticize in private. Most people are okay with and appreciate being praised in public, but criticizing someone in a public setting can actually make them feel like they are being shamed in front of everybody, so don't do that. When you need to provide negative feedback, do it in a DM or a private meeting.
  • Make it about growth. Frame any negative feedback you have in the context of the person's growth path: remember we're all on a journey, and maybe this person is just a bit stuck in theirs. Accompany the feedback with practical steps the person can take to correct their behavior, and make it clear how this will make team a better team member.

Most importantly: always keep in mind that feedback is a two-way street. When you criticize someone, really listen to their response, because it might indicate that there is a larger problem in the project or in the company. For instance, if an engineer is skipping most of a project's standups, your first thought might be that they are not responsible enough. However, this might actually be a sign that the standups are not structured properly and the person is skipping them so they can focus more on writing code than attending a one-hour status report that doesn't add any value to their work. As you can see, you should always be on the lookout for any external factors that might cause a team member to struggle.