How to Give Feedback

November 24, 2020

Guitar Amplifier

Photo by Portuguese Gravity on Unsplash

Let’s face it: giving feedback is hard.

You want to help that teammate improve their coding skills. You want to tell your manager you feel like they don’t listen when you share an idea. You want to help the newcomer struggling with a concept on the team by sharing your experience.

But how do you do that without sounding like a know-it-all? Or sound like you are just complaining?

While I’m not an expert at all-things-feedback, I’ve grown a lot in the past several years concerning how I give feedback - from technical aspects to soft skills and professionalism.

I want to share some of the tools I have learned to help you give better feedback. Whether you are a senior engineer who just got promoted, a junior struggling just starting, or someone who finds it hard to articulate what you think is helpful, these are for you.

Make Sure It is Your Place to Give Feedback

Before getting too in the weeds, giving feedback needs to have proper boundaries itself. All the tools I share are just that - tools. You need to use emotional intelligence to understand when, where, and what kind of feedback is essential for your role and team.

If you are in a situation where you aren’t sure, the best thing is likely to talk to your manager (or someone from your companies people services team) for some help in understanding the situation. They are there to help you and will help you through it.

Start With a Question

There is a simple question that I have found helps EVERY time I give feedback to someone.

Can I give you some feedback?

It sounds like such a simple question. And it is! But it’s harder than you might think to ask. Instead, we ofter see someone’s behavior and decide you need to “show them the right way.” However, this is a dangerous trap.

When you give feedback without asking if you can, you aren’t respecting the other person. It is likely they aren’t ready to receive it! It’s unwanted! Unwanted feedback is much more like telling someone what to do than giving feedback. Unwanted feedback destroys trust.

If they say “not right now” or “no,” then give them the space they need. Don’t worry if the answer is always “no.” If they are never willing to receive feedback, they will never grow. And while sade, that is their problem. Eventually, it will catch up to them. All you can do is be willing to give thoughtful, honest, and humble feedback when they are willing to receive it.

So what happens when they say “yes”? Keep reading!

State an Objective Observation With Humility

Now that they are willing to receive feedback, you need to make sure your feedback is rooted in objective observations.

Let’s use a simple example. During a technical discussion about a problem, a developer was getting very passionate. This developer, let’s call them Todd, also talked over several others during the discussion - an unfortunately common thing in the tech world. After the meeting, you decide to give Todd some feedback on the event. You want Todd to know that it was frustrating when they talked over others in the group. You ask Todd if you can give them some feedback, and Todd is willing to listen.

Once we have Todd’s willingness to hear our feedback, how do we give it?

First, a warning to stay FAR AWAY from large sweeping generalizations! They won’t help the conversation or the feedback you are attempting to give. Examples might be:

  • Todd always talks over everyone.
  • Todd doesn’t respect other people.
  • Todd is a jerk.

Instead, tell them what you noticed. Stick to the facts. A good approach might be to start with, “I noticed that in that last meeting, you were getting a little heated. You might not have noticed it, but you were talking over a few other people.”

At this moment, we have only re-stated what took place. We haven’t judged Todd or their intentions. We haven’t even offered any suggestions or advice on what to do next time.

By starting with a question (“Can I give you some feedback?”) and then re-stating facts (“You were talking over a few other people.”), we have done our best to create a safe space to now share our real feedback - what to do differently.

Make A Suggestion In the Form of a Question

At this point in the process, I start to second-guess myself. Maybe my advice or feedback is stupid. Maybe Todd doesn’t respect me enough to listen. Or maybe Todd won’t do anything about it anyway.

There is where giving your suggestion in the form of a question is so useful. Instead of telling Todd what they should do, ask Todd if they think your suggestion is a better way of handling it.

As an example, instead of saying, “Maybe you should let other people speak for a change.” you could ask, “I wonder if you think it would be a good idea to let some other people share their ideas too?”

The best part of this form of feedback is that you aren’t telling Todd what to do or what to think. You have asked Todd to think about what they could do differently - just with a gentle nudge towards a specific action.

You do need to be careful, though! Asking questions like this can be interpreted as a manipulation tactic. Remember that your goal is not to convince someone of your ideal reality or to persuade someone to do something in a way that suits your needs best. All of your feedback should be centered around helping others grow. If it isn’t, then take a few moments to consider if you are giving feedback or just angry something didn’t go your way.

Offer Support

If your initial feedback is received well, offer to help further. Don’t leave your teammate alone with only feedback to get better - help them get there!

Support might be as simple as telling them you are happy to field their questions about a particular technology. It could be that you offer to coach them on how to communicate better in a meeting. It might be offering to do pair programming instead of just doing asynchronous code-reviews.

Keep in mind the support you offer needs to appropriate for your role within the team as well.

Going back to our example with Todd, maybe you could spend a few minutes debriefing why Todd got so heated. Was there a specific phrase or statement from someone that made him angry? Can you give Todd a tool for recognizing when a situation has become unsafe for others, and he needs to tone it down and re-center the conversation?

Giving Feedback Takes Practice

Just like coding, there isn’t a magic formula that will solve all your problems. Sure there are patterns and frameworks (just like in code) that can help you, but you have to give feedback to get better at it.

But where do you start? How do you start giving feedback without damaging a relationship or hurting your career?

Start with yourself!

Practice giving feedback to yourself. When you give yourself feedback, you will start to understand what phrases, tools, patterns, etc., help you or hurt you. There is a good chance that what is helpful to you will be helpful to someone else.

Practically one way to give yourself feedback is to self-review your code. Before asking for a review from a teammate, keep your pull request as a draft, step away from it for a few minutes, and then come back to review it in full. Try to review each line and think, “Would by teammates understand this? How could this be better?” You don’t need to take forever on this - just put a few comments (yes! comments to yourself) to get used to giving feedback.

You can also give yourself feedback at the end of each week. I know it seems silly, but take your journal and spend maybe 10-15 minutes giving yourself feedback on what you did that week. Did you do something awesome that you should celebrate? Is there something you could have done better? Is there something you think you could do in the upcoming week to improve?“.

You’ll get comfortable with giving feedback in no time.

Happy coding!

👋🏼 p.s. If you liked this post, you'll love my book, Code Review Champion! In it, I share everything I've learned from over a decade in the industry about building a code review practice to set you and your team apart!


If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.


Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.