As a manager, you probably heard many times that employees want to get feedback – no matter whether it’s positive or negative.
I am not sure that’s completely true. People don’t like to get feedback as much as they like to get validation and praise. Or maybe that’s just me. But feedback is the next best thing.
When I was starting out managing people, I struggled with giving negative feedback, especially to good engineers. By negative feedback, I don’t mean nitpicking about which library the developer chose or proposing an alternative way to structure a database. That’s easy – it’s a discussion. Also, if I managed a developer who wasn’t good from day one, it was kind of easy to pack the feedback into “this is how we do things here and I kindly ask you to do the same”.
But, how do you tell something bad to a developer who’s been on your team for months or years, about whom you have a lot of nice things to say. And especially, how do you tell them something bad that’s more crucial than a single coding choice. You would feel bad if they felt unappreciated! The nightmare scenario is that you work up the courage and tell them your complaint, and they just say: “OK” and walk away. Or, even worse, they respond in a way that catches you off guard, and mid-feedback you regret ever coming in to work that day.
So, how do you give negative feedback effectively?
Firstly, go back to your engineering roots. If you filed a bug report that read: “This feature you built sucks!!!1! You suck too! Fix it.”, the developer would be hurt and wouldn’t know how to fix it. But, if you structured your bug report into a well-explained format that lets the developer understand the bug and confirms the expected behavior, the bug will be fixed and nobody’s feelings will get hurt. Do the same for feedback.
Firstly, don’t wait for a performance review to give your feedback – that event is for recapping, not original content. Whether your complaint is about some particular task or the developer’s approach in general, you should give feedback as soon as you notice the behavior. Even for a recurring thing – give feedback as soon as you identify a pattern. If you found a bug in the software, you’d file it right away, and you wouldn’t let it linger for weeks or months.
When you are ready to give feedback, structure what you are going to say. In my experience, covering the following is always helpful:
- State the problem – start directly and to the point. If you spend the first 15 minutes beating around the bush whatever topic you bring up after that will weigh even heavier. All the caveats and clarifications and assurances you come up with will not reassure the developer – but put them into a defensive mode, instead of conversation mode.
- Why is this problem important – the engineer might have known about the problem, but they never took it seriously. Besides, it’s an instinct to try to downplay problems and focus on the positives. But, you have to help the developer understand why you are taking up their precious time. This brings us to:
- Why do I (the manager) care about this problem? Never throw your hire-ups or other team members under the bus by saying: “I don’t really care, but so and so from the C-suite told me to do something about it, so whatever, here I am doing something about it.” Your team member should understand that you care so they know you are an ally in helping them solve the problem and that they can turn to you for advice.
- Why should you (the developer) care about this problem? Of course, this shouldn’t just be a sentence like: “because you’ll be fired if you don’t fix it”, but rather, an explanation of why the developer themselves is not benefiting from this behavior long-term.
- Explain the desired output – just like a bug report that misses the “Expected behavior” section, negative feedback is meaningless without setting expectations about what needs to change. This is a way to ensure that the feedback is not personal, but rather, something that can be changed.
- Offer help and advice on how to achieve the desired output – at no point should you be anything but an ally to your employee. You should be their biggest fan and the first cheerleader and offer everything you can to help succeed. After all, that is your job description as a manager.
Let’s run this through a workshop exercise. Imagine a developer is overall decent – they usually get the job done and they are fairly fast. However, they often rush to implementation which is not thought out properly and which either causes a lot of bugs in testing or complicates the code unnecessarily.
You could set this the problem as follows:
“The last feature you worked on was not your best work. The first release of your branch was too buggy to pass one of the rudimentary user stories. The rewrite worked well, but it included a lot of ad-hoc changes so the code stopped making sense.” This is our problem statement. You follow by explaining why this matters: “I am coming to you about the problem because it caused a lot of unnecessary delays and we incurred some technical debt.”
Now you can breathe, the hard part is over. If a response comes your way – listen to it, take notes and encourage your colleague to keep talking. I can guarantee that nine out of ten times the response will be something like: “Ok, I agree.” The developer probably already knows all of this and will be relieved to clear the air. If they don’t agree – that’s fine too. Perhaps you really didn’t have all the information and the culprit of the problem is not your developer’s aptitude but it won’t really change the rest of the conversation too much.
Now you state why you care about the problem. This should never be an emotional appeal saying that you are disappointed or frustrated. Those emotions will come out of your posture and tone anyway. Saying something like: “I don’t have confidence in that code being correct and maintainable and it will negatively affect my ability to propose new features based on it” should be a good enough explanation. At this point, if you are keeping this a conversation and not a monologue, the developer probably offered why they care about the problem anyway. If they didn’t, do it for them: “you will have to maintain the code and any new feature will slow you down.” Nobody likes talking about development speed and productivity, but sometimes we have to.
Now comes the fun part: tackle the problem. A reasonable desired output would be that the next feature goes better. Tell the developer they should make it a challenge that the QA doesn’t find a single bug in their first pass at the feature, and remind them about architectural principles the code should adhere to.
Advise them how to do it. For example, for our quality issue, a proposal might be: “How about using a rubber duck approach to test the feature? Before coming to the stakeholders, showcase the functionality to a rubber duck and walk it through all the user stories.” This is way better than giving them empty compliments and “reassuring they are a valuable part of the team.” You will be showing them you trust them to fix the problem and that you are willing to invest time and effort into helping them.
Now both of you have something to work with. You can check in with the developer occasionally and see if your advice is working or not. The problem will likely repeat itself – but that’s ok. As long as the next iteration is slightly better than the one before and the developer is showing interest to fix the problem, things will get better over time. And you won’t lose any friends or allies along the way. I promise.