Hey, everyone, and welcome to Developer Tea.
My name is Jonathan Cottrell. goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers.
Today, I've been thinking a lot about forcing functions.
The idea of a forcing function, we're going to get into this because I see it as the inverse or inverse thinking, inverted version of second or third order consequences.
All right, so let's talk about second or third order consequences, and then we'll talk about forcing functions on the back half.
If you are a good manager, then you probably often... whether you're explicitly calling it this or not, you're probably often thinking about the downstream consequences of an action.
The thing that happens after the first thing that happens.
That's the second thing, by the way, the second order consequence, the third order consequence.
All right, some basic things. think about some basic examples of a second or third order consequence.
A second order consequence of testing your code or tracking code coverage may be that People begin to add tests. for code that aren't actually testing anything, but increase the code coverage metric.
This is very common practice. Whenever you hear somebody setting a target for test coverage, There's probably a good manager in the room who says, not necessarily.
Just because we have high code coverage is not necessarily a good thing.
It's not really a bad thing per se, but it could encourage bad behavior.
Because of the second order consequences.
Right? Third order consequences beyond that second layer.
What's a third-order consequence? Well, maybe people begin to... have less appreciation for what a good test looks like.
Or maybe we start having Incidents, even though we have good test coverage, and now we get disillusioned with the idea of tests in the first place.
Yes. They're not helping us right there.
We're still having incidents despite our high test coverage.
So these are second, third order consequences.
Some some positive second or third order consequences might be.
Giving somebody ownership may be your first action.
Your second order consequence may be That some of the ambiguous things that previously you as a manager, you were having to kind of Over-define, maybe you're a tech lead, right?
Giving someone ownership over something. giving them autonomy, The things that you were having to go and create a bunch of specifications around.
You're having to go and add a ton of detail to your JIRA tickets.
There's nothing necessarily wrong with adding the detail to your tickets, but by giving somebody else ownership, the responsibility of adding that information, that extra detail, now is no longer all centralized up at one person.
The people who have the autonomy and the ownership are likely going to go and invest time filling those details out more completely on their own.
The delegation happens, right? So this is a second-order consequence. right?
So your first action was delegating by providing autonomy, by providing responsibility and ownership to someone.
In response to that autonomy and ownership, instead of just taking whatever they're handed and working through the ticket.
They respond to autonomy and ownership by dealing with the ambiguity. by owning the ambiguity.
That's the second order consequence. The third order consequence...
What's the third order consequence of these folks owning the ambiguity? is that they're going to deliver something that may be better than what you could have come up with on your own.
Because now your time can be spent if you're a manager or a tech lead.
Your time can be spent on new things. on different things you can focus on a smaller a portion of the work to a deeper level and the people that you've provided ownership and Responsibility 2 can focus on that portion.
Another third order consequence, this person has shown initiative and they may end up being up for promotion.
This is because you provided ownership to them.
You are now doing less of the busy work. that you previously were doing, not necessarily bad busy work, just a lot of dealing with ambiguity, which is draining if you're doing too much of it, right?
You've said, you know what? I'm going to let someone else do that.
That other person is energized by this opportunity.
They go and they own it and they end up growing in their career as a result of that, or the second and third order consequences.
Let's imagine the alternative route here for second and third order consequences is you continue you know, shouldering all of the ambiguity reduction work Okay, so all of it's falling on you as the tech lead or all of it's falling on...
The program manager, product manager, or you, the E.M., and you end up with a team The second order consequence here is a team that is constantly expecting you to be involved. in every ticket that they work on.
They're constantly expecting all of the tickets to be perfectly formed or to look at... a certain way before they'll begin working on them.
Come review time, performance management, you know, framework is going to look at the work they did and they're going to pass as satisfactory, but they're not moving up.
They're not taking on new responsibility.
They're not growing. They're just delivering incremental work.
And ultimately you're more stressed out and the quality of the work stays relatively static.
Right? We can kind of evaluate situations and the outcomes that we care about through this second and third order consequence.
Thinking. There's another way to kind of flip this on its head. where you can think about second and third order consequences as forcing functions.
In other words, you can think about the outcome that you want. as kind of the beginning function.
And the upstream requirements of that outcome may also be desirable effects.
So a good example of this, I was recently talking to someone I was kind of coaching through this similar problem.
And their team is a little bit chaotic. In terms of the work that they're doing, it was talking about, you know, how does work happen?
And the forcing function that we discussed is a prioritized backlog. to think about this for a second, alright? your forcing function, the thing that you should focus on, Instead of having 17 things that you're trying to improve all at once,
Try to find focus around one, maybe two or three things.
But focus on this one thing, this prioritized backlog of work. is a forcing function for a bunch of other things that you probably want.
And the way you can do this, the way you can back your way into this is by asking this very simple question.
What must be true? What must be true? In order for me to have a prioritized backlog...
What must be true? How did we arrive there?
This is kind of a pre-mortem type exercise. except in kind of a more positive direction, more of a specific outcome kind of direction.
A pre-celebration exercise so to speak. We have a prioritized backlog.
What else must be true? Well, we must have had a conversation.
We must've had some discussion about the items that are in the backlog.
We must've been able to say no to one thing. in order to say yes to another thing.
We must have been able to have enough information in the backlog in order to prioritize it in the first place.
We must have somebody who is knowledgeable enough to sort through and assign some priority.
All right, so once you have... Once you've kind of labeled this thing a prioritized backlog, it now... also works for second and third order consequences.
So, You say, this is our prioritized backlog.
We're going to work on this. Now, let's imagine that you move forward, you start working on this prioritized backlog, And then someone comes to the table and says, wait a second, that actually, that actually isn't the priority.
As it turns out, this is good feedback because now you have better information to carry into the prioritization process.
Now you have more clarity about the work and that second order consequence just reinforces that having your prioritized backlog in this case was a good forcing function.
You're forcing some kind of upstream and you're forcing a downstream conversation.
So this is the idea of a forcing function is think about.
Both what must be true in order to arrive there.
This very often, a good example of this is, in an organization.
A good example meaning an effective example.
It's not always necessarily good effects.
But an effective version of this is some kind of presentation. right, that's very common in organizations to have something like an all hands or a demo Some juncture where you are kind of standing up against a crowd...
Whether that's in a remote environment or not doesn't really matter. standing up you're recording a video you're doing something to show the work that you've done This is a great forcing function.
In order for that to be successful, what must be true?
You must have worked on that thing. If you haven't, then you can expect for that person to feel fairly uncomfortable and people want to avoid that. uncomfortable feelings, as it turns out.
So, you know, demos and... All hands presentations and discussions like this are good forcing functions for other behaviors that we may care about.
For ourselves, by the way. This is not just a class on... how a manager can get things out of their team.
That's not what we're really focused on here.
Instead, you can do this for yourself. You can make these commitments, for example, that hold you to a certain timeline for action.
This is basically accountability to some degree.
Okay. Other upstream, or rather... other good forcing functions that create upstream pressure or counterpressure.
Maybe things like sprint planning. Spring planning, very simple idea.
Same concept as a prioritized backlog. What must be true in order for us to be ready for spring? and planning.
We have to have an idea of what the priority is.
We have to have an idea of what our capacity for the next two weeks is.
So if I'm coming into sprint planning and I'm responsible for for walking away with a plan, then I need to have a pretty clear idea... of what our capacity is.
I need to have an idea of what we're working on.
What are the priorities, right? is a very similar kind of forcing function.
There are a lot of forcing functions that we ignore every day.
Most of them are social. Most of them are, you know, potentially financial issues.
These are basic incentive forcing functions in our lives. that most of the time they're relying on us making some kind of adjustment by some point. right?
Accomplishing some kind of action by some point.
And so they tend to work as good commitment devices. forcing function to Other forcing functions with teams, especially technical teams, usually land in the category of quality. right?
Or some kind of design. So what must be true, for example, for us to meet You know, P95 response time SLA.
It's a good forcing function for other things to be.
Lined up well. What must be true in order for us to use a particular framework? or use a particular kind of technology.
This is a really big one for hiring, is your technology choice.
Your choice of stack. If I wanted to, for example, select for... people who have a lot of enterprise experience, let's say. then I may choose a tech stack that has more alignment to enterprise tech stacks.
Java, for example, might land in that bucket.
Right? If I wanted to select for People who could easily transfer between frontend and backend.
I might opt for something more like TypeScript.
I want to work with people who I don't know, have some kind of experience with functional programming.
Well, I would choose a functional language.
Somebody who has experience... With legacy systems... then I might use a legacy tech stack.
You get the idea, right? These are, These are forcing functions because they create some back pressure selections.
If you were to go with something like Python or TypeScript, there's a very large community that that selects against.
But if you sub-select the community based on certain specific tools, like certain libraries, for example.
Some libraries are more popular than others.
Some things are more cutting edge. You may choose to work with...
Someone who has worked in event-oriented systems.
What is that a forcing function for? I'm not going to actually answer all of these because You can fill in the blank.
There may be multiple things that you're essentially forcing as a result of that.
Another good example of a forcing function and some of these are accidental.
So this is the reason I'm doing this episode in the first place.
So you can choose your forcing functions and also be aware of the ones that you are accidentally opting into.
Okay. One good forcing function. would be something like a remote policy or something dealing with your workplace restrictions, okay?
So for example... if you had a workplace restriction, that required that somebody work and be available uh on you know at night let's say i don't know this is an arbitrary policy okay Well, in that case, you may be creating a forcing function for people who don't have other commitments.
What does that mean? Well, there may be a large group of people who don't have other commitments.
But this may end up being an accidental kind of backwards discrimination against people who are relatively involved in their communities.
Maybe they volunteer. Well, those people would not fit well inside of this forcing function.
Maybe they have a family. Those people won't fit well inside of this forcing function. if they're active in their community, maybe they're social, maybe they play sports, intramural sports, Whatever the reason is, when you create a subselection, you should consider, what am I... accidentally forcing. this group to look like?
What am I accidentally forcing the actions both upstream and downstream, to look like.
And then on the flip side, you can use this as a tool.
You can use it as a tool and try to understand or try to draw out what is the one thing indicator the one downstream indicator That kind of gives me a lot of the things that I care about upstream from that.
In our previous example, that was the prioritized backlog.
In order to have a prioritized backlog, you have to have a lot of other things right.
A good example of this is also hiring, recruiting.
In order to recruit well... and to have good signals on recruiting for other people to... want to join your company, you have to have a lot of other things right. especially in a sustained manner, right?
You have to have some level of success in your company.
You have to have some level of success in the technical side of your company You have to be attractive from a technical standpoint, which means that your retention is probably pretty high. right you have to uh you know be competitive in the market which also likely means that you have a high standard for talent in your organization. which is attractive to engineers.
So a lot of things have to be right for recruiting to be working well.
And if recruiting is not working well in your company, There's a good chance that there is something that's causing that that isn't necessarily directly connected to recruiting. or some other improvement that you could be making with the measure of success being recruiting.
You can't recruit well because you're not paying good salaries.
You're not paying good salaries Because either your company is not doing as well as it could be or your understanding of the bar isn't. is too low, right?
And so you're trying to attract... You may say that you want higher talent, but you're not willing to pay for it, and therefore the talent that you're attracting is lower talent.
And so your recruitment is failing. So there's a lot of things that you would need to get right. in order to succeed in recruiting.
So this is a good forcing function. It's a good forcing function. possibly hundreds of these forcing functions that you could figure out for your team, for your individual engineers, and for yourself.
The thing I want you to think about as you leave this episode, the one thing I want you to take away. is how do you think about forcing functions and downstream effects? of your actions second order third order actions and tie that together so that you are both able to be a little bit more mindful and predictive about the things that may happen in the future based on today's actions, right?
And then you set goals that imply Rather than dictating, your goals are implying things that must be true. is a much smarter way of controlling your inputs. is by defining a downstream state that you want to arrive at.
How you arrive there may actually not matter all that much. right?
The forcing function that you're creating this downstream effect that you're trying to achieve, uh, the actual how may actually not matter all that much at all.
But your forcing function very likely is implying some kind of improvement that you do care about.
Thank you so much for listening to today's episode of Developer Tea.
I hope you enjoyed this discussion about forcing functions.
First, second, third order effects. Hopefully you will be thinking about your own functions that you've seen, And more importantly, as you go through your career, as you go through just this next week.
Try to be mindful when you when you are encountering these forcing functions.
Try to be mindful of when you're making especially impactful decisions, what the second and third order effects may be.
Thanks so much for listening. Until next time, enjoy your tea.
