we've talked recently about the concept of becoming more action oriented and this is a pretty broad discussion and today I want to give you some practical tools that you can use on your teams in your discussions in your planning in particular to move your teams towards action orientation. For the sake of the discussion today I want to kind of frame this action orientation particularly in the team's kind of working phases okay and we're talking about a team you could apply this to your to your individual work but this works really well with a team because this this happens very often and in fact most engineering teams have probably faced something like this. So we're talking specifically about planning we're talking about making decisions around planning. So this this big question of what should we do and more often for engineering teams how should we accomplish this? How should we do this? How should we make this feature possible? This is the bike shedding moment that your team will will face at some point and there is some balance there's some balance between deliberation and action and and commitment towards a direction. At some point your team assuming that you you know depend on this action to survive your team will have to make a decision about what to do. Now you've probably experienced this this situation even when you believe that you shouldn't do anything even when the action that you believe you should take is not to do the thing at all right. The product feature that you're being asked to build you think is not a good product feature. We're going to set aside uh some of those ideals the idea that you may be able to identify you know fluff in the roadmap or something uh that that would disqualify this as a valid way forward and instead we're going to talk about this this concept of committing to a plan. How and when do you commit to a plan? How do you know uh when there is a plan? How do you know when there is a plan? How do you know when there is a plan? is enough information on the table in order to make a decision and move forward with it. And we're not going to answer necessarily, you know, what is the threshold? There are plenty of thinking models that will help with that. Instead, I want to provide you these two models that maybe will help catalyze that transition. And we're going to talk about that first. The first model is kind of focusing on the transition itself. You can read a little bit about this in the, it's a handbook actually that was published by Cambridge University. This concept is called the model of action phases. The model of action phases, I'm going to read a little bit from the summary here. The model of action phases makes a distinction between motivational or goal setting and volitional or goal implementation phases of goal pursuit. The model implies that changing the behavior of individuals who are involved. In pre-decisional action phase. In other words, they have not crossed the Rubicon yet with respect to turning their many wishes into binding goals. Needs a different approach than changing the behavior of people who are in a post-decisional phase. I.e. have crossed the Rubicon and need to implement their goals. And the handbook goes on to describe the fact that both of these phases in order to, you know, instigate some kind of behavioral change. You need to treat these phases differently from each other. In other words, some kind of psychological motivation that occurs when you are in planning mode is very different than the psychological motivation. Or like the mechanisms of the psychological motivation that would happen when you're in execution mode. The one thing I'm going to kind of lay out or encourage you to do on your teams is to accept that this model is valid. You don't necessarily have to dive into the behavioral change. On the before versus after crossing the Rubicon. But rather accepting that the Rubicon exists in the first place. If you're unfamiliar with this idea. The Rubicon is a small stream. And in 49 BC. Caesar Julius Caesar led his his army south over the Rubicon. And effectively this move itself was illegal. It was a an act of war. And so the idea that the phrase of crossing the Rubicon essentially means passing the point of no return. There's nothing that he can't turn around and go back and undo the act of war. Now, this might feel a little controversial for you because we are taught to maintain flexibility in all things. If you subscribe to the principles of Agile. Then, you know, remaining flexible. Over following a plan is one of those core principles of Agile. It's something that we have to be careful with. But understanding the point at which you've moved away from the deliberative phase of your work. In other words, we're going to make a decision and move forward. We've committed to a direction. This can be a useful mental model. And the reason it can be a useful mental model is that there will be a point. Where deliberation happens. As diminishing returns. And those diminishing returns dip below the relative value. Perhaps the cost curve inverts. Right. You end up having. It becomes more expensive to deliberate than produce. Then it produces value. It may, in fact, reduce value of the thing that you're trying to build in the first place. So now you can take this this concept of, you know, we're getting ready to cross the Rubicon. We need to make a decision. You can. Use this mental model and then provide yourself other tools that help you make that decision. You know, within a certain reasonable amount of energy, effort, time, whatever. Right. So time boxing, for example, might be another model you can use in conjunction with this concept that you're moving from one phase of action to another phase of action. The first phase being that planning deliberative intentional discussion about what should we do? And the second phase. Being the execution phase. One thing that is really important to understand is that this doesn't have to necessarily be at any particular scale. In other words, you know, you could have your deliberative phase and then your execution phase be as often as daily. Of course, there's going to be some diminishing returns on how many of those cycles you do. This this really is in, you know, most agile. You know, development cycle kind of habits. This is something that you could do, let's say, every two weeks. Right. This is you don't have to necessarily think about this as, oh, we're doing all this upfront planning and then we have to execute. That's not necessarily what this model is prescribing. Instead, the idea is to, as a team, have some part of your ceremony where the commitment is treated as a crossing of the Rubicon. We're not going to turn around and revisit this decision that we've made that we've we've passed a point of no return. And for those of you who are still kind of struggling with this idea, this doesn't necessarily mean that you no longer are allowed to talk about that decision. Right. That that's not at all what we're saying. Instead, what we're saying is you're working. Energy is now going to be used towards execution against that decision. And then you could have other ceremonies, other processes, other energy spent on revisiting whether you think that decision was a good one or not. For example, in a retrospective. This model can be really useful if you, like many engineering teams, end up deliberating and you don't really have a clear point of finality. Right. It may be the default feeling that. Everybody needs to get on the same page. Everybody needs to agree on the direction that there has to be some kind of democratic process or something. When, in fact, what you really are all trying to do is get to a place that solves some particular necessary problem to solve with the least investment necessary to meet the quality of output. Right. This is kind of like a basic economic basic economic equation. You want to do. Enough. Deliberation. To make a quality decision. A decision that has enough quality. To suffice for the problem that you're trying to solve. So this model helps you get to that place because it looks at the deliberation process as a finite space. Right. That is that's kind of the another way to sum up this idea is that deliberation is something that costs. Right. We have to. You know. Allocate only a certain amount of resources towards deliberation so that we can reserve resources for other things, in particular for execution. We're going to take a quick break. Then we're going to come back and talk about another mental model that you might find controversial. You might bristle at it at first, but I hope to convince you that it's useful to move from deliberation towards action soon. Things have changed in the world of website builders. I'm not just talking about you as a website builder. I'm talking about the website builders that you've heard about in the past. The ones with limited control. Right. Well, I know that's probably what you're thinking. But what about a website builder that lets you use node full stack JavaScript? You can add that to any site that you own with Wix studio. You can spend less time on UI. Coding hosting and security and more on the custom logic and functionalities that truly matter. Developing your preferred coding environment, whether that's online in a VS code based IDE or maybe locally using GitHub. Either way, with Wix studio, you're deploying in a click. Extend and replace hundreds of powerful business solutions and custom built features with APIs and integrations. And when you need to speed things up, Wix studios AI assistant is on hand to generate tailored. Code snippets troubleshoot bugs and retrieve product answers in seconds. All of that functionality is neatly wrapped up in an automatically maintained infrastructure for total peace of mind. Work in a developer first ecosystem. Go to Wix studio dot com. That's W I X studio dot com. Thanks again to Wix studio for sponsoring today's episode of developer team. I want to talk to you about another. Decision making model that might help you frame these early kind of deliberative conversations and possibly shorten them. If you're like most engineering teams and if you come from the same kind of thinking background that I do, then you believe that decisions are to be made as deliberatively as reasonably possible. In other words, we want to take in information. And apply that information in some kind of. You know, model that we can describe. Right. This might mean that we're taking in user survey information. Maybe we're taking in base rates from market models for other companies that are doing something similar. And all of this information could be useful. But the problem is that we don't always have all of that information, or at least we don't have it in exactly the same way. That we might need it. The information may not apply the way that we think it does. And so we can end up in analysis paralysis. You know, this this kind of constant deliberation. And trying to decide what to do about the sparse information that we have. And this is particularly bad if we're under some kind of time pressure. But let's imagine that someone on the team has a lot of experience in this particular area. They've seen very similar problems many times over. They've experienced, you know, similar kinds of feedback from customers. Or they've seen this kind of tech pattern scaling problem. These people have been exposed to relevant information. They've been exposed to it. They've probably interacted with it. And they have some kind of repetitive data. This is a model that is essentially based on this kind of person. Someone who has been repeatedly exposed to information. They've built up expertise. It's called the recognition primed decision model. A non-software engineering example of this might be a pilot who recognizes, you know, a stall condition in an airplane. And instinctively, you know, falls back to their training. And initiates recovery. This pilot isn't looking at every instrument. To determine exactly what kind of stall. Or, you know, what is the specific, you know, deficit of airspeed. They're using repeated training that they've undergone of intentional stalls and recoveries. They're using that training of recognizing those patterns. And then allowing their, you know, their trained response to kick in. The idea is that. Humans have a lot of intuition. And the things that we've been exposed to. Are kind of encodings of that intuition. In other words, we are pretty good at recognizing patterns. Right? So if we see a pattern. We can kind of have an intuitive idea of what's getting ready to happen next. Or what would happen if I interacted with it in this particular way. If I've done that before. Now this is a hard thing for me to wrap my head around. Because I am. I am very much. You know. By principle. I believe in the empirical approach. That you shouldn't be using your gut intuition most of the time. As a primary decision making tool. You might use that as part of your decision making. But I think it's important to understand that there are places where. This RPD model. May. First of all, outperform. Other models. The sparse data model. That you were. That we were just talking about. A minute ago. But they are also. They tend to be drastically quicker. Than any of those other analytical models. Because they are based on. Intuition and. Essentially based on this. Mental forecasting. That's happening. Constantly. For the people who have. Who are considered experts in the area. This is. Especially good then. For situations where you need to make rapid decisions. Especially. If. The stakes. Are very high. Right. And also. If you don't need an optimal. Absolute optimal decision. Okay. So think about this. The stakes are very high. We need to make a decision in the next day. Or in the next hour. To recover. You know. We need to recover. Our servers. There's a huge incident. Everything is down. We need to recover them. Staff engineers may have an intuition. That. You know. This problem looks like. It's. It's a problem of. You know. Saturation. Or it's. Whatever the shape of the problem is. And so then they're going to go and throw. Resources. At that particular. Problem. They may not have all of the logs. To prove that they're correct. They may not have. Every single piece of the puzzle in place. But they take an action. Under this high stakes situation. It may not be the perfect action. Right. But. A lot of the time. That person who has been exposed. This kind of situation. They can make a decision. That is. That is. It's sufficient. To solve the problem quickly. And under the right constraints. Right. So. This is very different. This is very different. Than if you were to. You know. Task. Let's say. A junior engineer. Who hadn't been. Exposed to these problems before. They're not going to use. Any intuition. Because they don't have. Any intuition to use. Instead. They're going to go on. A fact-finding mission. They're going to go and. Discover. The logs. They're. They might. Ask multiple questions. Of multiple. Other people. You know. There's. There's more people. Getting involved. It becomes. A much longer delay. And they may. All right. That this is the interesting part. This junior engineer. May have a more. Optimal solution. At the end of this process. In terms of. The concrete. Kind of. Solving. But all of the variables. Put together. They may. It may take them two days. To. To get to that place. Right. Or a week. Whereas. If we're going with the. R.P.D. Model. Where we trust. A more senior engineer. To. To. Exercise their intuition. In this situation. Then we may relieve the problem. In as short as. A day or two. Now the interesting thing. About the R.P.D. Model. Is. Even. When. The. First guess. Is wrong. Because you had such a quick. Move. To action. Right. We went. We crossed the Rubicon. Very quickly. We have a quick move. To action. Even. If that. Fails. You now have. The. The freedom. To. To fall back on R.P.D. Again. Right. So. This. This. The quickness. Of moving. To action. Especially. In situations. Where. The decision. That you're making. Is. A type. Two decision. In other words. You can. Undo that decision. Or the cost. Of making that decision. Is relatively. Low. You know. It's. It's not an. In that particular way. You're not crossing. The Rubicon. You can come back. And try something else. Right. Those kinds of decisions. Tend to work well. With the R.P.D. Decision making model. There's one other. Characteristic. Where R.P.D. Might excel. Over other kinds. Of models. If you think about. Other types of decision. Making models. Let's say. The Eisenhower matrix. Right. Eisenhower matrix. Is very generic. It can fit. Many. Different problem. Spaces. And it's a very useful. Model. Right. The idea. That you have. Urgent. And important. As. Two axes. And. You want to. You know. Always. Focus on doing. The urgent. Important things. First. Etc. Etc. It helps you prioritize. But this is. The. Usefulness. Of it. The utility. Of it. Comes from. How generic. It is. But it may not. Necessarily. Be. The right. Model. For. A. Particular. Domain. The generic. Nature. Of the model. Means that it can be. Applied. Very analytically. But. It may not be. The best. Model. For the situation. And domain. Specific. Situations. May be served. Better. By people. Who have been exposed. That domain. Over and over. And over. This is also. As we mentioned before. The kind of model. That you might want to use. When you have low. Or. Or incomplete. Information. Right. If all of your. Decision making. Relies. On. Some kind of. Complete data. Picture. And you don't have that data. Then. A lot of those. Analytical processes. Kind of stall. Out. So instead. Of. Only relying on those. Analytical processes. You may. Then bring in. Someone who has intuition. Especially repeated. Pattern based. Intuition. About this particular subject. To help make an initial decision. One more characteristic. That I want to highlight. Where RPD. May excel. Or may do well. Is when the situation. Evolves quickly. Right. So. Even though. Our agile processes. Are tuned for change. If you have a situation. That's changing. Quickly enough. That. Your processes. Are. Starting to slow you down. Right. You don't have. An easy way. To. To. Respond to those changes. Quickly. Because. By the time. You've finished. Making a new plan. You know. Based on some change. That's occurred. It's changed again. Right. RPD works well. In these situations. Because. We are. Not only good. At recognizing. Initial patterns. But also. Evolving patterns. If we see certain signals. The original pattern. That we saw. Is now enriched. By that secondary change. And that third change. And that fourth change. When we see those changes. We get more. And more information. That help refine. Our original intuition. And build. On that. Kind of mental model. Of what truth is. About this particular. You know. Set of. Of data. That we are not really collecting. In any concrete way. So RPD does. Tend to excel. In situations. Again. Where. You have low information. Or the information. Is changing. You don't have. You know. Very good. Quality static information. The analysis. Is facing some challenges. And. Where the person. That is performing. The decision. Could have been. Exposed to very similar. Relevant information. Over and over and over. Right. They've had repeated exposure. To the. To that information. It's good in situations. Where. You don't need. The perfect decision. You need one. That is sufficient. And you need it quickly. Right. Time bound. You know. High time stakes. Kind of decision making. And if you add all of this together. And. Then add in. A more. Domain specific decision. Right. Where. You couldn't necessarily. Arrive at the same decision. With mental models. Or decision making frameworks. That are domain generic. Or domain agnostic. All of those factors together. Might be. A good candidate for RPD. And what this does. Is. In a situation where. You need to shorten that first phase. Right. The Rubicon crossing. Needs to happen sooner. Rather than later. You don't have. A large deliberation. Budget. Right. That the. The execution needs to start. Sooner than later. For. For whatever reason. There's. Plenty of things we could talk about there. About. Whether. You know. That is. Actually true. Perhaps more deliberation. May shorten your execution. For example. That would be. A different discussion. But. Let's assume that you have. Some fixed budget. For deliberation. You want to. Shorten your deliberation. You want to. Shorten your deliberation. Time. RPD. May help you. Do exactly that. Thanks so much for listening to today's episode of developer tea. I hope you enjoyed this discussion. Thank you again to today's sponsor. Wix studio. Wix studio. Is a developer first ecosystem. That will have you spending less time on the tasks that you don't want to spend your time on. And more time on. Developing functionalities that your customers are asking you for. You can develop online in a VS code based IDE. Or you can use your local. IDE stuff. Using GitHub. You can extend and replace a suite of powerful business solutions and ship faster. With Wix studios AI code assistant and all of that is wrapped up. In an automatically in automatically maintained infra. For total peace of mind. Working to develop a first ecosystem at Wix studio.com. Wix studio.com. Thanks so much for listening to today's episode. And until next time. Enjoy your tea. .