If 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 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. 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. So it's important that we actually do some analysis, 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 of pros and 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 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. That can choose heuristics or simple razors, simple rules of thumb 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've found. So let's play this out, the 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, and of course it will 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. 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 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. 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 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 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. This is why it's important to understand those probabilities. It's also important to understand that you are optimizing for something. Just play a hypothetical scenario where you have a 51% chance of success, a 49% chance of failure. Let's say your boss has entrusted you with 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 rational 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, isn't incredibly high. Most people could probably intuitively guess that. When this comes down to the optimization question, are you optimizing to reduce the 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 overanalysis. 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, at over to developertea.com slash Discord, to do that today. And of course, one of the best things you can do if you enjoy this episode to help us out is to leave a review on itunes or whatever podcasting platform you use. Thanks so much for listening, and until next time, enjoy your tea.