What is your relationship with mistakes? The thing about mistakes is that they will always happen. In today's episode, we're talking about acceptance of mistakes and how we can behave to deal with mistakes better.
imgix is the API for fast, responsive, optimized images. Your images create complex technical challenges. Our APIs solve them.
Listeners of Developer Tea can enjoy a $300 account credit when signing up for a new account!
Get that credit when you visit www.imgix.com/developertea
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
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.
What is your relationship with mistakes? What is your team's relationship or your company's relationship with mistakes? In today's episode, if you haven't thought about this before, you'll get a chance to think about it and to locate yourself on a scale that I'm going to provide of what your relationship looks like with mistakes. My name is Jonathan Cutrell, you're listening to Developer Tea and my goal on this show is to help driven developers like you find clarity, perspective and purpose in your career. So here's the thing about mistakes. It is invogue and it is certainly popular to accept that mistakes are going to happen. So I don't want you to check out too quickly because you've kind of jumped on that bandwagon. This is something that has been discussed a lot in podcasts like this. It's certainly been discussed in plenty of books. We talk a lot about the importance of psychological safety. In today's episode, we're going to take it another step further and not just talk about acceptance of mistakes. There's more to this discussion. There's more to how we should behave or how we can behave to deal with mistakes better. To have a better relationship with them. So hopefully you'll stick around as we go through this scale and there's five categories, five points on this scale that you can find yourself on. Almost certainly you'll find yourself somewhere on this scale. Now, of course, we're going to talk about it in terms of very discrete points on the scale, but this is a continuum. You're not going to act only one way. You're not going to fall entirely into one point on the scale, but I encourage you to consider how you might react or how you might behave to move to a new point on this scale if you don't like where you're at. So this podcast, this episode, is not intended to make you feel bad about where you are on the scale, but instead to try to provide a clear picture of the full scale altogether. So the idea is to zoom out of your own circumstance and try to imagine what other circumstances may allow. Now one thing that we'll note in advance before we get into the scale is that there's no point on the scale where you have escaped the relationship with mistakes. In other words, you will always have mistakes. There's no point on the scale where you will be able to break away and stop making mistakes. So that should not be a goal. As much as we want it to be a goal, it shouldn't be a goal. And part of the reason for that is because if we don't have mistakes, then we are probably not learning. We're not pushing past our previous barriers, not just individually, but as teams, and we're not helping others grow. Okay, let's get into the five stages of your relationship with mistakes. We're going to start at the kind of least healthy relationship with the mistakes. That is the stage one, this willful ignorance. Willful ignorance. You've seen this done before. You probably have done it at some point, and perhaps you regretted it. The idea here is that you just ignore the mistake. Whether that's a bug in code or some other mistake, some other fault, you are willfully choosing to ignore it. That's isn't because you're not aware of it. It's possible that you're not aware of a lot of mistakes. Which this kind of scale, you can't really have a relationship with something that you're unaware of. So we kind of ignore that for the sake of this episode. But if you're willfully choosing to avoid any kind of contact with the mistake, in other words, you're not investigating it. You're not trying to change it in any way. You're not trying to understand it in any way. You're just ignoring it. You're going about it. You're going about your job, you're writing your code as if that bug doesn't exist at all. You might ship that bug into production knowing it's there. Now, why is this an important state to bring up? Well, because this is something that we do more often than we realize most likely. We are choosing to prioritize one thing over another, understanding that there's a mistake that we're not rectifying. In some ways, this is actually functional. This is important to be able to do with the right kinds of mistakes. But the part that breaks down and what's unhealthy about this stage is the idea that we're choosing to stick our head in the sand, we're willfully ignorant. It's a little bit different to be cognizant of the mistake to understand it and to be able to categorize it into a category that says, oh, this is a low priority mistake, right? But that's not what the stage is. The stage one is willfully ignorant. So you don't know what the priority is because you're choosing not to inspect any further. Now, you can be on the opposite end of the scale and we'll talk about the opposite end of the scale shortly, but you could be on the opposite end of the scale and still choose to ship known bugs into production because they're low priority. Maybe you found work-or-owns or whatever the case is, but you're not being ignorant on that end of the scale, right? We're going to talk about that end of the scale, but understand that's willful ignorance is the idea that somehow you expect the universe or heard some other force to manage the mistakes for you. Now, what's strange is that sometimes that actually happens, right? Sometimes we ship a bug into production and then we write code, we rip out some old code, not even knowing that that code contained the bug that we shipped to production. And that bug, of course, because it's been replaced with new code, that bug goes away. So sometimes this accidentally works, right? But this is not by design. We're not dealing with our mistakes by design. We're dealing with them haphazardly or by chance. Okay, let's move on to stage number two. And this is still not a very healthy stage, but at the very least, we're not willfully ignorant. This stage is treating mistakes as anomalies. Treating mistakes as anomalies. The idea here is that when a mistake occurs, we consider it to be an exception. We consider it to be out of the norm. And so we don't plan for mistakes if we're in the stage, right? We end up having to work extra overtime because we expect that we can work at, let's say 80 or 90% utilization of our time and we'll be fine because we don't make mistakes regularly and so why would we build in time to deal with them? And this is where we find our problem, right? Because anytime a mistake occurs, not only do we immediately jump into kind of an urgent state, but we also don't plan ahead for them. Because if mistakes are anomalies, then on average, we're not going to have them, right? On the average day, we shouldn't spend extra time preparing for those mistakes because they don't happen often enough to prepare for them. Of course, in that stressful state, when we've made a mistake and we're already at our limit, we're having to fix our mistake above our limit. This is a critically important thing for managers, especially to understand. If you push your team to their limit, when it comes to a critical moment, like for example, if you ship a bad bug into production, but you're already at your limit, you're already pushing people to the point that they can't really give anymore. They're tired or they're mentally burned out. Then you're in a really bad scenario to deal with that mistake. Even though you're not willfully ignoring it, this is still a bad scenario to be in. This is still a bad relationship with mistakes because you're already at the limit. You're probably going to make another mistake. You can see where this goes, right? As we continue to snowball our mistakes on top of each other, rather than slowing down and having the head space to deal with them, those mistakes continue to compound. This leads to really bad culture. Of course, treating mistakes as anomalies makes people feel horrible. It makes people feel bad and not only bad, but also scared. They're afraid to make mistakes. We know from plenty of research, and we're already alluded to this at the beginning, that the opportunity to make mistakes is critical to success. It's critical to having an innovative and healthy team. This is something that has been shown in study after study. This is not novel. If we have people who are afraid because they think they're going to make a mistake and it's going to push everybody past their limit because mistakes are supposed to be anomalies, that's a really bad situation to be in, both individually and as teams. We're going to come back in just a moment and talk about the last three stages of your relationship with mistakes. But first, when I talk about today's sponsored Imagix, I've been using Imagix for a long time now, and I absolutely love Imagix. This is a product that's made for developers, but it has a super simple API. There's plenty of libraries for basically every language, pretty much every front-end framework, and they have a global image CDN. This helps developers deliver lightning fast sites and apps through automated image optimization. It makes responsive design and development easy. Images are automatically optimized for every browser and device, and it's used by thousands of developers from companies like Unsplash, Kickstarter, and Prismic. Here's the thing. The API for this is so simple that you can adapt it to pretty much anything you're doing. There's so many options, and it's all driven off of this parameter-based API. Just have to try it out to understand what I'm saying. It feels like magic every time I use it. Go and check it out. Head over to Imagix.com. That's IMGIX.com slash Developer Teato get started. I'll say one more thing about Imagix because it's such an important part of what they do. It's not just about optimizing photos for the web. You can also manipulate those photos with Imagix. There's all these cool filters, and you can lay text over the top of them, and you have to do basically none of the back-end work. You don't have to mess around with image manipulation libraries or anything like that. It's all available on Imagix. Of course, it's super, super fast. Let's talk about the last three stages of our relationship with mistakes. The third stage, we've already been through stages one and two. Number one was willful ignorance. Number two is treating mistakes as anomalies. Number three moves on from treating something as an anomaly, and instead, it anticipates mistakes. You're anticipating that they may happen. What happens when you get to an anticipation stage? This is where you might plan for the mistakes to happen. You might build in some overhead time to deal with the mistakes when they happen. You may even review mistakes as they occur, but most likely, most of what you're doing here is just allowing for mistakes to happen and not bearing down on people. This is really the culture shift moment. When you recognize that mistakes are not anomalies, you change over to believing that, hey, you know what? Actually, mistakes happen frequently. They happen to even the best engineers. They happen to the highest caliber talent in any field. We should prepare for them. We should plan for them. We should make space for them. We should not make people feel afraid to make mistakes. This is a massive culture shift, and you can imagine there's a rift between stage two and stage three where you change your mindset and your relationship with mistakes. But there's still two more stages to go, because here's the reality. Even though you make space for the mistakes to happen, you're not improving purely by making space for them to happen. And so if you're just anticipating the mistakes, if you're just making space for them, you're not changing yourself. You're not using the mistakes as a kind of jumping off platform for improvement, which is kind of the whole point. It's the whole point of allowing mistakes to be normalized in your culture so that you can improve. It's not just saying, oh, mistakes are a wonderful thing, and then you just let them happen. We need to respond to the mistakes in some particular way. So that stage four is responsive stage. Responsive stage, or you can also view this as kind of adaptive stage, right? When a mistake occurs, we change our approach. We might do a post-mortem in this stage. We might create some tests based on previous failures. We might see areas where we are weak, where that mistake is kind of costing us a lot of resources, and we might respond to that by improving in those particular areas. So this is a relatively healthy relationship with mistakes. That's where a lot of engineering, good engineering organizations end up sitting, right? Is in this responsive state where we don't know what the mistakes are going to be, but we know that we can handle them and we can improve in our handling of mistakes. All right. Stage five, stage five. This is kind of the best possible relationship with mistakes. That is to engineer the mistakes into your process. This is kind of the fully integrated stage where you are actually taking mistakes that haven't ever happened before in your testing against them. You might have some automated mistake generators, right? This is chaos engineering, falls into this category. You're creating new states, these are states that maybe you've never had before in the past. Those states are actually kind of bringing out mistakes that you've made, whether it's in your code or in your organization or in your personal life. You engineer ways to stress test any system that you are working with, right? So this is how you're being proactive in engineering mistakes into your process. At this stage, you might hold something called a pre-mortem where you try to imagine what are all the possible ways that things could go wrong. You're predicting future mistakes. Some companies that are at this stage will have people whose job it is to explicitly try to come up with an offensive strategy to disable their company. Of course, they're not going to employ this, but if they can come up with an offensive strategy that disables or otherwise could dismantle an effort at their current company, then their current company can defend against that in a novel way. So there's investment into understanding and preparing for future mistakes that we didn't even know were going to happen, or they may never happen at all. And you can see how this is almost in direct opposition, right? It's almost the exact binary opposite of stage one, which is willful ignorance. Here we are not only on the opposite end, where we're incredibly aware of the mistakes that are being made and we're responding to those, but we're also preparing and engineering new mistakes into our process so that we know how to deal with them if they were to happen. This is a predictive kind of offensive strategy that requires upstream thinking. It requires that we change the way that we interact with mistakes. We invite them into our thought process rather than waiting for them to happen as a result of a bunch of factors that we can't control. If we can simulate mistakes in scenarios that we can control, if we can lower the stakes of the scenarios where mistakes are occurring, right? And we can deal with them in a much more controlled environment. We can also prepare for them so that when they do happen in a higher stakes environment, we've kind of had a dress rehearsal, right? We know what to do if that occurs. So those are the five stages of a relationship with mistakes. And I hope that you found yourself somewhere on that spectrum. And I'd love for you to reach out and let me know where you're at, right? I'd love to know, you know, what is your relationship with mistakes? But also, how is it changing? How has it changed in the past? You can find me on Twitter at at Developer Teaor my personal handle at at Jake Troll. Thank you so much for listening to this episode. Thank you again to Imagix for sponsoring today's episode. Head over to Imagix.com, that's IMGIX.com slash Developer Teato get started today. Thanks so much for listening to this episode. This episode and every other episode of Developer Teacan be found on spec.fm. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell. And until next time, enjoy your tea.