One of the most important things you'll do in your whole career is participate in feedback sessions. And in good feedback sessions, things look very different than they do in bad feedback sessions. That's what we're talking about on today's episode. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. And in today's episode, we are talking about feedback. How to build a good feedback mechanism. If you are like most people, myself included, by the way, when you hear the word feedback, you have an immediate negative response. Maybe because of something that has happened previously or maybe because of some mental picture that you've built up about your workplace or about what feedback really means, this picture that when things are good, we stay quiet. When things go poorly, that's when we need to talk. And so when you hear that someone wants to provide you some feedback, the feeling that we might get, that a lot of people get, is one of fear. So how can you give feedback better? And how can you be on the receiving end and receive feedback better? That's what we're talking about in this episode. So first, let's take a step back and talk about what feedback really is. Feedback on its own is a term that's used in communication modeling. The idea of feedback is that there is a message that is being sent by some messenger. And that messenger has some kind of audience. Once the audience receives the message, they provide some kind of you guessed it feedback. So how does this fit with our working model? Well, the message is that we are sending are not intended for a particular audience, most of the time. Most of the time when we do our work, we're not trying to elicit positive feedback. We're trying to do our jobs. And so when we can understand that a feedback session is actually more like an original message session, we can start to look at feedback a little bit differently. This is especially important for managers. Managers when you provide feedback to an individual to a direct report, you have to understand that that person may not be expecting that feedback at all. And instead of seeing it as a response to something that they did that the direct report did, they might see it as something that you decided to do out of your own making, out of your own volition. And this is important because if they don't see this as a reaction, right, if your direct report doesn't understand that this is feedback is directly related to something that they did and you're trying to empower them, they might put up their guard. And the whole idea of feedback is to provide a loop that is invited. Otherwise what we're doing is we're creating messages and calling them feedback. So it's important to make feedback a collaborative process. That's the first tip that I'm going to give you today. Make your feedback a collaborative process, especially if you're a manager, but also if you're the person who is typically receiving the feedback from your manager. We're going to talk about how it goes the other direction as well later on in today's episode. But if you're the direct report, right, and you are receiving feedback, or if you are the manager who's giving that feedback, it's important to recognize the point, the whole goal of feedback. And that is, and this is tip number two for today, future focused feedback. The whole point of providing feedback as it stands in our modern workplace at least today is to improve, to make slight adjustments or to have a moment of relational connection. Maybe the feedback is as simple as letting someone know that you thought what they did was excellent. That's totally valid feedback and it serves a purpose that is still future focused. And the only way that you can be future focused in your feedback is to be collaborative about it. So how can you be collaborative? There are some very simple ways. For example, if you're a manager, you might ask your direct reports, how do you like to receive feedback so that it's most actionable for you? You might even ask them directly, how can I provide you feedback in a way that doesn't set off alarm bells? How can I provide feedback to you so that you can hear it best and so you don't feel attacked or you don't feel like I'm giving you a warning or some kind of negative signal that's putting you at risk? Now, that's not to say that you'll never have a conversation like that, a critical conversation with your manager or with a direct report where something is on the line, where something has gone terribly wrong and it needs some critical attention. But most of the time, those kinds of conversations, you can see them coming from a mile away. And instead, what you're looking for is ongoing iterative feedback. We're going to take a quick sponsor break and then we're going to come back and talk about the most common misconception and therefore problem in feedback sessions. Today's episode is sponsored by Red Hat. Command Line Heroes is an original podcast from Red Hat about the people who transform technology from the command line up. Command Line Heroes returned to this past July 14th of last week to explore the job of being a coder. Author Clive Thompson joins host Serranya Barak to share his insights from over 200 interviews with coders for his latest book. The three episode mini season will cover the mini-pass to a coding career, where coders work and what coders expect from each other. That's an important topic. Past seasons have ranged from the history of open source to the origins of popular programming languages and, most recently, the creation of revolutionary hardware. Head on over to the podcast platform of your choice to listen and to subscribe to Command Line Heroes. If you had to guess what the most common mistake that people make with feedback sessions, what would you guess? You can probably think back to a feedback session where you were on the receiving end and it wasn't very good. It felt bad for some reason. Maybe the person that was talking to you wasn't necessarily wrong about what they were saying, but it felt like it wasn't useful. You weren't actually going to be able to go and do or implement whatever that person was talking about. The biggest problem with feedback sessions is quite simply that they are a one-way monologue with no particular output. This is the way that feedback tends to go. I have some feedback for you and then I'm going to provide it to you without any particular action point, without any specific way forward. In fact, I'm going to provide you feedback that is more of a reflection on what I thought than it is on what I believe would improve your efforts. This is so critical to understand. A feedback session should not be an exposition of the person who is giving the feedback's feelings. Now, let me take a step back for a second because there's an important point in here and that is not to hide those feelings or to remove them from the feedback session, but instead to take it to the next point. It does make sense. In fact, this is often missing to explicitly label the things that you're feeling as a part of your feedback. This is one part of nonviolent communication. This is not something that I invented, not by a long shot. The author Marshall B. Rosenberg wrote a whole book on the subject. But one particular theme that stands out is the idea of labeling and specifically identifying your emotions to the other person. And specifically, the emotions as they connect to the other person's actions. So it does make sense to share this. I felt frustrated when you said x, y or z and then explain why you felt frustrated. What is the impact? Or on the converse, I felt very excited when you said x, y or z because, and once again, the positive impact. Or you may have something that feels a little bit more mellow somewhere in between. I felt confused when you said x, y or z and then explain the question that you had in your mind that couldn't be resolved. These are the starting point and often where most people stop. In fact, most of the time people don't even say that they felt something. They just say that the other person was confusing. But they could work on being less confusing and then they leave it at that, right? But I encourage you to take it one step further. Invite the other person to solve the problem with you or invite the other person to discuss how they can continue on a good path with you. So this is a conversation, a back and forth conversation rather than a monologue. I felt confused when you said x, y or z. What do you think would help me be less confused in this conversation? What am I missing here? These are the kinds of questions. This is the kind of feedback that invites the other person into problem solving mode, which has been shown to help someone exit that fighter flight protective mode. This is incredibly important to understand. When we are in conversation together, not only is it involving the other person so the power dynamics are much more fairly distributed in the conversation, but it also changes that person from someone who is looking for a thread to someone who is looking for an answer. If you do nothing else with your feedback sessions, point them towards the future. This is the best heuristic you can use to improve your feedback sessions. Think every feedback session about the future, which is fundamentally difficult to understand. And so when you do this, it forces you into a collaborative mode. It forces you into speculation rather than claiming that you know what's going on. A feedback session is a vulnerable time for both people and it's incredibly important that it goes both ways. That should not just be about a superior giving one of their subordinates some kind of direction. Feedback goes both directions and it's collaborative. This is what good feedback looks like. I hope that you can experience good feedback and perhaps you can even influence the feedback mechanisms that you use in your job day to day. Thanks so much for listening to today's episode. Thank you again to Red Hat for sponsoring today's episode. You can find command line heroes, the new podcast season from command line heroes, and whatever your favorite podcasting app is. Of course, you can also subscribe to this podcast Developer Teain that same podcasting app. Today's episode was produced by Sarah Jackson. You can find this episode of SPEC.FIM. My name is Jonathan Cutrell and until next time, enjoy your tea.