Giving Feedback
This blog post is Part 1 of the series Feedback for Engineers.
Feedback is not what is said, but what is heard.
When giving feedback, know that you are fighting an uphill battle. As soon as the human brain knows its world is being threatened, it kicks into fight or flight mode. Instincts take over. The brain has similar responses to physical harm as it does emotional harm.1 For those not used to receiving feedback, their brain may register it as potential emotional harm.
Your goal when giving feedback is make sure that your words are not just said, but that your message is heard.
There are the mechanics of delivering the feedback itself, but you should also keep in mind the context of your feedback. Do you have a good working relationship with this person? Do you trust them? Do they trust you? Your feedback will be taken in the context of your relationship. If you’re sniping them and they don’t know who you are, your feedback may not be heard no matter how well-packaged. Getting into the routine of giving someone else feedback can be great a way to develop a relationship.
These tactics apply to both types of feedback (positive and negative), although will be most useful when delivering critical feedback.
Do Not Delay
The single worst sin that I have committed regarding feedback is to delay giving it.
Our own brains find ways of making us procrastinate this. Eh, I’ll wait until next week. Many types of feedback become stale. It feels silly to give someone feedback on their microphone usage at a presentation 4 weeks after the fact. Now I’ll look weird if I bring it up. Oh well.
There are some things that require feedback that might require more observation. Even if something is a one-time occurrence, try giving the feedback. This might be as simple as an accidental interruption or a long-winded response to a simple question.
I have seen people keep a running Google Doc or notes in an app like Apple Notes of feedback they’d like to give. I’m a Google Docs guy. Writing things down is also a great way to make sure your message is well-packaged. Use tools to help collect your own thoughts, but do not use them as a /dev/null. By writing things down, you fight recency bias when it comes time for peer reviews.
Always in Person
Until you establish a very trusting relationship, always default to delivering feedback in person. There are a few reasons for this.
First, this helps eliminate misunderstanding. Textual forms of communication are lossy. Interpretations of different sentences and phrasings can distract from the true message.2 When delivering critical feedback, avoid lossy means of communication. By engaging in person, you’ll also get non-verbal cues like body language as to how your feedback is being received.
Second, it’s much more conducive to a conversation. Feedback delivered over email or Slack will be asynchronous by default. You will not know when they’ll receive that message: on the ride home, at home, or sometime during their morning routine. Having an asynchronous conversation about feedback is fine, but let the receiver make that distinction. (“Thank you for the feedback, please give me some time to process this.”)
There’s no one-size-fits all approach to this. Everyone will receive and process feedback differently. Keep in mind your audience, and tailor the message to their style.
Your Goal: An Actionable Shared Understanding
Your own mindset will also affect how the feedback is heard. For myself, I remind myself that I do not have the full picture. By reminding myself that we’re in this together, it helps me modulate my tone.
This idea is lifted directly from the book Difficult Conversations: How to Discuss What Matters Most.
We’re not just looking to say our feedback and get out, we want to position ourselves to work together toward a solution.
Actually Doing It: Situation, Behavior, Impact
When I need to give feedback, I look to line up the following:
- 15-30 minutes of free time for both of us
- A private room or a quiet place
- (Optional) Written notes of what I would like to say
In the perfect scenario, we hop in a room and go over whatever it is I’m trying to communicate. The conversation is respectful, understanding, and fair. We come to a shared understanding and shared view of the problem, and discuss potential actions if needed.
How do we develop a shared understanding? My preferred method is the Situation, Behavior, Impact (SBI) framework. The framework says the following: to deliver feedback, you need to cover…
- Situation (Objective) - Describe the situation in a way that no one can disagree with, sticking to the objective facts. There should be no disagreements here.
- Behavior (Objective) - Describe the individual’s behavior in the situation described. It can be very tempting to start with interpretations. Again, keep it objective. A passive bystander should be able to agree here.
- Impact (Subjective) - Next, describe that impact that you perceive. Feel free to use I think and I feel plenty here. The goal here is to ensure that your positions are communicated in a way that is framed well: People can’t disagree with whether you actually feels these things.
Let’s take a look at how this might play out in a few toy examples.
Example: Cutting Someone Off During Q&A
Jason, I’d like to give you some feedback on your recent presentation at the engineering all-hands meeting. Is now a good time?
(Situation) When you were presenting about a switch to MongoDB, Jane asked a question about the switching costs of this new technology. (Behavior) Before she finished, you cut her off. (Impact) When you cut her off like that, I think it detracts from your message and makes you look defensive. This defensiveness might lead to lack of trust among your teammates that MongoDB is the right tool for us. I think it might also hurt your relationship with Jane. How do you see it?
Here we have a simple situation of someone cutting someone else off during a Q&A session. This is the exact type of feedback that is best given closest to the time in question. We’ve separated the objective from the subjective with the SBI framework, and looked to develop shared understanding with the “How do you see it?” at the end. This is where the discussion begins, not ends.
Let’s do one more example, just for good measure.
Another Example: Site Downtime
Steve, I’d like to give you some feedback on your behavior during the recent downtime. Is now a good time?
(Situation) As we all know, the site went down for 30 minutes on Monday because our deployment framework failed half-way through a deploy. I know that you had raised the fragility of our deployment framework in the past. (Behavior) While the site was down, you dropped a message in the incident Slack channel saying “This would not have happened had we fixed the deployment framework like I said.”
(Impact) While you have every right to claim this, I feel the timing of this message hurts the dynamics of the team. Specifically in times of crisis, I feel this communicates that you are more interested in scorekeeping past decisions than fixing the site. This not only does not help us stabilize faster, but actively works against it: teammates now have to deal with technical problems and emotional problems in a situation where time is critical. How do you feel about your behavior in this situation?
This one is a bit more complicated (and serious), but also something that you’ll likely see as companies grow. Behavior like this—left unchecked and unaddressed through feedback—quickly erodes team morale.
Conclusion
By getting better at giving feedback, you will make sure the message is heard and not just said. Delivery of feedback is always the beginning of a conversation, not the end. Using a simple framework, you can make sure you don’t go off the rails yourself.
This post is part of the Feedback for Engineers series. Stay tuned for more!
Special thanks to Justin Duke, Emily Field, Omri Ben Shitrit, and Ketki Duvvuru for feedback on early drafts of this post.
Illustration by Ash Jin.