How can a concept mean so many different things for different people? Why does feedback cause to fear for some and productivity to others?
In today's episode, we're talking about why we feel fear during some feedback sessions and how we as employees can facilitate healthier feedback sessions.
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Sentry tells you about errors in your code before your customers have a chance to encounter them.
Not only do we tell you about them, we also give you all the details you’ll need to be able to fix them. You’ll see exactly how many users have been impacted by a bug, the stack trace, the commit that the error was released as part of, the engineer who wrote the line of code that is currently busted, and a lot more.
Give it a try for yourself at Sentry.io
When I say the word feedback, there are people who are listening to the show right now who will feel anxious. And there are also people who are listening to the show who have a strong affinity and appreciation for the word feedback. How can a single concept mean such different things to different people? And we aren't talking about a politically dividing concept here either. Feedback is something that we all can benefit from in practice. So why does it cause fear for some and excitement or productivity for others? We're going to be talking about feedback in today's episode and specifically diving into why feedback can feel a little bit scary, why it can be intimidating to go into a feedback session. And then we're going to talk about ways that you can fix that, that you can run better feedback sessions. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on the show is to help driven developers find clarity, perspective, and purpose in their careers. If you work in a company that has a traditional management hierarchy where you work on a team and that team is managed by you guessed it, a manager. And then those managers may have executives or vice presidents above them. This is a common hierarchy. If you work in a company that has really any kind of hierarchy at all, it's very likely that you have had a one-on-one meeting. Even if you haven't worked in a company that has a strong hierarchy like this, you probably do have one-on-one meetings, whether they're formal or not, with co-workers, no matter where they are in the power structure of the company. And in these one-on-one meetings, very often, especially for those that are structured properly, there is time set aside for feedback. Now, of course, not every company practices this the same way, not everyone calls it feedback, even, and sometimes the feedback session is implicit. Sometimes the feedback session is pointed at someone who is not present for the meeting. But ultimately, in these kind of intentional meetings that are centered on work, some kind of feedback is likely happening. In today's episode, we're focusing more on this intentional feedback. You may have experienced feedback like what we're talking about in today's episode if you've ever had something like a performance review, or if you do have a common practice of providing explicit feedback in one-on-ones, another example of this is having a retrospective. It's a little bit of a different format for feedback to come from multiple people in a meeting. It's not necessarily in a one-on-one. There's so many different forms of this, but all of them have some similar components. Generally speaking, the feedback is some kind of commentary, some kind of discussion about previous events, something that has happened in the past, with some kind of intent to either change or reinforce. Consider those two outcomes and always remind yourself of those two outcomes. Am I shifting, am I adjusting, in response to this feedback? Is that the point of this feedback? Or is the point of this feedback to reinforce something that I'm doing or that we are doing as a team that we should continue doing more of? So you're probably listening or thinking, okay, so far so good, but this isn't really what my feedback sessions look like. So I want to take a moment and dive into why feedback can be such a nerve-wracking thing. When you hear that you have some feedback coming down to you from a manager, or maybe even coming up to you from someone that you manage, this can cause anxiety. We've said it over and over in this episode. Why is that? We're going to talk about exactly why we're going to try to break that down right after we talk about today's sponsor, Cintry. Speaking of feedback, Cintry provides you a different kind of feedback. It comes from your application. Now, unfortunately, a lot of people are relying on their users for feedback. And specifically right now, we're talking about when your app fails, when you have shipped bad code to production. A lot of times, we don't know about the bad code that we shipped to production until we get that feedback from our users. Now, a lot of people are probably thinking, well, there's better ways to get that feedback. Maybe a QA team, for example, can provide you feedback. But the problem is that even with QA teams that are exhaustive in the things that they do to QA your product, they still can't cover every single base. There's always blind spots. There's always ways that users will interact with your product or there's context that they're interacting with your product in that you may not have thought of. And so it's important that you have another way, another channel of feedback to help you determine what to do. Century provides exactly that. Not only do you see the error message, but you also see the full stack trace, you get a link to the commit that to the code that is actually causing this particular error. And you get to see who committed that code. So you can triage the code as quickly as possible. Go and check out what Century has to offer. Head over to centreet.io to get started today. Next again to century for sponsoring today's episode of Developer Tea. So I want to take some time to break down why feedback sessions can be so nerve-wracking. And then in the next episode, we're going to talk about how to fix those problems, how to actually run a good feedback session. And that episode will have a lot of practical tips of ways of framing things, using particular types of language, you know, posture and all of these things we're going to talk about in the next episode. I want to explain this division of why feedback can be so nerve-wracking. The reality is when we hear the word feedback, we fill in with different definitions. These definitions are based on experiences that we've had in the past, but also based on our kind of pre-wired sense to avoid dangerous things. We are wired to avoid danger before we are wired to seek improvement. And let that sink in for a minute. We are much more motivated by avoiding danger than we are motivated to seek improvement. And so it's natural for us to start with the filter, with this mental kind of screening to determine is this situation a threat. And so when we hear feedback, we're actually filling in the definition with something different. Probably something like judgment, for example. Judgment is quite different from feedback. And depends on one person having some kind of absolute standard. And it depends on them being able to apply some kind of moralistic language based on that standard. At least for today's episode, that's the definition that we're going to use here. When you think about a feedback session as someone providing you an absolute judgment, then it should be natural that we would fear this. The source of basically all anxiety, not just when we're talking about feedback, is our brains tendency to predict and imagine a future that is dangerous. This is again kind of a wiring in our brain to avoid dangerous things. We imagine scenarios that may occur that would be dangerous. This helps us understand how we might interact with those scenarios. So it's quite useful. You really can kind of thank your brain for doing its job whenever you feel this little bit of fear. But often, the fear that we feel is not only irrational, right? Our anxieties about something are not rational to the actual risk of those things occurring. But this anxiety also depends on a wrong definition of feedback and what feedback should be for. Bad feedback is about passing judgment. It's about having kind of a turning point, a moment in time where everything falls apart. This is some kind of event that you're predicting where you will hear bad news, where some kind of negative effect will fall into your lap and into your life. Now this is a bad version of feedback because it's focused on punitive action or some kind of negative turning point. And feedback, in most cases, is focused on improvement. It's focused on opportunity. It's focused on growth. So if you are a manager who's listening to today's episode and you have feedback sessions that you can visibly see, for example, that the people that you're providing feedback to are nervous. It's important that you establish a culture where feedback is pointed at growth. It's not pointed at judgment. It's not pointed at evaluation, but instead it's pointed at improvement. Now, this may seem like a simple shift or positive psychology and language rather than a real and tangible difference. But in the next episode, we're going to talk about those real and tangible differences. How you can provide effective feedback that is not only not going to incite fear for the people who are receiving it, but it also can be the absolutely critical turning point for your company, for your personal relationships, for you to understand how to properly provide feedback to another person and how to properly receive feedback from another person. This is kind of a superpower. This is something that is incredibly important for developers and non-developers alike. So I hope that you will listen to that next episode of Developer Tea. I really hope that you are providing an opportunity to practice this new way of thinking. For today's episode, the action will take away is to think about the moments of feedback that you have with your team, with the people, and interpersonal relationships that you have, and I want you to imagine how you may shift those moments of feedback away from judgment and towards opportunity. Thank you again for listening to today's episode. My name is Jonathan Cutrell. This is Developer Tea. If you don't want to miss out on that next episode about feedback, I encourage you to subscribe and whatever podcasting app you are currently using to listen to this. Thank you to Century for sponsoring today's episode. Go and find out about errors before your users have to provide that feedback to you. Head over to Century.io to get started today. Today's episode wouldn't be possible without spec.fm. Spec is built for designers and developers just like you to level up in your career. Spec has loads of other great content, including every episode of Developer Tea, but also other fantastic shows like React Podcast, Tools Day, Framework, and Design Details amongst others. Go and check out everything on spec.fm and of course at spec, we have our wonderful producer, Sarah Jackson. Thank you so much for listening to today's episode. And until next time, enjoy your tea.