Be prepared when giving negative feedback

Problem

"I had noticed that when giving negative feedback, I would usually start with positive feedback before diving into the real message that I wanted to share. However, this approach just delays the negative feedback and is not efficient. We had one engineer who had come from a smaller company and who was very feature-driven. Our team works on an older codebase, where the focus is about code quality and good architecture. Team members started complaining to me about the way the engineer was working."

Actions taken

When giving negative feedback, I usually start by organizing my thoughts in a spreadsheet. I start by writing my expectations, what the staff member has been hired for, and how they are not performing as expected. I then have a meeting with the underperforming staff member and start by asking how things are going. The idea is to see if they bring up some of the written points. If an engineer is aware of a problem, then they are halfway to finding a solution, so I then ask what have they planned to do to improve. If they don't mention any problems and they think everything is going well, I start with what I have to say. I see if they agree and I get their side of the story and then I try to work on a solution with them. I usually set a follow-up date to check on whether things have improved.

Lessons learned

"Using a spreadsheet has many advantages. It helps me organize my thoughts, it's a record of what has been said and it avoids the need for anyone to take notes. After the meeting I add details about what has been said, ensuring I mix negative and positive feedback, and then share the document with the underperforming team member."