When something fails, we have the tendency, naturally, to believe that the failure was within our control, or that it somehow is our fault. We also have the tendency to try to shift that fault, especially in social settings. In today's episode, I want to give you a more nuanced view of how failure occurs, and hopefully some tools for thinking about failure, so that you can go into your next retrospective after your next sprint with some better tools, rather than just asking the question, what happened? My name is Jonathan Cottrell. You're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity. Perspective and purpose in their careers. In today's episode, I want to focus on this very simple tool. This tool is a conceptual tool. It gives you a model for thinking about failure. But first, I want to back up and talk about failure as the result of a functional process. We are all familiar with functions as engineers. And in this case, we're going to talk about how we can use the tools we have in our hands to function as engineers. And in this case, we're going to talk about how we can use the tools we have in our hands to this particular manner, I'm referring to kind of pure functions. A pure function is one that, given all of the same inputs, you will produce the same output. So in a way, we have a testing ground for functional input and output. But because of the amount of variability, we very rarely actually have the same output given the same inputs, at least from our perspective. And so this is why we end up having retrospectives that say things like, well, we did essentially what we've always done, but this time it failed. Or you might have two or three companies at a kind of a higher order level that are doing essentially the same things, but one company beats the other. And often these books are written about the secrets that that company used, the company A uses over company B, or the mindset or whatever other magic variables that company A has that are a benefit over company B. So I want to give you a model for thinking about failure and by extension for thinking about success. Really, this is a model for thinking about functional outputs of your efforts. And then I want to talk about how to use this model in a retrospective, particularly in a team retrospective. So the model is very simple. Because we're talking about functions, what we should be talking about is inputs for those functions. And then determining what exactly is the function part, what is operating on that function, or within that function. Is the function itself possibly changing? We'll talk about how that might happen in just a second. But first, let's talk about the inputs. The tool that I want to give you is kind of a matrix or a quadrant, right? So you have this quadrant is a representation of combinations of two binary states, right? So you can imagine the quadrant is essentially like four squares. And the bottom kind of axis, the x-axis, is going to be awareness. So you know about or you don't know about this particular input. And then on the y-axis, you have, again, a binary of control. So either you can influence or control this input, or you can not influence or control this input. Now, we're creating these as binaries. The truth is they're probably more of a spectrum. You may know something about the particular input, but you may not know everything about it, right? So awareness may not always be, you know, the same thing. You may not know everything about it, but you may not know it may not be complete. It may have, you know, partial awareness of that input or a flawed understanding of the input. Similarly, with control or influence, there may be, let's say, that it's a quantity, right? Maybe it's money, right? Resources. You have some influence over resources, but you don't have an infinite influence over those resources. So you can imagine, if you want to, that this is less of a quadrant and more of an actual quadrant. You can kind of imagine the kind of heat map where the top rightmost portion of the graph is the highest influence and the highest control, and the bottom leftmost portion of the graph is the least influence and the least control. But this gives us four categories of inputs. The first category is the kind of input that you know about, and you can control, that upper right quadrant. is the thing that we imagine is always true, right? This is the one that we intuitively expect. We imagine that the inputs that are affecting the thing that we want are within our control and that we know about all of them. Very often though, we ignore the other three quadrants. So moving from the top right to the top left is the inputs that we control that we don't know about, right? The inputs we control that we don't know about. For example, we can control our level of exhaustion. In other words, it's possible that we imagine that the amount of work that we're putting in is going to have the same outcome no matter what. But the truth is, in most cases, right, this isn't a universal truth, but in most cases, if you work yourself to exhaustion, the outcome, the output of that function of work is going to change, right? So this is an input that we might not be aware of, okay? There are other inputs that we might not be aware of. For example, we might choose a technology solution that we don't realize is limiting our capacity to move forward or to be more effective, all right? Moving to the bottom right, right? Let me make sure I get my axes right. The bottom right is things that we know about, but we can't control, right? Things we know about that we can't control. This might be, for example, the evolution of evolution, right? At the evolution of evolution, evolution of evolution, evolution of about but we can't control, right? Things we know about that we can't control. This might be, for example, the actions of a competitor. We might have very little or no influence over those actions. And by the way, going back to that top left, the things that we don't know about that we can control, there might be opportunities, right? There might be opportunities that we don't even realize are waiting for us that we could seek out. We have the agency to seek those out. For example, certain partnerships or you might have a technology that you could adopt that you don't realize that you could, right? It's kind of the inverse but it's the same kind of problem. The things that we don't know could greatly influence our outcomes but we do, we theoretically do have control over those things or we are controlling those things. So again, going back to the bottom right, right? These are the things that we don't have control of but we can control. We know about, we're aware of them. And by the way, in this category, we have a lot of things that we want to try to control, right? We have the illusion of control over the categories or over the bottom right category. We want to try to control the things that we can't. Now, a lot of the things in this category might be something that we have secondary control over. In other words, we have influence by some other process, right? Maybe those, those particular things are outputs of other functions that we have control over the inputs of, right? So we mentioned already that in this category might be the actions or the success level of our competitors. And we may have some influence over our competitors because we have some influence over the market in general, right? We might have some competing factors where we share some market space with our competitors. Maybe we're acquiring our competitors or even partnering with our competitors. In some way, right? So there are a lot of things that we have some awareness of that we don't have direct control of, but this goes back to the fact that, you know, control is very much a gradient. It's not necessarily a binary. The more control that we have over something, the more directly we can influence it. But the least, the less control doesn't mean we have no control or no influence at all. But in this category are the things that we know about and we can't control. Or at least we have a very limited influence on. And then the final category is arguably perhaps the most insidious. And that is the things that we don't know about and we can't control. In this category are things like randomness and entropy. There's a lot of kind of universal effects that we don't really have a way of measuring or predicting. And that second piece of not being able to predict something, it may not necessarily be an unseen force, but it's something that we couldn't ever have predicted. And that's the thing that we don't know about. Like social influences that are multiple orders deep, right? So we're talking about responses to other responses to other responses, social responses that kind of build on each other. These are things that are very, very difficult to predict, but can have profound influences on marketplaces and therefore on the things that we care about in our personal lives and also in our professional lives. We're going to take a quick sponsor break and then we're going to come back and talk about how we can build on these things. And then we're going to talk about how we use this tool during our retros. Developer Tea is supported by LaunchDarkly. LaunchDarkly is feature management for the modern enterprise, fundamentally changing how you deliver software. And here's how it works. If you've ever heard of feature flags, then you probably either have a good idea of how they work or a really painful history trying to figure out how to use them. So if you've ever heard of feature flags, then you probably know what feature flags are. They're a little bit of a pain in the ass to implement them yourself. LaunchDarkly enables development and operations teams to deploy code at any time, even if a feature isn't ready to be released to users. You can wrap your code with feature flags that you don't have to engineer yourself. And it gives you the safety to test new features and infrastructure to your production environments without impacting the wrong end users. And when you're ready to release more widely, all you have to do is update the flag status and changes are made instantaneously by their real-time streaming. So if you've ever dealt with feature flags that, for example, have either clashing logic or maybe they're cached somehow that you didn't realize they were cached, you're not going to have to deal with that with LaunchDarkly. With LaunchDarkly, you can innovate faster, deploy fearlessly, and make each release a masterpiece. Head over to LaunchDarkly.com to get started for free today. Thanks again to LaunchDarkly for sponsoring today's episode of Developer Tea. So we've talked about this matrix of inputs, the inputs that you know about and that you don't know about, and the inputs that you have control over and the inputs that you don't have control over. There's some really interesting kind of areas that this quadrant brings up. It's particularly interesting to think about the things that you have control over, but you don't realize have any influence on the outcomes that you care about. And so I'm going to talk a little bit about I can think of about a hundred of these right off the top of my head in my personal life, for example, the inputs that I don't realize have a lot of effect on, for example, my work. I found out later on in life than I should have that exercising every day has a major effect on my mental capacity. There's a lot of these other types of inputs that might fit in that category, but I want to focus instead for today's episode on using this matrix tool, using this matrix tool to improve your retros. If you're not familiar with what a retrospective is, the basic idea is after a failure, you come together as a team and you try to determine, okay, what exactly caused this failure so that either we can fix it, right? That's one important part of establishing a cause for the failure, and or we can improve on our process, we can improve on our hypothesis, whatever it is that we want to improve. Using the information that we get from the retrospective, right? Some people practice something specific called blameless retrospectives, which is where you come together, you examine as much information as you can, but you never focus on any particular person's fault. You just state facts in the retrospectives. These are pretty useful. I would recommend using this flavor of retrospective, but it's important to have good tools in your retrospective, good kind of insights. If you're not familiar with retrospective, you can use this tool to improve your your retrospective, because if you're not familiar with retrospective, you're going to need to use tools. You can think of this as a way of kind of filtering the data that you're using to perform your retrospective. So, we're going to use this quadrant that we talked about in the beginning of this episode, and again, keeping in mind that, you know, you have to think about these things in categories or else it can become overwhelming, but the truth is that most of these things are on some kind of gradient. All right, so if we can't determine what went wrong, maybe we have a retrospective, and we're kind of scratching our head, heads are not really sure. Maybe there's a lot of disagreement about what went wrong. A few things can be at play. Number one, it's possible that we're totally incorrect about the importance of the inputs that we've determined. In other words, we might imagine that the things that should be affecting the outcomes are more important than they really are. We're over emphasizing the importance of, let's say, testing or performance, and we're under emphasizing the importance of, let's say, user experience. Another possibility is that it's possible that the important inputs that do exist, we're completely unaware of them. We're focusing on the wrong inputs altogether, not just overemphasizing the right ones, but we're emphasizing a set of inputs that are having little to no effect on the outcomes. On our outputs, or maybe there is a very important one input that we're totally unaware of. What should we do in our retrospectives with this information in mind? If we have a clear indication that an input that we can control can be improved, we should focus first on how to improve that input. First of all, we should use this kind of matrix. We can individually control the inputs. If we have a clear indication that an input that we can control think about the different causes or the different inputs and categorize them to talk about with the group. You might give each category a number or a letter, for example, and say, okay, I think that this particular input fits in this category. And this, you know, maybe there are some unknown inputs that I've thought about, and I might bring those to the group, right? So that's a good kind of pre-retro exercise for people to do, especially if this is a particularly important failure that you're diagnosing. So if you have a clear idea of an input, let's say three out of four people in your group all agree that this particular input needs improvement, that it's important, then probably try to focus on improving that input, right? That's probably not a bad signal. If it's clear that an input out of our control has influenced our outcome, we should think about either a parallel strategy that reduces the importance or the impact of that input, or an out of our control that reduces the importance of that input. Or an upstream strategy that allows us to influence that input that we otherwise don't have direct control over, right? That's a lot of information. Let's break it down for a second. If something out of our control, if we know about something out of our control that has made our strategy, you know, not work well, whether it's, let's say another competitor has introduced a product that is directly in competition with ours, maybe they beat us to market, and now we're stuck with a product that seems obsolete, what are the ways that we can address that? Well, we can either come up with a different parallel product or a parallel strategy for marketing our product that sits in the same space, or we can come up with an upstream way of influencing how that competitor's product is positioned in the market. Again, we're talking about this from the perspective of running a business. We can talk about this from the perspective of a software engineer. Imagine that you had, let's say, an outage on AWS. This actually happened recently, right? And you want to protect yourself against, you're doing a retro and you're wanting to protect yourself against this. You don't have direct control over AWS, but you know about it, right? This is a factor that you know about, but you don't have direct control over in that, I think that's the bottom right quadrant, right? So we can either go upstream of the problem and have multiple providers or maybe choose a different provider so that AWS can be able to do that. At the same time, you may have toension yourijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij we can either control or not control. But what about the things that we don't know about? If nothing obvious is popping out, if people are trying to fight for whatever their particular input is that they believe is influencing this thing, it's time to ask together what other inputs might be influencing our outcomes. If you did this exercise in advance, then it's possible that other people already have their ideas of what might be influencing the outcomes. It makes sense to review this together to discuss why we think these inputs are important, discuss whether or not the inputs themselves nullify other inputs. So if you bring out something that is important that is unknown, or at least is unknown up to this point, it's possible that it competes with the importance of another input. And then finally, we can explain how we think that the function itself is working. So what does this mean? Well, when we talk about inputs, we're talking about kind of situational things, or either situational or our actions. Sometimes the function that we're using in this paradigm might be the market. As the market changes, the way that it responds to particular inputs might change as well. Ultimately, there are things that we think are important that we can do to help us improve our outcomes. And so we can think about how we can control, and there are things that we can't control. And there's information that we can clearly see, and information that we can't see, or that we haven't seen yet. In all of this, there's a lot more going on with a given effort, with a given failure, or a given success, than what we might intuitively think. This is important to recognize because the other tendency that we have as humans is to believe that we can control, and there are things that we can't control. And there's information that we either have total control, or we have no control over the outcome of something. That either we succeed, and therefore it was because of something that we did, or often when we fail, we blame things that are out of our hands. But there's a more nuanced picture, and if you can focus on that nuanced picture, create a lens that allows you to see more detail, then your retrospectives and your kind of problem solving, your iteration is going to be more informed and likely more successful. Thanks so much for listening to today's episode of Developer Tea. Thank you to today's sponsor, LaunchDarkly. You can get started with feature flags without going through the pain of making them yourself by heading over to launchdarkly.com. That's totally free to get started. Thanks so much for listening. And until next time, enjoy your tea. Thank you.