Action Orientation and Making Faster Decisions
Summary
This episode focuses on practical tools for helping engineering teams transition from prolonged deliberation to decisive action. The host frames action orientation specifically within team planning phases, addressing the common challenge of teams getting stuck in endless discussions about “what should we do” and “how should we accomplish this.”
The first model discussed is the “model of action phases,” which distinguishes between motivational/goal-setting phases and volitional/goal-implementation phases. The key insight is recognizing the existence of a “Rubicon” moment—a point of no return where a team commits to a direction. This concept helps teams understand that deliberation has diminishing returns and becomes more expensive than execution at some point. The host emphasizes that this doesn’t mean teams can’t revisit decisions later (such as in retrospectives), but rather that working energy should shift toward execution once the commitment is made.
The second model introduced is the “recognition-primed decision” (RPD) model, which leverages the intuition and pattern recognition of experienced team members. This approach is particularly valuable in situations with sparse information, time pressure, or rapidly evolving circumstances. The host explains that RPD works well when you don’t need a perfect decision but rather a sufficient one made quickly, especially in domain-specific situations where generic analytical models may fall short.
The episode contrasts these approaches with traditional analytical decision-making and discusses when each model is most appropriate. The RPD model excels when stakes are high, time is limited, information is incomplete or changing rapidly, and when domain expertise provides relevant pattern recognition. The host acknowledges that this approach might feel controversial to those who prefer empirical, data-driven decision-making but argues it can significantly shorten deliberation time when properly applied.
Throughout the discussion, the host emphasizes balancing deliberation with action, allocating appropriate resources to each phase, and understanding that different situations call for different decision-making approaches. The practical application involves helping teams recognize when they’re stuck in deliberation and providing frameworks to catalyze the transition to execution.
Recommendations
Concepts
- Model of Action Phases — A framework from Cambridge University that distinguishes between motivational/goal-setting phases and volitional/goal-implementation phases, emphasizing the importance of recognizing when a team has ‘crossed the Rubicon’ from deliberation to commitment.
- Recognition-Primed Decision (RPD) Model — A decision-making approach that leverages the intuition and pattern recognition of experienced individuals, particularly valuable in situations with sparse information, time pressure, or rapidly changing circumstances where analytical models may stall.
Topic Timeline
- 00:00:00 — Introduction to action orientation in team planning — The episode opens by framing action orientation within team planning phases, specifically addressing how engineering teams make decisions about what to build and how to build it. The host introduces the common problem of “bike shedding” where teams get stuck in endless deliberation without reaching decisions. The discussion sets up the need for practical tools to help teams transition from planning to execution phases more effectively.
- 00:03:35 — The model of action phases and crossing the Rubicon — The host introduces the “model of action phases” from Cambridge University, which distinguishes between motivational/goal-setting phases and volitional/goal-implementation phases. The key concept is recognizing when a team has “crossed the Rubicon”—reached a point of no return where commitment to a direction has been made. This model helps teams understand that deliberation should be treated as a finite resource with diminishing returns, and that there needs to be a clear transition point from planning to execution modes.
- 00:12:20 — Introduction to recognition-primed decision model — After the sponsor break, the host introduces the recognition-primed decision (RPD) model as another tool to shorten deliberation time. This model leverages the intuition and pattern recognition of experienced team members who have been repeatedly exposed to similar problems. The host acknowledges this might feel controversial for those who prefer empirical, data-driven approaches but argues it can be valuable in certain situations where analytical models struggle.
- 00:14:31 — How RPD works with expertise and intuition — The host explains how the RPD model works by drawing on the expertise of people who have built up pattern recognition through repeated exposure to similar situations. Using the example of a pilot recognizing stall conditions, the host illustrates how trained intuition can lead to faster decisions than analytical processes. The discussion covers when RPD outperforms other models—particularly in high-stakes, time-sensitive situations where you need a sufficient (not perfect) decision quickly.
- 00:19:43 — When to apply RPD versus other decision models — The host details specific characteristics where RPD excels: when decisions are type two (reversible), when you have low or incomplete information, when situations evolve quickly, and when you need domain-specific expertise rather than generic analytical frameworks. The episode contrasts RPD with models like the Eisenhower matrix, noting that while generic models have broad utility, domain-specific intuition can be more effective in particular contexts where rapid pattern recognition is valuable.
Episode Info
- Podcast: Developer Tea
- Author: Jonathan Cutrell
- Category: Technology Business Careers Society & Culture
- Published: 2025-01-22T08:00:00Z
- Duration: 00:25:48
References
- URL PocketCasts: https://pocketcasts.com/podcast/developer-tea/cbe9b6c0-7da4-0132-e6ef-5f4c86fd3263/action-orientation-and-making-faster-decisions/e5c2c450-46ac-44f3-b51d-c978043b443f
- Episode UUID: e5c2c450-46ac-44f3-b51d-c978043b443f
Podcast Info
- Name: Developer Tea
- Type: episodic
- Site: http://www.developertea.com
- UUID: cbe9b6c0-7da4-0132-e6ef-5f4c86fd3263
Transcript
[00:00:00] We’ve talked recently about the concept of becoming more action oriented, and this is
[00:00:22] a pretty broad discussion.
[00:00:26] Today I want to give you some practical tools that you can use on your teams in your discussions,
[00:00:34] in your planning in particular, to move your teams towards action orientation.
[00:00:42] For the sake of the discussion today, I want to kind of frame this action orientation particularly
[00:00:51] in the team’s kind of working phases.
[00:00:55] Okay, and we’re talking about a team, you could apply this to your individual work,
[00:01:00] but this works really well with a team because this happens very often.
[00:01:05] And in fact, most engineering teams have probably faced something like this.
[00:01:11] So we’re talking specifically about planning.
[00:01:13] We’re talking about making decisions around planning.
[00:01:18] So this big question of what should we do, and more often for engineering teams,
[00:01:25] how should we accomplish this?
[00:01:27] How should we do this?
[00:01:28] How should we make this feature possible?
[00:01:33] This is the bike shedding moment that your team will face at some point.
[00:01:41] And there is some balance between deliberation and action and commitment towards a direction.
[00:01:51] At some point, your team, assuming that you depend on this action to survive,
[00:01:59] your team will have to make a decision about what to do.
[00:02:03] Now you’ve probably experienced this situation even when you’re doing this.
[00:02:10] You believe that you shouldn’t do anything,
[00:02:13] even when the action that you believe you should take is not to do the thing at all.
[00:02:21] The product feature that you’re being asked to build you think is not a good product feature.
[00:02:25] We’re going to set aside some of those ideals,
[00:02:30] the idea that you may be able to identify fluff in the roadmap or something
[00:02:36] that would disqualify this as a valid way forward.
[00:02:41] And instead, we’re going to talk about this concept of committing to a plan.
[00:02:46] How and when do you commit to a plan?
[00:02:50] How do you know when there is enough information on the table
[00:02:57] in order to make a decision and move forward with it?
[00:03:01] And we’re not going to answer necessarily what is the threshold.
[00:03:05] There are plenty of thinking models that will help with that.
[00:03:08] Instead, I want to provide you these two models
[00:03:11] that maybe will help catalyze that transition.
[00:03:15] And we’re going to talk about that first.
[00:03:17] The first model is kind of focusing on the transition itself.
[00:03:22] You can read a little bit about this in the,
[00:03:26] it’s a handbook actually that was published by Cambridge University.
[00:03:31] This concept is called the model of action phases.
[00:03:35] The model of action phases,
[00:03:36] I’m going to read a little bit from the summary here.
[00:03:38] The model of action phases makes a distinction
[00:03:40] between motivational or goal setting
[00:03:43] and volitional or goal implementation phases of goal pursuit.
[00:03:48] The model implies that changing the behavior of individuals
[00:03:52] who are in pre-decisional action phase,
[00:03:55] in other words, they have not crossed the Rubicon yet
[00:03:58] with respect to turning their many wishes into binding goals,
[00:04:02] needs a different approach than changing the behavior of people
[00:04:05] who are in a post-decisional phase,
[00:04:08] i.e. have crossed the Rubicon and need to implement their goals.
[00:04:13] And the handbook goes on to describe the fact that both of these phases
[00:04:18] in order to instigate some kind of behavioral change,
[00:04:22] you need to treat these phases differently from each other.
[00:04:25] In other words, some kind of psychological motivation
[00:04:28] that occurs when you are in planning mode
[00:04:31] is very different than the psychological motivation
[00:04:35] or like the mechanisms of the psychological motivation
[00:04:37] that would happen when you’re in execution mode.
[00:04:40] The one thing I’m going to kind of lay out
[00:04:42] or encourage you to do on your teams
[00:04:46] is to accept that this model is valid.
[00:04:49] You don’t necessarily have to dive into the behavioral change
[00:04:52] on the before versus after crossing the Rubicon,
[00:04:55] but rather accepting that the Rubicon exists in the first place.
[00:05:00] If you’re unfamiliar with this idea, the Rubicon is a small stream
[00:05:05] and in 49 BC, Julius Caesar led his army south over the Rubicon.
[00:05:16] And effectively, this move itself was illegal.
[00:05:20] It was an act of war.
[00:05:22] And so the idea, the phrase of crossing the Rubicon
[00:05:27] essentially means passing the point of no return.
[00:05:30] There’s nothing that he can’t turn around and go back
[00:05:34] and undo the act of war.
[00:05:37] Now, this might feel a little controversial for you
[00:05:40] because we are taught to maintain flexibility in all things.
[00:05:45] If you subscribe to the principles of Agile,
[00:05:50] then remaining flexible over following a plan
[00:05:53] is one of those core principles of Agile.
[00:05:55] It’s something that we have to be careful with.
[00:05:58] But understanding the point at which you’ve moved away
[00:06:03] from the deliberative phase of your work.
[00:06:06] In other words, we’re going to make a decision and move forward.
[00:06:10] We’ve committed to a direction.
[00:06:13] This can be a useful mental model.
[00:06:15] And the reason it can be a useful mental model
[00:06:17] is that there will be a point where deliberation
[00:06:21] has diminishing returns and those diminishing returns
[00:06:25] dip below the relative value.
[00:06:27] Perhaps the cost curve inverts.
[00:06:33] It becomes more expensive to deliberate than it produces value.
[00:06:38] It may, in fact, reduce value of the thing
[00:06:42] that you’re trying to build in the first place.
[00:06:44] Now you can take this concept of we’re getting ready
[00:06:48] to cross the Rubicon, we need to make a decision.
[00:06:51] You can use this mental model and then provide yourself
[00:06:55] other tools that help you make that decision
[00:06:59] within a certain reasonable amount of energy, effort, time, whatever.
[00:07:04] Time boxing, for example, might be another model
[00:07:07] you can use in conjunction with this concept
[00:07:10] that you’re moving from one phase of action
[00:07:13] to another phase of action.
[00:07:14] The first phase being that planning, deliberative,
[00:07:18] intentional discussion about what should we do
[00:07:21] and the second phase being the execution phase.
[00:07:25] One thing that is really important to understand
[00:07:27] is that this doesn’t have to necessarily be
[00:07:30] at any particular scale.
[00:07:32] In other words, you could have your deliberative phase
[00:07:37] and then your execution phase be as often as daily.
[00:07:41] Of course, there’s going to be some diminishing returns
[00:07:43] on how many of those cycles you do.
[00:07:46] This really is, in most agile development cycle kind of habits,
[00:07:54] this is something that you could do, let’s say, every two weeks.
[00:07:59] You don’t have to necessarily think about this as,
[00:08:01] oh, we’re doing all this upfront planning
[00:08:03] and then we have to execute.
[00:08:05] That’s not necessarily what this model is prescribing.
[00:08:10] Instead, the idea is to, as a team,
[00:08:13] have some part of your ceremony where the commitment
[00:08:18] is treated as a crossing of the Rubicon.
[00:08:22] We’re not going to turn around and revisit this decision
[00:08:25] that we’ve made.
[00:08:27] We’ve passed a point of no return.
[00:08:30] And for those of you who are still kind of struggling
[00:08:31] with this idea, this doesn’t necessarily mean
[00:08:35] that you no longer are allowed to talk about that decision.
[00:08:40] That’s not at all what we’re saying.
[00:08:42] Instead, what we’re saying is your working energy
[00:08:46] is now going to be used towards execution against that decision.
[00:08:52] And then you could have other ceremonies, other processes,
[00:08:57] other energy spent on revisiting whether you think
[00:09:00] that decision was a good one or not, for example, in a retrospective.
[00:09:05] This model can be really useful if you,
[00:09:08] like many engineering teams, end up deliberating
[00:09:13] and you don’t really have a clear point of finality.
[00:09:19] It may be the default feeling that everybody needs
[00:09:22] to get on the same page.
[00:09:24] Everybody needs to agree on the direction
[00:09:26] that there has to be some kind of democratic process
[00:09:29] or something when, in fact, what you really are all trying to do
[00:09:33] is get to a place that solves some particular necessary problem
[00:09:39] to solve with the least investment necessary
[00:09:43] to meet the quality of output.
[00:09:46] This is kind of like a basic economic equation.
[00:09:51] You want to do enough deliberation
[00:09:54] to make a quality decision, a decision that has enough quality
[00:09:59] to suffice for the problem that you’re trying to solve.
[00:10:03] So this model helps you get to that place
[00:10:05] because it looks at the deliberation process
[00:10:09] as a finite space, right?
[00:10:12] That is kind of the another way to sum up this idea
[00:10:15] is that deliberation is something that costs, right?
[00:10:19] We have to allocate only a certain amount of resources
[00:10:24] towards deliberation so that we can reserve resources
[00:10:28] for other things, in particular, for execution.
[00:10:31] We’re going to take a quick break,
[00:10:33] then we’re going to come back and talk about another mental model
[00:10:37] that you might find controversial.
[00:10:38] You might bristle at it at first,
[00:10:40] but I hope to convince you that it’s useful
[00:10:43] to move from deliberation towards action soon.
[00:10:53] Things have changed in the world of website builders.
[00:10:58] I’m not just talking about you as a website builder.
[00:11:00] I’m talking about the website builders
[00:11:03] that you’ve heard about in the past,
[00:11:05] the ones with limited control, right?
[00:11:08] Well, I know that’s probably what you’re thinking,
[00:11:10] but what about a website builder that lets you use Node,
[00:11:13] full stack JavaScript?
[00:11:15] You can add that to any site that you own.
[00:11:18] With Wix Studio, you can spend less time
[00:11:21] on UI coding, hosting, and security,
[00:11:23] and more on the custom logic and functionalities
[00:11:26] that truly matter.
[00:11:28] Developing your preferred coding environment,
[00:11:30] whether that’s online and a VS code-based IDE,
[00:11:33] or maybe locally using GitHub.
[00:11:36] Either way, with Wix Studio, you’re deploying in a click.
[00:11:39] Extend and replace hundreds of powerful business solutions
[00:11:43] and custom-built features with APIs and integrations.
[00:11:46] And when you need to speed things up,
[00:11:48] Wix Studio’s AI assistant is on hand
[00:11:50] to generate tailored code snippets, troubleshoot bugs,
[00:11:54] and retrieve product answers in seconds.
[00:11:56] All of that functionality is neatly wrapped up
[00:11:58] in an automatically maintained infrastructure
[00:12:00] for total peace of mind.
[00:12:02] Work in a developer-first ecosystem.
[00:12:05] Go to wixstudio.com.
[00:12:07] That’s W-I-X studio.com.
[00:12:09] Thanks again to Wix Studio for sponsoring today’s episode
[00:12:12] of Developer Team.
[00:12:20] I want to talk to you about another decision-making model
[00:12:24] that might help you frame these early
[00:12:29] deliberative conversations and possibly shorten them.
[00:12:33] If you’re like most engineering teams,
[00:12:36] and if you come from the same kind of thinking background
[00:12:39] that I do, then you believe that decisions
[00:12:42] are to be made as deliberatively as reasonably possible.
[00:12:47] In other words, we want to take in information
[00:12:51] and apply that information in some kind of model
[00:12:55] that we can describe.
[00:12:57] This might mean that we’re taking in user survey information.
[00:13:01] Maybe we’re taking in base rates from market models
[00:13:05] for other companies that are doing something similar.
[00:13:08] And all of this information could be useful,
[00:13:11] but the problem is that we don’t always have
[00:13:13] all of that information, or at least we don’t have it
[00:13:16] in exactly the same way that we might need it.
[00:13:21] The information may not apply the way that we think it does.
[00:13:24] And so we can end up in analysis paralysis,
[00:13:29] this kind of constant deliberation
[00:13:32] and trying to decide what to do
[00:13:34] about the sparse information that we have.
[00:13:37] And this is particularly bad if we’re under
[00:13:39] some kind of time pressure.
[00:13:41] But let’s imagine that someone on the team
[00:13:44] has a lot of experience in this particular area.
[00:13:48] They’ve seen very similar problems many times over.
[00:13:51] They’ve experienced similar kinds of feedback from customers,
[00:13:56] or they’ve seen this kind of tech pattern scaling problem.
[00:14:00] These people have been exposed to relevant information.
[00:14:06] They’ve been exposed to it,
[00:14:07] they’ve probably interacted with it,
[00:14:10] and they have some kind of repetitive data.
[00:14:16] Now, this is a model that is essentially based
[00:14:20] on this kind of person.
[00:14:21] Someone who has been repeatedly exposed to information,
[00:14:25] they’ve built up expertise.
[00:14:27] It’s called the recognition-primed decision model.
[00:14:31] A non-software engineering example of this
[00:14:34] might be a pilot who recognizes a stall condition in an airplane
[00:14:41] and instinctively falls back to their training
[00:14:45] and initiates recovery.
[00:14:48] This pilot isn’t looking at every instrument
[00:14:50] to determine exactly what kind of stall
[00:14:54] or what is the specific deficit of airspeed.
[00:15:00] They’re using repeated training that they’ve undergone
[00:15:05] of intentional stalls and recoveries.
[00:15:09] They’re using that training of recognizing those patterns
[00:15:13] and then allowing their trained response to kick in.
[00:15:18] The idea is that humans have a lot of intuition
[00:15:22] and the things that we’ve been exposed to
[00:15:26] are kind of encodings of that intuition.
[00:15:29] In other words, we are pretty good at recognizing patterns, right?
[00:15:33] So if we see a pattern,
[00:15:35] we can kind of have an intuitive idea
[00:15:38] of what’s getting ready to happen next
[00:15:39] or what would happen if I interacted with it
[00:15:41] in this particular way if I’ve done that before.
[00:15:45] This is a hard thing for me to wrap my head around
[00:15:49] because I am very much, by principle,
[00:15:54] I believe in the empirical approach
[00:15:56] that you shouldn’t be using your gut intuition most of the time
[00:16:00] as a primary decision-making tool.
[00:16:02] You might use that as part of your decision-making,
[00:16:06] but I think it’s important to understand
[00:16:08] that there are places where this RPD model may,
[00:16:14] first of all, outperform other models,
[00:16:17] the sparse data model
[00:16:18] that we were just talking about a minute ago,
[00:16:22] but they tend to be drastically quicker
[00:16:26] than any of those other analytical models
[00:16:28] because they’re based on intuition
[00:16:31] and essentially based on this mental forecasting
[00:16:36] that’s happening constantly
[00:16:39] for the people who are considered experts in the area.
[00:16:43] This is especially good then for situations
[00:16:46] where you need to make rapid decisions,
[00:16:49] especially if the stakes are very high,
[00:16:53] and also if you don’t need an optimal,
[00:16:55] absolute optimal decision.
[00:16:57] So think about this.
[00:16:58] The stakes are very high.
[00:16:59] We need to make a decision in the next day
[00:17:01] or in the next hour to recover.
[00:17:05] We need to recover our servers.
[00:17:07] There’s a huge incident.
[00:17:09] Everything is down.
[00:17:10] We need to recover them.
[00:17:11] Staff engineers may have an intuition
[00:17:13] that this problem looks like it’s a problem of saturation
[00:17:19] or it’s whatever the shape of the problem is,
[00:17:22] and so then they’re going to go and throw resources
[00:17:25] at that particular problem.
[00:17:26] They may not have all of the logs
[00:17:28] to prove that they’re correct.
[00:17:29] They may not have every single piece of the puzzle in place,
[00:17:33] but they take an action under this high-stake situation.
[00:17:37] It may not be the perfect action, right?
[00:17:40] But a lot of the time,
[00:17:42] that person who has been exposed to this kind of situation,
[00:17:45] they can make a decision that is sufficient
[00:17:50] to solve the problem quickly and under the right constraints, right?
[00:17:55] So this is very different.
[00:17:57] This is very different than if you were to task,
[00:18:01] let’s say, a junior engineer
[00:18:03] who hadn’t been exposed to these problems before.
[00:18:06] They’re not going to use any intuition
[00:18:08] because they don’t have any intuition to use.
[00:18:10] Instead, they’re going to go on a fact-finding mission.
[00:18:13] They’re going to go and discover the logs.
[00:18:16] They might ask multiple questions of multiple other people.
[00:18:21] There’s more people getting involved.
[00:18:22] It becomes a much longer delay, and they may, all right?
[00:18:27] This is the interesting part.
[00:18:29] This junior engineer may have a more optimal solution
[00:18:33] at the end of this process
[00:18:35] in terms of the concrete kind of solving.
[00:18:39] But all of the variables put together,
[00:18:43] it may take them two days to get to that place, right?
[00:18:47] Or a week.
[00:18:49] Whereas if we’re going with the RPD model
[00:18:52] where we trust a more senior engineer
[00:18:54] to exercise their intuition in this situation,
[00:18:58] then we may relieve the problem in as short as a day or two.
[00:19:03] Now, the interesting thing about the RPD model
[00:19:07] is even when the first guess is wrong,
[00:19:13] because you had such a quick move to action, right?
[00:19:18] We went, we crossed the Rubicon very quickly.
[00:19:21] We have a quick move to action.
[00:19:24] Even if that fails,
[00:19:27] you now have the freedom to fall back on RPD again.
[00:19:32] So the quickness of moving to action,
[00:19:37] especially in situations
[00:19:38] where the decision that you’re making is a type two decision.
[00:19:43] In other words, you can undo that decision
[00:19:45] or the cost of making that decision is relatively low.
[00:19:51] In that particular way, you’re not crossing the Rubicon.
[00:19:54] You can come back and try something else, right?
[00:19:57] Those kinds of decisions tend to work well
[00:20:00] with the RPD decision-making model.
[00:20:02] There’s one other characteristic
[00:20:04] where RPD might excel over other kinds of models.
[00:20:08] If you think about other types of decision-making models,
[00:20:11] let’s say the Eisenhower matrix, right?
[00:20:14] Eisenhower matrix is very generic.
[00:20:17] It can fit many different problem spaces
[00:20:20] and it’s a very useful model, right?
[00:20:22] The idea that you have urgent and important as two axes
[00:20:27] and you want to always focus on doing
[00:20:31] the urgent and important things first, et cetera, et cetera.
[00:20:34] It helps you prioritize.
[00:20:38] The usefulness of it, the utility of it
[00:20:41] comes from how generic it is,
[00:20:43] but it may not necessarily be the right model
[00:20:47] for a particular domain.
[00:20:49] The generic nature of the model
[00:20:52] means that it can be applied very analytically,
[00:20:55] but it may not be the best model for the situation
[00:20:59] and domain-specific situations may be served better
[00:21:04] by people who have been exposed to that domain
[00:21:06] over and over and over.
[00:21:08] This is also, as we mentioned before,
[00:21:11] the kind of model that you might want to use
[00:21:13] when you have low or incomplete information, right?
[00:21:17] If all of your decision-making relies on
[00:21:21] some kind of complete data picture
[00:21:23] and you don’t have that data,
[00:21:25] then a lot of those analytical processes kind of stall out.
[00:21:30] So instead of only relying on those analytical processes,
[00:21:34] you may then bring in someone who has intuition,
[00:21:37] especially repeated pattern-based intuition
[00:21:41] about this particular subject
[00:21:43] to help make an initial decision.
[00:21:45] One more characteristic that I want to highlight
[00:21:48] where RPD may excel or may do well
[00:21:52] is when the situation evolves quickly, right?
[00:21:56] So even though our agile processes are tuned for change,
[00:22:01] if you have a situation that’s changing quickly enough
[00:22:04] that your processes are starting to slow you down, right?
[00:22:09] You don’t have an easy way to respond
[00:22:14] to those changes quickly
[00:22:16] because by the time you’ve finished making a new plan,
[00:22:20] you know, based on some change that’s occurred,
[00:22:23] it’s changed again, right?
[00:22:25] RPD works well in these situations
[00:22:27] because we are not only good at recognizing initial patterns
[00:22:32] but also evolving patterns.
[00:22:34] If we see certain signals,
[00:22:36] the original pattern that we saw
[00:22:39] is now enriched by that secondary change
[00:22:41] and that third change and that fourth change.
[00:22:44] When we see those changes,
[00:22:46] we get more and more information
[00:22:48] that help refine our original intuition
[00:22:52] and build on that mental model of what truth is
[00:22:55] about this particular set of data
[00:22:59] that we are not really collecting in any concrete way.
[00:23:02] So RPD does tend to excel in situations, again,
[00:23:06] where you have low information
[00:23:08] or the information is changing,
[00:23:10] you don’t have very good quality static information,
[00:23:14] the analysis is facing some challenges
[00:23:18] where the person that is performing the decision
[00:23:21] could have been exposed to very similar
[00:23:25] relevant information over and over and over, right?
[00:23:28] They’ve had repeated exposure to that information.
[00:23:32] It’s good in situations
[00:23:34] where you don’t need the perfect decision,
[00:23:36] you need one that is sufficient
[00:23:39] and you need it quickly, right?
[00:23:40] Time-bound, you know, high time-stakes
[00:23:43] kind of decision-making.
[00:23:45] And if you add all of this together
[00:23:47] and then add in a more domain-specific decision, right?
[00:23:52] Where you couldn’t necessarily arrive at the same decision
[00:23:55] with mental models or decision-making frameworks
[00:23:59] that are domain-generic or domain-agnostic.
[00:24:03] All of those factors together
[00:24:05] might be a good candidate for RPD.
[00:24:07] And what this does is in a situation
[00:24:11] where you need to shorten that first phase, right?
[00:24:14] The Rubicon crossing needs to happen sooner rather than later.
[00:24:18] You don’t have a large deliberation budget, right?
[00:24:24] That the execution needs to start sooner than later
[00:24:27] for whatever reason.
[00:24:28] There’s plenty of things we could talk about there
[00:24:30] about whether, you know, that is actually true.
[00:24:35] Perhaps more deliberation may shorten your execution,
[00:24:38] for example, that would be a different discussion.
[00:24:41] But let’s assume that you have some fixed budget
[00:24:44] for deliberation.
[00:24:46] You want to shorten your deliberation time.
[00:24:48] RPD may help you do exactly that.
[00:24:52] Thanks so much for listening to today’s episode of Developer Tea.
[00:24:55] I hope you enjoyed this discussion.
[00:24:56] Thank you again to today’s sponsor, Wix Studio.
[00:25:00] Wix Studio is a developer-first ecosystem
[00:25:03] that will have you spending less time on the tasks
[00:25:06] that you don’t want to spend your time on.
[00:25:08] And more time on developing functionalities
[00:25:11] that your customers are asking you for.
[00:25:13] You can develop online in a VS Code-based IDE,
[00:25:15] or you can use your local IDE stuff using GitHub.
[00:25:20] You can extend and replace a suite of powerful business solutions
[00:25:23] and ship faster with Wix Studio’s AI Code Assistant.
[00:25:26] And all of that is wrapped up in an automatically maintained infra
[00:25:31] for total peace of mind.
[00:25:32] Working to develop a first ecosystem at wixstudio.com,
[00:25:35] w-a-x-studio.com.
[00:25:37] Thanks so much for listening to today’s episode.
[00:25:39] And until next time, enjoy your tea.