One of the more difficult skills you can learn is how to be wrong. How to be when you are wrong. How should you react? How should you behave and interact with other people when you've recognized something that you need to take accountability for? We're going to do a little bit of an exercise in this episode. But I want to kind of differentiate this from a more in vogue concept, the idea of having a psychologically safe environment. Being afraid to fail or holding a blameless retro, these are things that we discuss regularly. We don't want our engineers, if you're an engineering manager, you don't want your engineers to be afraid to fail. This is a very common saying. You want people to be able to fail and learn from it. And so we have these blameless retros where we review something that has gone wrong. And we try to figure out what it was that caused the issue without necessarily making any one person the point of concern. But the truth of the matter. While these blameless retros provide, hopefully, a more. psychologically safe environment to fail in. The truth of the matter on the other side. Is that we do indeed make mistakes. We have the opportunity to fail every day. And very often the kinds of mistakes. That require some level of accountability are not the same kind. That you're likely to make. That you're likely to see in a retro. Doing something that takes down production. Is a rite of passage. You've probably done this before. And this kind of operational mistake or pushing a bug to production. These kinds of mistakes are the kinds that tend to feel safer. Generally speaking. It's a fairly rare occurrence for someone. To experience a. A. Significant negative job impact. Over a single bug. Over an incident that occurs. Or over one kind of mishap. The more common problem that we have. Is what we're going to explore today. The kinds of things that we make mistakes on. Or that we should hold ourselves accountable to. Are less about individual mistakes. And much more about. Systematic issues. Issues of repetitive nature. An example of this might be something like. A design decision. That your team made. And moved forward with. That's causing a performance problem. This is a situation where. Instead of saying. Oh look at us. We made a mistake. We must not have had our coffee that morning. You instead are looking at. A systematic decision that was made. You're judging. The intentional work. That was done. We're going to take a quick sponsor break. And then when we come back. We're going to do a little exercise. That will hopefully help you. Dig out things that you might need. Or benefit from. Taking accountability for. So. Let's get started. Today's episode is sponsored by. Jam. Jam is developer friendly bug reports. In a single click. If you're a developer. You probably are. If you're listening to this episode. You may work on a team. You may have a front end. Web product that you work on. And you probably have had. Quite a few bug reports. And the quality of your bug reports. If they're like most. Are all over the map. Maybe you get one from. An engineer that has all of the context you need. But more often. You're probably getting these. With very little context. Maybe just a text description. Maybe the screen shot is only partial. You don't know what kind of browser they're using. You know what kind of phone. Maybe they're on. On a mobile device. You have to go chasing information. And this takes up the majority. Of your bug resolution. And it's a little bit of a challenge. But it's a little bit of a challenge. But it's a little bit of a challenge. Think about it. Instead of fixing the problem. You're going to talk to the person. To try to figure out what the problem is. In the first place. And you go over weeks. Of back and forth. In ticket comments. And quick zoom calls. So many variables that you have to nail down. That can contribute to the application state. During a bug. Jam is solving this problem. By making it impossible. To file a bug issue. Without all of that information. It's a free tool. That saves software engineers. A ton of time and frustration. More than 75,000 people are using it. It forces the perfect bug report. You can't do it wrong. It includes a video of the bug. It includes your console log. Your network requests. All the information you need. To be able to debug it. Using Jam. You can go from having a bug report. To having something that's so descriptive. You can turn around and make an automated test. Just by copying the attributes. From the report. Go and check it out. It's at jam.dev. To get started totally free. That's jam.dev. Thanks so much to Jam. For sponsoring today's episode of Developer Tea. So the exercise we're going to do. Is to think about. The last time. Your work. Could have been called into question. And you probably have. A feeling of defensiveness. If this is the right selection. The right thing to think about. I want you to think about. Some time where you felt like. You had to defend your work. Where you had to defend your team. Or you had to explain. Why did something go wrong. And you had to. And the undertone. Of your explanation. Is well this wasn't. Really our fault. I can see how you would think it was our fault. But it wasn't really our fault. It was actually the fault of. And then you list. The systematic reasons. Or what led you to get to that place. And all of this information. May actually be true. All of the information that you. Identified in this list. May actually be. Accurate. And this is the kind of thing that we do in a blameless retro. It is a useful. Exercise. To try to recognize what kinds of systematic issues. Would cause problems like this. Because. The assumption. In a blameless retro. Is that. A we don't have any. Malicious people. Who would cause this problem on purpose. And C that we believe. That the people who are doing this job. Are competent. We are not here to litigate. Whether they are capable of doing the job. Instead we are assuming they are capable of doing a particular job. And we are trying to find the systematic issues. That result in these problems. Despite those three things being true. So we have. This baseline assumption. In a blameless retro. But I want you to. Take this idea. This feeling that you have of. Okay we kind of escaped. This idea. The pressure. We escaped the. You know. The sense of. Direct accountability. By focusing. The issue on. A larger thing. On a larger problem. Now here is the exercise. I want you to write down. Three things. Three things. That you personally. Could have done. Or can do. To improve the situation. This is a very simple heuristic. Three things. That take you towards. A better future. Or could have helped you avoid. A worse past. And here is the thing. We are not going to. Bring into discussion. Whether or not you think that those things were expected. Or a part of your job. We are not going to discuss. Whether there is hindsight. Is 20 20 here. Looking back. You could have done X. But how could you have known that you could do X. Those discussions are off limits. For this exercise. The goal here. Is to learn how to get comfortable. With. Taking responsibility. For. Something more than just a mishap. Taking responsibility. For less. Larger mistakes. Larger things that do have. Systematic interactions. What part. Of responsibility. Can you take. And the important thing here. Perhaps one of the most important parts of this exercise. Is that forward thinking. Responsibility. We are not talking necessarily about just falling on your sword here. That is not the goal of the exercise. The goal of the exercise. Is to try to improve. Not try to. Improve. What else needs to improve. Or what system should improve. But you personally. How do you grow and get better. From this situation. Focus on. That. Idea of three actions. That could take you in the future. And I would even say. If you are struggling. In which direction you should look. Then the future is almost always a better option. Taking you to a better. Place in the future. What are the three things that you can do. In response to this specific circumstance. That move you. Towards a better outcome. These three things. Will help you grow. Now this lens. Is going to improve. Your way of thinking. The next time you make a mistake. You will make another mistake. There is one lurking around the corner right now. If you don't like the feeling. That you have. When you are making excuses. If you don't enjoy. The fight or flight mode. Of having to justify. Why you went. The direction you went. If that is uncomfortable. Then I encourage you to get more. Comfortable. With the idea that accountability. Is. The other side of the coin. Of growth. Taking accountability. And recognizing. What went wrong. Accountability is not just saying. Okay you can point at me. For what went wrong. Accountability is saying. I am recognizing. What went wrong. And I am going to do something about it. I could have done something about it. I am checking into. What I could have done. Personally. To have avoided this mistake. Now. I am going to. Do something about it. But this is not. A one to one substitute. For something like a systematic investigation. There are indeed. Many system level effects. That would cause somebody. Who is very good at their job. To still fail. And those should be investigated. But you shouldn't only. Look at the ways. To hold a system accountable. Of holding yourself accountable. At the plinth of evolution. At the plinth of evolution. At the plinth of evolution. At the plinth of evolution. At the plinth of evolution. If you enjoy this episode and you'd like to listen to more episodes of this show, you can make sure you don't miss out by subscribing in whatever podcasting app you're currently using, your favorite podcasting app, hopefully, and you will get this show delivered to you every time we publish, which right now is on a cadence of about two episodes a week. If you enjoyed this episode, you can also join the Developer Tea Discord community. We're talking about these kinds of topics on a pretty regular basis there. It is not an overwhelmingly chatty. Discord is one that is full of meaningful content, but it's not just, you know, kind of surface level discussions. Usually people are asking meaty questions in the Discord community. Go and check it out. It's at developertea.com slash discord. It's totally free. We're not trying to monetize that community right now. We've made a commitment to make it a free resource for everyone. Who uses it? That's developertea.com slash discord. Thanks so much for listening. And until next time, enjoy your tea.