You make reasonably complex decisions every day, but knowing exactly how much time to spend on these decisions is difficult. In today's episode, I want to give you a blueprint for that middle of the road decision that you're probably going to face all the time. We're talking about this decision type happening about three or four times at least in a given week. My name is Jonathan Cottrell. You're listening to Developer Team. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. This is a very simple framework for making these decisions. These are not inconsequential decisions. In fact, when you stack these up, they have a lot of consequence. It's important that we actually do some of them. But the problem is that most of the frameworks that we've talked about on this show even, they tend to have a lot of time spent evaluating all of the possible options, the pros and the cons, weighing all of those factors. Sometimes we just don't have time to evaluate all of that. But it doesn't make a lot of sense to just go with our gut either. It's also problematic. It's probably not a good idea just to take a vote. Although this strategy, this blueprint that I'm about to give you actually leaves the door open for each of these types of decision making. This blueprint is extremely simple. First, decide what you want to optimize for. Hopefully this is one, maybe two or three things at most. Second, choose heuristics or simple razors, simple rules of thumb. These are the three things that help you gather the most relevant data, even if it's incomplete, that speaks to the things that you want to optimize for. Finally, make the decision based on the relevant information you found. So let's play this out, this simple blueprint. Let's imagine that you have two different options that you are evaluating for the products that you're building. One option is going to increase the... technical debt a bit, but it will deliver, let's say, in half the time. The other option will not increase the technical debt. Of course, it'll take twice the amount of time. So let's talk about different things we could optimize for. Of course, there's the obvious things like we want to optimize for as little technical debt as possible. Well, this almost becomes its own razor. Of course, you would choose the second option. But usually, we're trying to optimize for something that's a bit more intractable. For example, as little technical debt as possible to maintain a good customer experience. In this scenario, then you might have to dig a little bit further to understand your customer. Is it going to be okay with your customer to have a delay on delivering those features? Next, you might gather some information about the difference, the delta, between the customer's happiness of the two options. Let's say, for example, that the customer's happiness is relatively the same. Maybe they're slightly less happy, but not much. This leaves us with, yet again, a difficult decision to make. Yes, we could probably maintain most of the customer happiness and not increase our technical debt. But are we supposed to maintain most or all? You need to be clear about your options. You need to be clear about your optimization statement. If your goal is to never have the customer happiness slip, well, this becomes a different problem entirely. This means that you always have to keep the customer completely happy. But this is where your decision-making should start to include external factors, such as the second-order effect of that technical debt. If you increase technical debt today, what are the odds that you might lose, that customer's happiness down the road, in a more catastrophic way than you would in this particular case? Most decisions in this category don't rely on absolutes. In other words, it's very unlikely that a zero-tolerance policy is going to be useful in these heuristics. Instead, these heuristics are not following rules. They're providing rationale. They're providing rationale. The way you think about this problem of keeping your customers happy is complex, but you can use the heuristics to make it simple. For example, let's say you were talking to your colleagues about the decision that you've come to. It would be totally reasonable to everyone involved if you said, in order to reduce the risk that our customers will be unhappy in the future, I've decided to go with the option that, that reduces the technical debt. This is partially because we have good reason to believe that our customers are not going to be incredibly unhappy with the delay of these particular features, but also because it's completely conceivable that a future problem caused by this technical debt would in fact create increasingly unhappy customers. If we, however, encounter strong evidence that our customers are going to be unhappy with this delay, then we should be able to say, we should discuss that further. This kind of dialogue that you have with your colleagues is essentially talking about predicting the future. When you have these discussions, you should also reinforce the fact that everything that you're saying is based on probabilities. It's based on guesses, and that it's still possible that the outcome of your correct decision isn't good. We've talked about this quite a few times, on the show, but a rational decision doesn't always pan out. And this is why it's important to understand those probabilities. And it's also important to understand that you are optimizing for something. Let's play a hypothetical scenario where you have a 51% chance of success and a 49% chance, of course, of failure. Let's say your boss has entrusted you with, you know, a huge portion of the budget for the year, and your 51% chance of success is a particular bet that you're considering making. The catch is that it takes the entire budget. Now, there's some school of thought, some rational school of thought, that says that the correct decision would be to take the bet. You have the odds in your favor. However, a more realistic understanding of these odds would probably shy away pretty quickly. And in fact, it would take much more than 51% chance or odds of success to actually make this bet. All of this ultimately means that even though you are more likely to succeed in this bet that you're getting ready to make with this large sum of money, that you still probably shouldn't take the opportunity. Because the downside, the risk, is incredibly high. Most people could probably intuitively guess that. And this comes down to the optimization question. Are you optimizing to reduce risk? And if so, what are your heuristics? In other words, how much less risky would it need to be for you to accept the bet? Start with this optimization question and then move on to the heuristics that will help you determine how your options stack up. for that particular optimization. Thanks so much for listening to today's episode. Hopefully this basic idea of a blueprint is helpful for you when you're making those kind of intermediate level decisions. The ones that take a little bit more thought, a little bit more time, but the same decisions that can also be prone to over-analysis. Hopefully this little middle ground blueprint will help you out. Thank you so much for listening. If you enjoyed this episode, I would love to have you. Join the Developer Tea Discord. Head over to developertea.com slash discord to do that today. And of course, one of the best things you can do if you enjoyed this episode to help us out is to leave a review in iTunes or whatever podcasting platform you use. Thanks so much for listening. And until next time, enjoy your tea.