Vox

Leitura de 24 min

Second Order Consequences and Forcing Functions

Summary

In this episode, Jonathan Cottrell explores the interconnected concepts of second/third-order consequences and forcing functions. He begins by explaining how actions have ripple effects beyond their immediate outcomes, using examples from software development and management. For instance, mandating high code coverage can lead to developers writing meaningless tests just to hit metrics, which may eventually cause disillusionment with testing altogether.

Cottrell then contrasts this with positive examples, such as delegating ownership to team members. The first-order action is giving autonomy; the second-order consequence is that team members take responsibility for ambiguity; the third-order consequence is they deliver better work and grow in their careers, while managers free up time for higher-level tasks. This framework helps evaluate decisions by considering their extended impacts.

The discussion shifts to forcing functions—choosing a desired downstream outcome that necessitates certain upstream behaviors. A prioritized backlog serves as a prime example: to have one, teams must have conversations, say no to some items, and gather sufficient information. This forcing function naturally improves clarity and prioritization processes. Other examples include sprint planning, demos, and specific technology choices that shape hiring and team composition.

Cottrell emphasizes that many forcing functions are accidental, like workplace policies that inadvertently select against people with family or community commitments. By being intentional, developers and managers can choose forcing functions that align with their goals. The episode concludes by encouraging listeners to set goals that imply necessary conditions rather than dictating steps, allowing the forcing function to drive improvements organically.

Topic Timeline

  • 00:00:00 — Introduction to forcing functions and second-order consequences — Jonathan Cottrell introduces the episode’s focus on forcing functions as an inverted way of thinking about second and third-order consequences. He explains that good managers often consider downstream effects of actions, which is the core of second-order thinking. The episode will first explore consequences and then examine forcing functions.
  • 00:01:27 — Examples of second and third-order consequences in software — Cottrell provides concrete examples of second and third-order consequences. Mandating code coverage can lead to developers writing useless tests to hit metrics (second-order), which may then erode appreciation for good testing or cause incidents despite coverage, leading to disillusionment (third-order). He contrasts this with positive consequences of delegating ownership, where autonomy leads to team members handling ambiguity and ultimately delivering better work.
  • 00:06:00 — The alternative path: centralizing ambiguity reduction — The discussion explores the alternative scenario where a manager shoulders all ambiguity reduction work. The second-order consequence is a team that expects perfect tickets and constant involvement. The third-order consequence is stagnant career growth for team members and increased stress for the manager, with work quality remaining static. This highlights how consequence thinking helps evaluate outcomes.
  • 00:07:37 — Introducing forcing functions as inverted thinking — Cottrell introduces forcing functions as flipping consequence thinking on its head. Instead of predicting outcomes from actions, you start with a desired downstream outcome and work backward to determine what must be true upstream. This approach focuses on creating conditions that naturally lead to the goal, rather than micromanaging the process.
  • 00:08:33 — The prioritized backlog as a forcing function — A prioritized backlog is presented as a key forcing function example. To have one, teams must have discussions, say no to some items, and have sufficient information. This forcing function improves clarity and prioritization. When someone challenges the priority, it provides valuable feedback, reinforcing the process. Cottrell explains how to use the question ‘What must be true?’ to identify necessary upstream conditions.
  • 00:11:46 — Other organizational forcing functions: demos and presentations — Cottrell discusses demos, all-hands presentations, and similar events as effective forcing functions. To present successfully, work must be completed, creating pressure to deliver. These social accountability mechanisms leverage people’s desire to avoid discomfort. He notes that forcing functions aren’t just managerial tools—individuals can use commitments and timelines as personal forcing functions.
  • 00:13:51 — Technical and hiring forcing functions — The episode explores technical forcing functions like SLAs for response times or specific technology choices. Choosing a tech stack (e.g., Java for enterprise, TypeScript for full-stack) acts as a forcing function for hiring by selecting candidates with certain experiences. Cottrell emphasizes that these choices create ‘back pressure’ that shapes team composition and capabilities.
  • 00:17:23 — Accidental forcing functions and intentional selection — Cottrell warns about accidental forcing functions, such as workplace policies that require nighttime availability. These may inadvertently discriminate against people with families or community commitments. He encourages listeners to consciously choose forcing functions that align with goals and to consider what behaviors or demographics they might be accidentally selecting for or against.
  • 00:19:33 — Recruiting as a forcing function for organizational health — Successful recruiting is presented as a forcing function that implies many other things are working well: company success, technical attractiveness, high retention, competitive compensation. If recruiting fails, it signals deeper issues like low salaries or misaligned standards. This makes recruiting a valuable indicator of overall organizational health.
  • 00:21:44 — Conclusion: mindfulness and goal-setting with forcing functions — Cottrell concludes by encouraging listeners to be mindful of forcing functions and second/third-order effects in their careers. He suggests setting goals that imply necessary conditions rather than dictating steps—a smarter way to control inputs by defining desired downstream states. This approach allows the forcing function to drive improvements organically.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2025-08-22T07:00:00Z
  • Duration: 00:23:45

References

Podcast Info

Transcript

[00:00:00] Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell. My goal on this

[00:00:13] show is to help driven developers like you find clarity, perspective, and purpose in

[00:00:17] their careers. Today I’ve been thinking a lot about forcing functions. The idea of a

[00:00:27] forcing function, we’re going to get into this because I see it as the inverse or inverse

[00:00:34] thinking, inverted version of second or third order consequences. All right, so let’s talk

[00:00:41] about second or third order consequences and then we’ll talk about forcing functions on

[00:00:46] the back half. If you are a good manager, then you probably often, whether you’re explicitly

[00:00:55] calling this a forcing function or not, you’re probably going to get into this a lot. And

[00:00:57] calling it this or not, you’re probably often thinking about the downstream consequences

[00:01:04] of an action. The thing that happens after the first thing that happens.

[00:01:11] That’s the second thing, by the way, the second order consequence, the third order consequence.

[00:01:19] All right, some basic things. Let’s think about some basic examples of a second or third order

[00:01:27] consequence. A second order consequence of testing your code or tracking code coverage

[00:01:36] may be that people begin to add tests for code that aren’t actually testing anything but increase

[00:01:45] the code coverage metric. All right, this is very common. You know, whenever you hear somebody

[00:01:54] setting a target for testing, you’re going to hear somebody setting a target for testing,

[00:01:57] there’s probably a good manager in the room who says, not necessarily. All right, just because we

[00:02:05] have high code coverage is not necessarily a good thing. It’s not really a bad thing per se,

[00:02:12] but it could encourage bad behavior because of the second order consequences.

[00:02:18] Right? Third order consequences beyond that second layer. What’s a third order consequence? Well,

[00:02:27] maybe people begin to have less appreciation for what a good test looks like. Or maybe we start

[00:02:37] having incidents even though we have good test coverage. And now we get disillusioned with the

[00:02:43] idea of tests in the first place. They’re not helping us. Right there. We’re still having

[00:02:49] incidents despite our high test coverage. Right? So these are second, third order consequences.

[00:02:57] Some positive second or third order consequences might be giving somebody ownership. Maybe your

[00:03:06] first action. Your second order consequence may be that some of the ambiguous things

[00:03:12] that previously you as a manager, you were having to kind of over-define. Maybe you’re a tech lead,

[00:03:19] right? Giving someone ownership over something, giving them autonomy. You know, the things that

[00:03:27] you were having to go and create a bunch of specifications around. You were having to go

[00:03:31] and add a ton of detail to your JIRA tickets. Right? There’s nothing necessarily wrong with

[00:03:36] adding the detail to your tickets, but by giving somebody else ownership, the responsibility of

[00:03:44] adding that information, that extra detail, now is no longer all centralized up at one person.

[00:03:52] The people who have the autonomy and the ownership are likely going to go,

[00:03:57] invest time, filling those details out more completely on their own. Right? The delegation

[00:04:03] happens. Right? So this is a second order consequence. Right? So your first action

[00:04:09] was delegating by providing autonomy, by providing responsibility and ownership to someone.

[00:04:16] Right? In response to the autonomy and ownership, instead of just taking whatever they’re handed

[00:04:21] and working through the ticket, they respond to,

[00:04:27] autonomy and ownership by dealing with the ambiguity, by owning the ambiguity.

[00:04:35] That’s the second order consequence. The third order consequence, what’s the third order

[00:04:40] consequence of these folks, you know, owning the ambiguity is that they’re going to deliver

[00:04:46] something that may be better than what you could have come up with on your own. Because

[00:04:54] now your time can be spent.

[00:04:57] If you’re a manager or a tech lead, your time can be spent on new things, on different things.

[00:05:05] 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.

[00:05:19] Another third-order consequence, this person has shown initiative, and they may end up being up for promotion.

[00:05:27] This is because you provided ownership to them.

[00:05:29] 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.

[00:05:45] You’ve said, you know what? I’m going to let someone else do that.

[00:05:48] That other person is energized by this opportunity.

[00:05:51] They go and they own it, and they end up growing in their career as a result of that.

[00:05:57] The second and third-order consequences.

[00:06:00] Let’s imagine the alternative route here for second and third-order consequences is you continue shouldering all of the ambiguity reduction work.

[00:06:14] 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.

[00:06:27] You end up with a team.

[00:06:29] The second-order consequence here is a team that is constantly expecting you to be involved in every ticket that they work on.

[00:06:39] They’re constantly expecting all of the tickets to be perfectly formed or to look a certain way before they’ll begin working on them.

[00:06:51] Come review time, performance management framework is going to look at the work they do.

[00:06:56] They’re going to look at the work they did, and they’re going to pass as satisfactory, but they’re not moving up.

[00:07:02] They’re not taking on new responsibility.

[00:07:04] They’re not growing.

[00:07:05] They’re just delivering incremental work.

[00:07:10] Ultimately, you’re more stressed out, and the quality of the work stays relatively static.

[00:07:18] We can evaluate situations and the outcomes that we care about through this second and third-order consequence thinking.

[00:07:26] There’s another way to flip this on its head, where you can think about second and third-order consequences as forcing functions.

[00:07:37] In other words, you can think about the outcome that you want as the beginning function and the upstream requirements of that outcome.

[00:07:57] You can try everything in a fair way.

[00:08:10] You can do a particular task, and the outcome may be made by carrying it.

[00:08:17] You may also be able to wish it to happen some other way.

[00:08:19] I can think of two things.

[00:08:20] The first is you’re not looking at somebody else’s plan for the future, and you’re looking at somebody else’s quality and well-being.

[00:08:21] You’re not looking at the other party and you have to think about the way you want to bring that value into the team that works.

[00:08:22] You’re not going to want to expect that to happen as somebody else.

[00:08:23] You were just letting that process of mail in both sections.

[00:08:23] You’re not going to want to push the line.

[00:08:24] You’re not going to move out there and be like, I’m going to start my own несколько decades before it そう bei accent�� Stickmix

[00:08:24] happen. And the forcing function that we discussed is a prioritized backlog.

[00:08:33] To think about this for a second, all right? Your forcing function, the thing that you should focus

[00:08:39] on, instead of having, you know, 17 things that you’re trying to improve all at once,

[00:08:45] try to find focus around one, maybe two or three things. But focus on this one thing,

[00:08:51] this prioritized backlog of work, is a forcing function for a bunch of other things that you

[00:08:58] probably want. And the way you can do this, the way you can back your way into this,

[00:09:04] is by asking this very simple question, what must be true? What must be true? In order for me to have

[00:09:15] a prioritized backlog, what must be true?

[00:09:19] How did we arrive there, right? This is kind of a premortem type exercise,

[00:09:26] except in kind of a more positive direction, more of a specific outcome kind of direction,

[00:09:32] a pre-celebration exercise, so to speak. We have a prioritized backlog. What else must be true?

[00:09:41] Well, we must have had a conversation. We must have had some discussion about the items that

[00:09:47] are in the backlog. We must have been able to say,

[00:09:49] no to one thing in order to say yes to another thing. We must have been able to have enough

[00:09:56] information in the backlog in order to prioritize it in the first place. We must have somebody who

[00:10:05] is knowledgeable enough to sort through and assign some priority. Once you’ve labeled this

[00:10:16] thing a prioritized backlog, it now also works for second and third order consequences. You say

[00:10:24] this is our prioritized backlog. We’re going to work on this. Let’s imagine that you move forward,

[00:10:30] you start working on this prioritized backlog, and then someone comes to the table and says,

[00:10:34] wait a second, that actually isn’t the priority. As it turns out, this is good feedback because now

[00:10:43] you have better information to carry.

[00:10:46] Into the prioritization process. Now you have more clarity about the work and that second

[00:10:54] order consequence just reinforces that having your prioritized backlog in this case was a good

[00:11:01] forcing function, right? You’re, you’re forcing some kind of upstream and you’re forcing a

[00:11:09] downstream conversation. So this is, um, the idea of a forcing function is

[00:11:15] think about it. You’re forcing a downstream conversation. So this is, um, the idea of a

[00:11:16] think about both what must be true in order to arrive there, right? This very often a good

[00:11:24] example of this in an organization, a good example, meaning an effective example. It’s

[00:11:29] not always necessarily good effects, but an effective version of this is, uh, some kind of

[00:11:37] presentation, right? This is very common in organizations to have something like an all

[00:11:43] hands or a demo. There’s some kind of presentation that’s very common in organizations to have

[00:11:46] something like an all hands or a demo. There’s some kind of presentation that’s very common in

[00:11:46] organizations to have something like an all hands or a demo. There’s some, some juncture where you

[00:11:48] are kind of standing up against a crowd, uh, whether that’s in a remote environment or not,

[00:11:55] doesn’t really matter. You’re standing up, you’re recording a video, you’re doing something to show

[00:11:59] the work that you’ve done. This is a great forcing function in order for that to be successful. What

[00:12:05] must be true? You must have worked on that thing, right? If you haven’t, then you can expect for

[00:12:15] that person to feel fairly uncomfortable. You can expect for that person to feel fairly uncomfortable.

[00:12:16] People want to avoid uncomfortable feelings as it turns out. So, uh, you know, demos and all hands

[00:12:26] presentations and discussions like this are good forcing functions for other behaviors that we may

[00:12:32] care about. All right. For ourselves, by the way, not just, this is not just a, you know, a class on

[00:12:39] how a manager can get things out of their team. That’s not what we’re really focused on here.

[00:12:44] Instead, uh, you can do this for yourself. You can make these commitments, for example,

[00:12:50] that hold you to a certain timeline for action, right? This is basically accountability to some

[00:12:58] degree. Okay. Uh, other upstream, uh, or, or rather, um, other good forcing functions that

[00:13:05] create upstream, um, you know, pressure, counter pressure, maybe things like sprint planning.

[00:13:14] Sprint planning, very simple ideas, same, same concept as a, as a prioritized backlog. What must

[00:13:19] be true in order for us to be ready for sprint planning? We have to have an idea of what,

[00:13:25] what the priority is. We have to have an idea of what our capacity for the next two weeks is.

[00:13:31] So if I’m coming into sprint planning and I’m responsible for walking away with a plan,

[00:13:37] then I need to have a pretty clear idea of what our capacity is. I need to have an idea of what

[00:13:43] we’re working on. What are the priorities? I need to have an idea of what we’re working on. What are the

[00:13:44] priorities, right? It’s a very similar kind of forcing function. There are a lot of forcing

[00:13:51] functions that we ignore every day. Most of them are social. Most of them, uh, uh, are, uh, you

[00:13:59] know, potentially financial. These are basic incentive forcing functions in our lives that

[00:14:07] most of the time they’re relying on us, um, you know, making some kind of

[00:14:14] adjustment by some point, right? Uh, accomplishing some kind of action by some point.

[00:14:23] And so they tend to work as good commitment devices, uh, forcing functions too. Uh, other

[00:14:33] forcing functions tend with teams, especially technical teams, uh, usually land in the category

[00:14:42] of quality, right?

[00:14:44] So, or, or some kind of design. So what must be true, for example, for us to meet, uh, you know,

[00:14:51] a P95 response time SLA. It’s a good forcing function for other things to be lined up well.

[00:15:01] What must be true in order for us to, you know, use a particular framework, right? Or use a

[00:15:07] particular kind of technology. This is a really big one for hiring is your technology choice,

[00:15:13] right?

[00:15:14] Your, your choice of stack. If I wanted to, for example, uh, select for people who have a lot of

[00:15:21] enterprise experience, let’s say, then I may choose a tech stack that has more alignment to

[00:15:29] enterprise tech stacks. Java, for example, might, might land in that bucket, right? If I wanted to,

[00:15:36] uh, select for people who could easily transfer between front end and back end, I might opt for

[00:15:43] something more like typesetting.

[00:15:44] Script, right? Um, I want to, you know, work with people who, I don’t know, uh, have, have some kind

[00:15:53] of, uh, experience with functional programming. Well, I would choose a functional language,

[00:15:59] somebody who has, um, you know, experience, uh, you know, with legacy systems that I might use

[00:16:08] a legacy tech stack. You get the idea, right? These are, these are forcing functions because,

[00:16:14] they create some back pressure selection. If you were to go with something like Python or

[00:16:22] TypeScript, there’s a very large community that that selects against. But if you sub select the,

[00:16:30] the community, uh, based on certain specific tools, like certain libraries, for example,

[00:16:37] right? Some libraries are more popular than others. Uh, some things are, you know, more cutting edge.

[00:16:44] You may, um, you know, choose to work with someone who has worked in event oriented systems,

[00:16:52] right? What, what is that a forcing function for? I’m not going to actually answer all of these

[00:16:56] because you can fill in the blank. There may be multiple things that you’re essentially,

[00:17:01] uh, forcing as a result of that. Another good example of, of a forcing function. And

[00:17:07] some of these are accidental. So this is the reason I’m doing this episode in the first place

[00:17:11] is so you can choose your forcing function. You can choose to do it in a different way. You can

[00:17:14] also be aware of the ones that you are accidentally opting into. Okay. One good forcing function

[00:17:23] would be something like a remote policy or, uh, something dealing with, um, your,

[00:17:33] your workplace restrictions. Okay. So for example, if you had a, a workplace restriction,

[00:17:42] uh, that required, uh, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a,

[00:17:44] that somebody work and be available, uh, on, you know, at night, let’s say, I don’t know,

[00:17:51] this is an arbitrary policy. Okay. Well, in that case, you may be creating a forcing function

[00:17:58] for people who don’t have other commitments. What does that mean? Well, there may be a large

[00:18:07] group of people who don’t have other commitments. Uh, but this may end up being an accidental

[00:18:14] kind of backwards discrimination against people who are relatively involved in their communities.

[00:18:20] Maybe they volunteer. Well, those people would not fit well inside of this forcing function.

[00:18:26] Uh, maybe they have a family. Those people won’t fit well inside of this forcing function.

[00:18:31] If they’re active in their community, maybe they’re social. Maybe they play sports,

[00:18:35] intramural sports, whatever the, the reason is when you create a subselection, you should consider

[00:18:42] what am I?

[00:18:44] Accidentally forcing this group to look like, what am I accidentally forcing the actions,

[00:18:52] both upstream and downstream to look like? And then on the flip side, you can use this as a tool.

[00:19:00] You can use it as a tool and try to understand or try to draw out what is the one indicator,

[00:19:08] the one downstream indicator that kind of gives me a lot of the things that I,

[00:19:14] care about upstream from that, right? In, in, in our previous example, that was the prioritized

[00:19:20] backlog. In order to have a prioritized backlog, you have to have a lot of other things, right?

[00:19:25] Uh, a good example of this is also hiring, recruiting in order to recruit well,

[00:19:33] uh, and, and to have good signals on recruiting for other people to want to join your company,

[00:19:42] you have to have a lot of other things, right?

[00:19:44] Especially in, in a sustained manner, right? You have to, uh, have some level of success in your company.

[00:19:53] You have to have some level of success in the technical side of your company.

[00:19:57] You have to be attractive from a technical standpoint, which means that your retention is probably pretty high, right?

[00:20:05] You have to, uh, you know, be competitive in the market, which also likely means that you have, uh, you know, a high, a high

[00:20:13] standard.

[00:20:14] For talent in your organization, which is attractive to engineers.

[00:20:18] So a lot of things have to be right for recruiting to be working well.

[00:20:23] And if it’s not, if recruiting is not working well in your company, there’s a good chance that there is something that’s causing that,

[00:20:33] that isn’t necessarily directly connected to, to recruiting.

[00:20:38] There’s some other improvement that you could be making with the measure of success.

[00:20:44] Being recruiting, you can’t recruit well because you’re not paying good salaries.

[00:20:52] You’re not paying good salaries because, uh, either your, your company is not doing as well as it could be, or your understanding of the bar is too low.

[00:21:03] Right.

[00:21:04] And so you’re a track, you’re trying to attract, uh, you, you know, you may say that you want higher talent, but you’re not willing to pay for it.

[00:21:11] And therefore the talent that you’re attracting is lower talent.

[00:21:13] And so you’re trying to attract, uh, you, you know, you may say that you want higher talent, but you’re not willing to pay for it.

[00:21:14] And so your, uh, recruitment is failing.

[00:21:17] So there’s a lot of things that you need, you would need to get right, uh, in order to succeed in recruiting.

[00:21:23] So this is a good forcing function.

[00:21:25] It’s a good forcing function.

[00:21:26] There are, uh, you know, possibly hundreds of these, uh, forcing functions that you could figure out for your team, for your, uh, individual engineers and for yourself.

[00:21:41] The thing I want you to think about as you leave this episode.

[00:21:44] Uh, you know, the, 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.

[00:22:11] Right.

[00:22:13] And then you set.

[00:22:14] Goals that imply rather than dictating your goals are implying things that must be true as 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?

[00:22:41] The forcing function that you’re creating this downstream.

[00:22:44] Effect that you’re trying to achieve, uh, the actual, how may actually not matter all that much at all, but your forcing function, uh, very likely is implying some kind of improvement that you do care about.

[00:23:02] Thank you so much for listening to today’s episode of developer T.

[00:23:04] I hope you enjoyed this discussion about forcing functions.

[00:23:07] It’s about first, second, third order effects.

[00:23:10] Uh, hopefully you will be thinking about your own.

[00:23:13] Uh,

[00:23:14] you know, for functions that you’ve seen, um, and more importantly, as you go through your career, as you go through just this next week, try to be mindful when you, uh, 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.

[00:23:34] Thanks so much for listening until next time.

[00:23:36] Enjoy your tea.

[00:23:44] Thank you.

Visão de gráfico