we've talked recently about the concept of becoming more action oriented and this is a 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 teams 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 uh 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 They're making decisions around planning.
So 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?
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 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.
The product feature that you're being asked to build you think is not a good product feature.
We're going to set aside some of those ideals, the idea that you may be able to identify fluff in the roadmap or something that would disqualify this as a valid way forward. And instead, we're going to talk about this concept of committing to a plan.
How and when do you commit to a plan?
how do you know, uh, when there is enough information, um, on, 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, 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 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 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 instigate some kind of behavioral change, you need to treat these phases differently from each other.
In other words, some kind of 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 army south over the Rubicon.
And effectively, this move itself was illegal.
It was an act of war.
And so the idea, 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 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 has 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, than 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 concept of, you know, we're getting ready to across 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 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 could have your deliberative phase and then your execution phase days be as often as daily.
Of course, there's going to be some diminishing returns on how many of those cycles you do.
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.
cute. 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.
We've passed a point of no return.
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.
That's not at all what we're saying.
Instead, what we're saying is your 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.
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?
right? This is kind of like a 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 kind of another way to sum up this idea is that deliberation is something that costs.
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 and 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 sooner.
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 Studio's 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 wixstudio .com.
That's W -I -X studio .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 deliberative conversations and possibly 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 model that we can describe.
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, 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.
Now, 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 a stall condition in an airplane and instinctively falls back to their training and initiates recovery.
This pilot isn't looking at every instrument to determine exactly what kind of stall or what is the specific 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 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 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 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're based on intuition and essentially based on this mental forecasting that's happening constantly for the people 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.
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 this problem looks like it's a problem of 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 stake situation.
It may not be the perfect action, right?
But a lot of the time, that person who has been exposed to this kind of situation, they can make a decision that is sufficient to solve the problem quickly and under the right constraints, right?
This is very different.
This is very different than if you were to 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 might ask multiple questions of multiple there's multiple other people, you know, there's more people getting involved, it becomes a much longer delay, and they may, all right, 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, it may take them two days to get to that place, right, or a week.
Whereas if we're going with the RPD model, where we trust a more senior engineer 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 RPD model is even when the first guess is wrong, because you had such a quick move to action, right?
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 RPD 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.
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 RPD decision -making model.
There's one other characteristic where RPD 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 always focus on doing the urgent and important things first, et cetera, et cetera.
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 to 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 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 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.
in, 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 set 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 very good quality static information, the analysis is facing some challenges 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 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, 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 execution needs to start sooner than later for whatever reason.
There's plenty of things we could talk about there about whether 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 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 Studio's AI Code Assistant.
And all of that is wrapped up in an automatically maintained infra for total peace of mind.
Work in a developer -first ecosystem at Wixstudio .com, W -I -X -studio .com.
Thanks so much for listening to today's episode.
And until next time, enjoy your tea.
