Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell. My 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 this a forcing function or not, you're probably going to get into this a lot. And 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. Let's 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. All right, this is very common. You know, whenever you hear somebody setting a target for testing, you're going to hear somebody setting a target for testing. You're going to hear somebody setting a target for testing. You're going to hear somebody setting a target for testing. You're going to hear somebody setting a target for testing. You're going to hear somebody setting a target for testing. You're going to hear somebody setting there's probably a good manager in the room who says, not necessarily. All right, 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. They're not helping us, right? We're still having incidents despite our high test coverage. So these are second, third-order consequences. Some positive second or third-order consequences might be giving somebody ownership, maybe 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 your tech lead, right? Giving someone ownership over something, giving them autonomy, you know? The things that you were having to go and create a bunch of specifications around. You were having to go and add a ton of detail to your JIRA tickets, right? 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 like, oh, I'm going to do this. I'm going to do this. I'm going to do this. I'm going to do this. I'm going to do this. I'm 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, right? In response to that autonomy and ownership, instead of just taking whatever they're handed and working through the ticket, they, 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, you know, 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 portion of the work to a deeper level, and the people that you've provided ownership and responsibility to, can focus on that portion. Another third-order consequence, this person has shown initiative, and they may end up being up for a job, right? And they may end up being up for a job, right? And they may end up being up for a job, right? This is because you provided ownership to them. You are now doing less of the busy work that you previously were doing. Not necessarily, you know, bad busy work. Just a lot of dealing with ambiguity, which is draining if you're doing too much of it, right? So, 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 EM. 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, you know, a certain way, before they'll begin working on them. Come review time, performance management, you know, framework, you know, management 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. So 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, a similar problem. And their team is, you know, there's a little bit chaotic in terms of the work that they're doing. It was, it was, it was, it was, you know, how, how does work happen? And the forcing function that we discussed is a prioritized backlog. To think about this for a second, all right? Your forcing function, the thing that you should focus on, instead of having, you know, 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 premortem 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 have had some discussion about the items that are in the backlog. We must have 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've kind of labeled this thing a prioritized backlog, it now, what's the next step? What's the next step? What's the next step? What's the next step? What's the next step? 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 know, you, 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, right? You're, 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, what must be true in order to arrive there, right? This very often a good example of this 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 a very common in organizations to have something like an all hands or a demo. You know, some, some juncture where you are kind of, you know, you're standing up against a crowd, whether that's in a remote environment or not, doesn't really matter. You're 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, right? If you haven't, then you can expect for that person to feel fairly uncomfortable and people want to avoid uncomfortable. Feelings as it turns out. So, uh, you know, demos and all hands presentations and discussions like this are good forcing functions for other behaviors that we may care about. All right. For ourselves, by the way, not just, this is not just a, you know, a class on how a manager can get things out of their team. That's not what we're really focused on here. Instead, uh, you can do this for yourself. You can make these commitments, for example, that hold you to a certain timeline for action, right? This is basically accountability to some degree. Okay. Uh, other upstream, uh, or, or rather, um, other good forcing functions that create upstream, um, you know, pressure, counter pressure, maybe things like sprint planning, sprint planning, very simple ideas, same, same concept as a prioritized background. So, uh, you can do this for yourself. You can make these commitments, what must be true in order for us to be ready for sprint planning. We have to have an idea of what, 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 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. It's 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, uh, uh, are, uh, you know, potentially financial. These are basic incentive forcing functions in our lives that most of the time they're relying on us, um, you know, making some kind of adjustment by some point, right? Uh, you know, there are a lot of forcing functions that Accomplishing some kind of action by some point. And so they tend to work as good commitment devices, forcing functions too. Other forcing functions tend, 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 a 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? A really big one for hiring is your technology choice. Right? 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 front-end and back-end, I might opt for something more like TypeScript. Right? 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 forcing functions because they create some... Back pressure selection. 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. At the same time, they may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution may have evolution, evolution 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 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, 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 group of people, 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 indicator, the one downstream indicator that kind of gives me a better idea of what is going on in my community. And then you can use this 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. 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. You have to have 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. A lot of things have to be right for recruiting to be working well. 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... to recruiting. There's 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 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. There are possibly hundreds of these forcing functions that you could figure out for your team, for your... for your team. for your... for your... for your... individual engineers and for yourself. The thing I want you to think about as you leave this episode, you know, 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. Second order actions and tie that together so that you are both able to be a little bit more pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch pinch 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, 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, about 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 are encountering these forcing functions. Try to be mindful of when you're making especially impactful decisions, what they're going to be. And I hope you enjoyed this episode of Developer Tea. Second and third order effects, maybe. Thanks so much for listening. Until next time, enjoy your tea.