A Method to Give Feedback
Tags: practices, career, softwareengineering
Published: 2023-08-08 18:43:21

---
title: A Method to Give Feedback
published: true
date: 2023-08-07 00:00:00 UTC
tags: Practices,Career,SoftwareEngineering
canonical_url: https://hceris.com/a-method-to-give-feedback/
cover_image: https://hceris.com/static/48445f65a23c4c13863a2af6367400f1/b4294/cover.jpg
---

Feedback, when used thoughtfully, is a superpower. It accelerates personal growth faster than anything you can achieve through introspection alone.

Over time, I’ve witnessed developers hinder their careers by repeatedly making the same fundamental mistake. Imagine influencing somebody’s trajectory by simply giving good feedback. That screams _Senior Engineer_ to me.

Why is it, then, that so many people wait until the last day before the performance review submission deadline to finally write down something that’s way too superficial to be useful? I don’t know, man. Maybe it’s for lack of a method? In this article, I’m talking about my approach to delivering feedback.

## What Constitutes Good Feedback?

There are two aspects of giving feedback:

- _The content:_ The observation you’re attempting to share
- _The delivery:_ How you share it with the intended recipient

Let’s begin with the content. You don’t need deep, career-changing insights to be helpful. More mundane observations are valuable and easier to come by. For instance, I tend to speak over others in meetings. While it might sound like a small thing to point out, receiving that feedback has helped me become more aware of it.

Be sure to refer to **concrete** events. Be as precise as possible to help the other person understand what you’re talking about. For the same reason, talk about **recent** events. Memory gets hazy over time. It’s significantly easier to discuss something when it’s fresh on your mind. At the same time, it’s probably good to avoid giving feedback _immediately_ after the fact. Waiting a bit helps cool down.

[![deer](https://hceris.com/static/b38a3efa4d78f577f78038f79c216ee8/acb04/deer.jpg)](/static/b38a3efa4d78f577f78038f79c216ee8/eea4a/deer.jpg)
_actionable insights_

Next, your input should be **actionable**. What’s there to do differently next time? A situation with no realistic alternative is a dead end. Feedback is about finding ways to improve yourself, not grading your performance.

Lastly, it should be **constructive**. _You suck_ isn’t feedback, even if you phrase it nicely. If you can’t find a way to frame it so that it helps the person grow, it’s probably better to let it go.

As an example of what _not_ to do, I remember a manager in a previous company telling me something akin to _Why do you repeat yourself so much?_, in a way that sounded more like an accusation than a question. I actually went and asked a few colleagues if they had observed this, as I was taken aback. That feedback didn’t land well at all.

In summary, keep the following in mind when preparing the content:

- It should be **recent**
- It should be **concrete**
- It should be **actionable**
- It should be **constructive**

## Situation-Behavior-Impact

Let’s say you have the content ready. The next step is figuring out the _delivery_. Giving feedback can be difficult, especially if it’s not positive. That’s why I like to stick to a structured pattern commonly referred to as **Situation-Behavior-Impact**. You have three distinct phases:

_Situation_ describes the context, so that the receiver knows what you’re talking about. This ties back to using a concrete example. Moreover, it being a recent situation means both of you are more likely to remember the details, avoiding misunderstandings. Your goal should be to set up the stage, not to bore the other person. After all, they were there as well. Make it as short as you can.

_Behavior_ is about describing the actions you observed. **Key** word being observed. Acting as if you know exactly what somebody else was thinking is condescending and counterproductive. You’ll probably be wrong, and it won’t land very well.

Instead of reading minds, focus on your observations. Make it clear that this is your perspective, which might be incomplete or even incorrect. Use a neutral tone and avoid making judgments. Your goal is to talk about actions.

_Impact_ is the last part of the puzzle. What did the previous behavior _cause_, on you or somebody else? Talking about impact can be uncomfortable, but it’s a necessary part of a complete piece of feedback. Based on this impact, the receiver can reflect and decide to do things differently the next time.

Similarly to the behavior part, focus on what you saw. Using a fixed structure can feel forced, but it ensures consistency. When you’re raising a thorny issue, this formula helps you concentrate on being as objective as possible.

[![impact](https://hceris.com/static/ca0e5798128350e9c518972780b90eee/acb04/impact.jpg)](/static/ca0e5798128350e9c518972780b90eee/eea4a/impact.jpg)
_Landing some impact_

Another example: I used to work in consulting. In my first project, we developed some CI/CD infrastructure for a traditional German company. I was a bit overwhelmed as I wasn’t familiar with the tooling. A senior colleague gave me some harsh feedback about me being hesitant to make decisions, which was diminishing my credibility with the client. It wasn’t easy to hear, I can tell you that much.

However, my colleague was structured in how he delivered the feedback. He was concrete about the meeting he was referring to. He described the actions he was seeing from me. Lastly, while he was clear about the impact it was having, he wasn’t judgemental. On the contrary, he was keen to support me. The structure made this tough message more digestible. Building a plan to address the issues felt a lot easier.

## Practice!

Sharing imperfect feedback is preferable to sharing nothing, as long as you remain respectful and constructive. Remember that any formula isn’t a substitute for practice. The only way to get better is to do it regularly. Don’t leave it for the last possible moment. Take notes and share them regularly, and it’ll progressively get easier over time.

I prefer giving feedback in person. I always thought that what you write for an official review shouldn’t surprise the receiver. However, if you feel more comfortable over chat or email, use that medium. Remove the barriers that are preventing you from doing it more often.

Another option is to go to the person’s manager directly and share the feedback with them. Honestly, that sounds very foreign to me, so I have a hard time picturing myself doing it. I believe that building trust with others to a point where you can freely share and receive feedback is a better long-term investment for yourself. But, hey, I guess that _some_ feedback is better than just eschewing the practice altogether.

## Beware of Rigid Formulas

Even though a structured method like **SBI** can help, you should be ready to abandon any method and be adaptable instead. Feedback is a very personal thing. People have different preferences regarding format, medium, or anything else. Adapting your delivery to accommodate these preferences will improve effectiveness. Especially so for people with whom you collaborate more closely and have more to share.

For instance, some resources recommend using the _feedback sandwich_, where you wrap a negative piece of feedback in between two good ones. I despise this method and find it fake and artificial. It just doesn’t work for me. Everybody has their anti-patterns, so it’s a good idea to figure out those over time.

Using a formula allows you to be consistent. However, it’s more important to be _genuine_.

## It’s Not Up to You Anymore

Alright, so your carefully crafted feedback is ready, and you go out and share it with the intended recipient. What’s next?

Not much, really. In my opinion, you did your job already. Now, it’s up to that person to digest it, reflect upon it, and decide how to act on it. It might well be that they choose to discard it. That’s not necessarily bad! Remember that you only have a limited view of how somebody else acts and behaves.