Hi, everyone, and welcome to Developer Tea.
My name is Jonathan Cottrell, and my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers.
And in today's episode, I want to talk a little bit about a management kind of principle or set of principles.
And it's not just for managers. This is good for self-management as well.
The basic question that often comes to mind is how do I get a person to do a thing?
It's a fundamental management question. How do I get an engineer to consider testing their code differently?
How do I encourage this group of engineers to review each other's code more often?
And very often the kind of naive management approach is to throw your hands up in the air and say, well, nobody wants to do the right thing.
So we're going to mandate it. We're going to create rules.
They must do it. They have to do it. Or similarly, perhaps even more damaging would be the mindset that because they're not doing it, they're in the wrong. and leaving it at that.
Maybe it shows up in a performance review or something.
And the trouble is none of this actually solves the underlying problem.
You're not actually working on the behavioral aspects that you care about.
You're not creating a new habit. It's unlikely to stick.
Following rules doesn't generate quality work.
It usually results in people following the rule to the minimum possible.
Especially if it was something that they didn't want to do in the first place.
Now, my goal is not to impress the idea that you have to encourage them to want the thing.
Instead, I want to look at this kind of set of factors that are most clearly associated with whether somebody does something or not.
This sounds kind of very base level principled, but this is a model that you can use to when you're trying to encourage either others or yourself.
The interesting kind of insight for those of you who are not managers is that the same kinds of problems, the same model will work on your own interest, your own motivations, your own kind of self-bettering.
If you want to participate in a particular behavior, but you find yourself struggling to actually incorporate that behavior, You've made all of the resolutions in the world.
You've made all the self-commitments. You've read every book out there.
There's a couple of books that you could have read that probably cover some of what we're talking about here.
But you struggle to actually implement. You struggle to actually get the thing done.
You struggle to stick to that. So this model, these principles will work for you at a personal level as well.
So why doesn't a person do a thing? Well, let's first start with the many things that we don't do to begin with.
In order to decide to choose to do something, we are choosing to not do anything else. an almost infinite number of other possibilities that we say no to.
And so deciding to do something, we generally want to have a good reason.
Sometimes good reason there can be fulfilled by the thing that feels good.
It can be fulfilled by something that we are sufficiently motivated to do.
We'll talk a little bit more about motivation here in a second.
But ultimately, we don't just do everything that we come across.
So if I have 10 things that I could be doing at work, one of them might be filling out that survey that somebody sent me in Slack.
Another one might be working on the ticket that's assigned to me.
Another one might be reviewing somebody else's code.
Another might be joining a social gathering.
What are the incentives? What are the motivations for me to pick one of those over another?
The fallacy in our thinking, especially as managers, is that we will have time to do everything.
That all of the important things will fit in because we hope that somehow somebody has designed our job so that we will always get to all of the important stuff.
That's definitely not the case, right? We're definitely not going to get to even all of the important things, even the things that we deem to be worth doing.
We won't necessarily get a chance to do them all.
We'll have to say no to a lot of things, almost everything, in fact.
That's the amazing kind of insight that I hope you gather from this, is that in order to get somebody to do any one thing, they have to say no to infinitely more possibilities.
So what is the science behind how do we get to the place where we're actually taking action, we're actually doing a thing that we deem important to do?
That's step one, is understanding that there needs to be some reason, some motivation to do the thing in the first place.
If there's not a clear motivation, if there's not a clear incentive, especially, right?
The incentive meaning that there's some kind of payoff for me to do this thing.
Or if the incentive is difficult to understand, if it's not clear, so then there may be an incentive, but you're not really sure what it is.
We can effectively say that there's not an incentive in those situations, even though as a leader, you may believe that, oh, of course, there's an incentive for you to review your code because that helps the company and it helps your fellow teammate.
The incentive is clearly there. That's not necessarily the case.
When we talk about incentives, we're really talking about the kind of selfish question, what's in it for me?
And not just the selfish question, but the question that helps bring that home to the individual that we're trying to get to some active state, some active decision.
So in the case that, oh, it helps out your teammate, that's not an incentive for me, not a direct one at least. the incentive in that situation to help another person is actually a social incentive, right?
I get some kind of social credibility. You know, there's a liking effect that occurs.
And so now this person is more likely to act on my behalf.
That is the kind of fundamental or sociological version of an incentive.
It is a social incentive in this particular case if we're talking about code review, reviewing each other's code.
Other incentives might include as long as it's explicit, right?
It might include your performance review.
Okay, so incentives really are the critical factor because incentives are how we make those decisions of what to pursue in the first place, okay?
Past incentives. Let's imagine that we have a perfectly clear incentive for why you should be able to choose to do something.
The next two things that we need to think about are What is the crossroads?
Okay. What is the trigger? What is the point at which we would make the decision to do this?
Okay. So for example, if we are supposed to review each other's code, but we never really, we don't really have a good practice of, you know, kind of notifying the team when we need a review.
Or maybe that trigger has become, you know, we've gotten a little bit apathetic towards it.
Everybody's asking for reviews, nobody's giving them, and then nothing happens.
Everything repeats tomorrow. It's the same thing as if you had alert fatigue.
If your service is experiencing errors and you're getting an alert every single day for the same error over and over, eventually you're going to ignore that alert.
But eventually there's going to be a real alert, right?
Yeah. It was a technological equivalent of the boy who cried wolf.
It's just the alert who cried wolf. Okay, so we need to understand that there's a crossroads point, a trigger point, where we make a decision of what should we do in this circumstance, right?
Very often, we assume that the trigger point will be self-generated.
This is another bad kind of management practice or assumption that many managers make, naive managers will make, is that Just by nature of the person kind of doing their job, they will either create, self-create this trigger for themselves or they'll stumble over it.
The opportunity will be there by nature of just doing work, right?
Especially not the case when we're asking somebody to do something fundamentally new, right? to use a new skill set, to use new tools, to adopt a new pattern, to adopt new behavior that doesn't really fit in with their current kind of setup, right?
So having some kind of trigger... Um, especially if you can design the trigger is much more likely to lead to some kind of reaction, some kind of point of decision.
Okay. So you're, uh, you want to create those decision points or at least be highly aware of where they exist and then calling them out or trying to call more attention to them, create more signal in that trigger.
Really you're, you're trying to elevate that moment, that crossroads moment.
OK, the last is the ability. All right. So and I'm going to kind of talk about ability and incentive.
So we have trigger ability incentive, the ability and the incentive kind of coincide.
And we're going to talk a little more about why that's the case, because when we talk about ability here, we're not just talking about. a skill set, right?
We're not just talking about whether this person can do this thing theoretically or whether or not they can use that particular tool or something like that.
When we talk about ability, we're also talking about clarity of how to do the thing, okay?
They may be fully capable. They may have the technical ability, but in order to accomplish the thing, Are there other roadblocks that they can't even control no matter how good at it they are?
All right. So a good example of this might be, well, you know, we want you to review code.
Okay. Let's say I'm a senior engineer. I've reviewed a lot of code in my, in my time, but it's not really clear exactly what standard I'm supposed to be reviewing this code to.
I'm highly capable, but I'm not able, right?
In this circumstance, I'm not able. So, uh, My ability is hindered by being blocked by some lack of standard.
Now, of course, there's a lot of ways to deal with this, but the fundamental idea here is that not only do you want to ensure that the person is capable, but you also want to reduce the friction involved.
And the variability in the behaviors that you're wanting to encourage as much as possible.
So what this is doing is it's creating less of a hurdle.
You're reducing the difficulty, reducing the friction.
You're, so to speak, you're making the right thing the easy thing.
You're trying to reduce the amount of cognitive overload that engaging in the desired behavior causes.
And really what you're doing is you're taking advantage of our automatic desire, our brain's desire to optimize, to optimize for the easiest thing.
Instead of saying, well, everybody can figure it out.
They're smart. This is a common trope amongst managers.
Why should I go through all this difficulty when this is just a part of their job?
They're smart people. They know how to do this stuff.
Why would I spend a lot of my energy trying to make this thing that they're supposed to be doing anyway easier?
That's taking time from me. Or that's, you know, why should I baby this person?
That might be another bad assertion. That by trying to reduce the friction that you are somehow dumbing down the behavior that you want.
And all of this is wrong thinking because what we're really trying to do is we're trying to make it easier to create habits, right?
We're trying to make the defaults a better behavior.
And we're not really trying to test whether somebody has a lot of mental fortitude.
There's not really a lot of value in that, right?
We're not trying to prove that we can stand up against all odds.
There may be a different kind of value in that, but that's not really what we're trying to shoot for whenever we're trying to adopt or develop a new behavior.
So instead of trying to test whether somebody has the mental fortitude to stick something out, make it easier.
Make it simpler. The ability here, very often in an organizational setting, what this looks like is creating fewer variations of how to accomplish something.
So reducing from two or three tools for doing reviews of code down to one or two.
Cutting that down. Trying to make a paved road. for people to travel down.
And so, you know, what this will ultimately result in is a lot more people going down the paved road.
Okay, so we have these three areas. And the reason why I say, you know, ability and incentive are kind of tied in this world, right?
Let's imagine that you have your trigger figured out and you have an incentive and you have your ability, right?
Ability in this case is clarifying how to do something.
Very often the how to do it or the instruction that you're providing is trying to point somebody at a finish line.
So you want somebody to accomplish something, deliver something, change some kind of behavior.
And there is some inherent value in whatever that thing was that you were encouraging them to do.
That inherent value is one of the incentive structures, right?
So you can imagine that if something has poorly designed incentives, the question why is not well answered.
Why should I adopt this? What does it give me?
Does it increase the quality of my of my work?
What what exactly do I get out of this and how do I do it?
You know, am I am I doing it right if I do this thing over here or do I have to do it a different way?
Where's the standard for that? How can I ensure that the thing that I'm doing is the right thing in order to accomplish the thing that I'm being asked to do?
So you can see that those are, you know, those concepts kind of overlap with each other.
The ability concept that we're talking about specifically beyond just skills and into the friction discussion and the incentive side.
Because sometimes the incentive is kind of structurally connected to the thing that you're doing.
If it's unclear what you're doing, then the incentive may also become unclear because you're not really sure how to check the box.
So then the reward seems uncertain. It's not really sure what are you rewarding me for?
Right? Okay. And in that situation, those two things tend to go together.
So the reward is uncertain because you're not really sure what the goal is.
The goal is uncertain because you're not really sure where the reward is, right?
And to be very clear, we're not talking about just paying somebody.
We're not talking about creating an incentive structure that requires, you know, a huge amount of resources or something.
To be clear, like an incentive may be that you don't want to do poorly on your performance review.
That's a real incentive, right? The positive side of that incentive is probably going to be more effective, but this framework doesn't assume that incentives are always trying to provide somebody with some kind of benefit if they engage in some behavior.
The beneficial incentives tend to work better just from a scientific standpoint.
So if you don't have an opinion and you have opportunity to use either one, go for something that is a beneficial incentive.
So if you have a beneficial incentive and you have some opportunity very clear pathway.
The ability is if you don't have the skills, we'll train you.
Or if you don't have clarity on how to accomplish the thing, we're going to create better documentation for it.
We're going to reduce the variability, reduce the complexity.
We're going to make it easy to get started.
Instead of running five commands, you can run one command.
We're going to write the script. Whatever the thing is, and we're kind of getting really specific into software engineering now, but it doesn't have to be that specific.
So the investment that you're creating or that you're building is towards these three areas.
A better trigger, a better incentive, and ability.
Lower friction, higher ability, higher skill.
Those three things are the critical factors in getting someone to engage in some kind of behavior change.
Thank you so much for listening to today's episode of Developer Tea.
I hope you enjoyed this episode, and I hope you're enjoying the videos as they begin to come out on YouTube.
We're still working through some of the kinks on the YouTube. the video production, uh, aspect and how to get these videos out, um, you know, alongside the episodes, but we will work through that.
Thank you so much for listening. And until next time, enjoy your tea.
