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 Cutrell, 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 particular manner, I'm referring to kind of pure functions. 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, and 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 one. And often these books are written about the secrets that that company uses, 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, right? 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? Awareness may not always be there. It may not be complete. It may have 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 graph that you can kind of imagine the kind of heat map where the top right most portion of the graph is the highest influence and the highest control. And the bottom left most portion of the graph is the least influence and the least control. But this gives us kind of four categories of inputs. The first category is the kind of input that you know about and you can control that up or right quadrant. This 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. So this is an input that we might not be aware of. 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. 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 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 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 know about where aware of them. By the way, in this category, we have a lot of things that we want to try to control. 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 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. 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 are 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 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 controller, 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 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 like social influences that are multiple orders deep, right? So we're talking about responses to other responses to other responses. People 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 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 and you probably either have a good idea of how they work or a really painful history trying 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 architecture. This is the part that you don't have to build. 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 fielously 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. I can think of about a hundred of these right off the top of my head and 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 that 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 and 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 that's one important part of establishing a cause for the failure or 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. 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 and you just state facts and 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 inspection 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. Alright so if we can't determine what went wrong maybe we have a retrospective and we're kind of scratching our heads are not really sure maybe there's a lot of you know 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 right 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 right another possibilities that it's possible we are that the important inputs that do exist we're completely unaware of them right so we're focusing on the wrong inputs all together not just over emphasizing the right ones but we're emphasizing a set of inputs that are having little to know effect on our outputs or maybe there is a very important one input that we're totally unaware of right. Alright so 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 right but we can first of all we should use this this kind of matrix we can individually 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 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 of the impact 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 that how that competitors product is positioned in the market again we're talking about this from the 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 is 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 a WS 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 outage doesn't really have an effect on us or we can choose a parallel strategy that doesn't rely on AWS as you know when it's down right we can have some you know I don't know for example some really serious caching right so that the whatever it is that we're trying to load loads in memory if it you a AWS is down or another parallel strategy that doesn't require AWS as a provider so this covers the things that we do know about that we can either control or not control but what about the things that we don't know about if if nothing obvious is popping out if people are trying to you know 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 right if you did this exercise in advance then it's possible that other people already have their ideas of what might be influencing now comes it makes sense to kind of review this together to discuss why we think these in these inputs are important discuss whether or not the inputs themselves nullify other inputs right 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 right 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 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 can control and there are things that we can't control and there's information that we can clearly see an 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 given success than what we might intuitively think and this is important to recognize because the other tendency that we have as humans is to believe that either we 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 ultimately 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 Teathank you to today's sponsor launch darkly you can get started with feature flags without going through the pain of making them yourself by heading over to launch darkly.com that's totally free to get started thanks so much for listening and until next time enjoy your tea