Vox

Leitura de 19 min

Principles of Work - Shorten Your Feedback Loops

Summary

This episode explores the core principle of shortening feedback loops in work and learning contexts. The host introduces the principle: “Make your feedback loops short enough that any singular action is cheap enough that when you’re wrong, the value of learning outweighs the cost of being wrong.” This concept is fundamental to agile methodologies, lean practices, and learning theory, drawing from behavioral science and psychology.

The discussion breaks down the essential components of a complete feedback loop: action, measurement of that action, review of the measurement, decision about the decision, and adjustment before restarting the loop. The host emphasizes that shortening feedback loops isn’t just about frequent retrospectives—it requires having the agency to make adjustments based on what’s learned. Without the ability to change direction, the feedback loop remains incomplete.

The episode examines why shortening feedback loops matters from an economic perspective, considering costs in terms of time, effort, and satisfaction. There’s an optimal length for feedback loops represented by a J-curve—too short creates overhead that outweighs learning value, while too long increases risk and cost. The host uses the example of teams with two-week versus two-month sprints to illustrate how shorter loops provide better risk mitigation in uncertain environments like software engineering.

Several key benefits of optimized feedback loops are explored: risk mitigation in areas of uncertainty, reduced friction to action (encouraging decisiveness), and improved quality of messaging within the loop. Shorter loops create tighter correlation between actions and measurements, reducing noise and confounding variables. The episode concludes by encouraging listeners to apply this principle beyond sprint cadences to areas like code testing where immediate feedback can be valuable.

Recommendations

Communities

  • Developer Tea Discord — The Discord community for Developer Tea listeners, mentioned as a place to join for further discussion and engagement with the podcast community.

Tools

  • Unblocked — A tool that provides helpful and accurate answers to questions about your code base in seconds by complementing source code with relevant discussions from GitHub, Slack, JIRA, Notion, Confluence, and other sources. It helps teams ship faster by reducing time spent digging for information.

Topic Timeline

  • 00:00:00 — Introduction to the feedback loop principle — The episode introduces the core principle of shortening feedback loops, explaining its roots in agile methodologies, lean practices, and learning theory. The host presents the formal principle: making feedback loops short enough that the value of learning from mistakes outweighs the cost of being wrong. This sets up the foundational concept for the entire discussion.
  • 00:02:00 — Defining what shortening feedback loops means — The host clarifies that shortening feedback loops requires both regular retrospective review and the agency to make adjustments. Simply looking back without the ability to change direction doesn’t complete the feedback loop. The discussion emphasizes that adjustment is a critical component that enables learning and course correction.
  • 00:03:31 — The five components of a complete feedback loop — The episode breaks down the essential parts of a feedback loop: action, measurement of that action, review of the measurement, decision about the decision, and adjustment before restarting. The host explains that missing any of these pieces means the feedback loop is incomplete, and shortening just part of the process doesn’t fulfill the principle’s requirements.
  • 00:06:45 — The economics of feedback loop optimization — The discussion shifts to why shortening feedback loops matters from an economic perspective, considering costs in time, effort, and satisfaction. The host introduces the J-curve concept for feedback loop optimization—there’s an optimal length where the loop is cheapest relative to learning value. Too short creates overhead; too long increases risk and cost.
  • 00:09:18 — Example comparing two-week vs two-month sprints — Using a concrete example, the host compares teams with two-week sprints versus two-month sprints. The two-week team can catch and correct mistakes more frequently, reducing risk. The two-month team might continue down mistaken pathways longer, making errors more expensive. This illustrates the risk mitigation benefits of shorter feedback cycles.
  • 00:11:48 — Key benefits of optimized feedback loops — The episode explores several important benefits of shortening feedback loops: risk mitigation in uncertain environments, reduced friction to action (encouraging decisiveness), and improved messaging quality within the loop. Shorter loops create tighter correlation between actions and outcomes, reducing noise and making learning more effective.
  • 00:14:33 — How shorter loops improve measurement quality — The host explains that shorter feedback loops increase the quality of messaging within the system by reducing the likelihood of confounding variables. When measurements happen closer to actions, there’s higher cohesion to reality, making it easier to attribute outcomes to specific decisions. This makes the learning process more efficient and less ‘leaky.’
  • 00:17:00 — Conclusion and practical applications — The episode concludes by reiterating the simple heuristic: shorten your feedback loops. The host notes there’s an optimal length that varies by context, and the principle applies beyond sprint cadences to areas like code testing. Listeners are encouraged to join the Developer Tea Discord community and check out the sponsor, Unblocked.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2024-04-03T07:00:00Z
  • Duration: 00:18:07

References

Podcast Info

Transcript

[00:00:00] We’re going to talk about a working principle in today’s episode of Developer T, and this

[00:00:14] principle is one that is core to every agile discussion, every lean discussion, and it’s

[00:00:26] core to another industry, and that’s the learning industry, or specifically learning theory,

[00:00:36] and this principle is based on things that come from behavioral science and study of

[00:00:47] psychology. The principle is based on the idea of feedback loops. Here’s the principle.

[00:00:56] It’s very simple. Make your feedback loops short enough that any singular action is cheap enough

[00:01:06] that when you’re wrong, the value of learning outweighs the cost of being wrong. I’m going to say

[00:01:16] that again because it’s kind of a long one. Make your feedback loops short enough that any singular

[00:01:23] action is cheap enough that when you’re wrong, the value of learning that you get from being wrong

[00:01:29] is cheaper than the cost of being wrong in the first place. Said another way, shorten your feedback

[00:01:39] loops so that mistakes provide learning that outweighs the cost of making those mistakes.

[00:01:45] There’s a very interesting underlying structure here that I want to expose, but I want to focus

[00:01:54] first on the idea of shortening your feedback loops. What does this mean exactly? It can mean

[00:02:00] a lot of different things depending on the context. Very importantly, the requirement to shorten a

[00:02:07] feedback loop in this principle is two things. One, it allows you to, on a regular basis, review

[00:02:15] in some kind of retrospective way. You’re looking back at whatever decision, whatever action you’ve

[00:02:20] taken, and looking at measuring some kind of result. You’re trying to understand what was the

[00:02:27] impact of the action that I took. Shortening the feedback loop has all kinds of good effects that

[00:02:31] we’re going to talk about after our sponsor message today. The important thing to qualify

[00:02:37] the shortening of the feedback loop, you need to be able to change direction. It’s not enough

[00:02:45] just to continuously retrospect on what you’ve been doing. You need the agency to be able to

[00:02:51] make adjustments. Otherwise, all of this ends up being kind of a lost cause. If all you’re doing

[00:02:59] is you’re retrospectively looking at what you have done in the past two weeks, but you don’t have any

[00:03:07] agency to adjust your heading, you can’t change anything about what you’re learning, then it’s not

[00:03:14] really fitting the mold of shortening the feedback loop. The feedback loop includes, very importantly,

[00:03:23] includes adjustment. The parts of the feedback loop, just very briefly, the parts that you

[00:03:31] need to have for the feedback loop to be complete. First is an action, some kind of action, whatever

[00:03:38] it is, a decision, maybe some kind of code deployment that you do, whatever it is.

[00:03:46] Second is a measurement of that action, so some kind of, hopefully, some kind of objective

[00:03:55] measurement in the best case. Three, review of that measurement, and here we’re looking to see

[00:04:02] if we believe that the measurement is indeed tightly cohesive with our action. Four, some

[00:04:12] decision about the decision. In other words, if you’re looking at the measurement, you may make

[00:04:21] a decision about the decision, that is, some kind of judgment call about the decision,

[00:04:27] that is instructive for the final piece, which is some kind of adjustment before restarting that loop.

[00:04:36] So the adjustment acts as the prompt for the next action. If you’re missing any of those pieces,

[00:04:44] then your feedback loop is not complete, and shortening, you know, just some part of that

[00:04:49] does not actually check the box here for this principle. We’re going to take a quick

[00:04:53] sponsor break, and then we’re going to come back and talk about why. Why do we care about

[00:04:57] shortening the feedback loop? What kinds of effects does that have, et cetera, right after

[00:05:01] we talk about today’s speech? Speaking of feedback loops, what was the last time that you had a long

[00:05:13] feedback loop? Because you’re trying to answer a question about your code base, and you spent

[00:05:17] hours digging through Slack channels, PRs, JIRA tickets, and wikis trying to figure out what was

[00:05:23] going on. Or perhaps somebody on your team has recently faced this, and then they had to ping

[00:05:28] you, and you had to bounce out of the IDE, or you got interrupted in a meeting or something

[00:05:34] to answer this question. Maintaining a shared understanding of the code base, it does get harder.

[00:05:41] As an engineering team grows, and as the code base grows, getting answers to questions becomes

[00:05:46] more time-consuming when you’re onboarding new team members or working on refactoring existing

[00:05:51] projects. Our sponsor today, Unblocked, helps solve these problems. It provides helpful and

[00:05:57] accurate answers to questions about your code base in seconds. Answers are specific to your team

[00:06:02] and your application, because it complements source code with relevant discussions from GitHub,

[00:06:07] Slack, JIRA, Notion, Confluence, and more. Like an extended team member who never sleeps,

[00:06:13] Unblocked is aware of every decision, every discussion, for every part of your code base.

[00:06:18] With Unblocked, teams are shipping faster by spending less time digging for information

[00:06:23] and dealing with interruptions. Check it out at GetUnblocked.com.

[00:06:27] So our principle today is not just simply shorten your feedback loops. That is a good heuristic.

[00:06:45] Very likely, most people can probably benefit from shortening their feedback loops. But the

[00:06:52] economic principle here is the one that I want to talk about, and that is

[00:06:56] to understand why we care about shortening our feedback loops in the first place.

[00:07:02] And it’s an economics problem. And when we say economics, we’re not just talking about,

[00:07:07] necessarily, money economics. This could also apply to your time, to your effort,

[00:07:12] to your satisfaction. There are economics that apply to all of those things.

[00:07:18] So understanding why do we care about shortening the cycle time. There’s a couple of reasons

[00:07:24] why we care about shortening the cycle time. First of all, one kind of sub principle here is

[00:07:29] that shortening cycle time, or rather shortening the feedback loop time, we kind of consider these

[00:07:35] things very similar, cycle time and feedback loop time. Shortening your feedback loop time,

[00:07:41] generally speaking, will result in a cheaper loop. It is a less expensive loop, a less costly loop.

[00:07:52] And this makes intuitive sense if you think about, okay, our feedback loop is one day versus five

[00:07:58] days. Well, our total loop cost, if you want to call it that, our total loop cost is five times

[00:08:04] as much in terms of time, at least, for the five day loop versus a one day loop. Now there’s an

[00:08:09] important caveat here, and that is that shortening your feedback loop too short of a period of time

[00:08:17] will incur some kind of overhead, kind of a curve that looks like a J, where the cost

[00:08:27] actually goes back up compared to the value of the learning that you get from the retrospective

[00:08:34] portion of the feedback loop. So let me say that another way. There is a certain length of time,

[00:08:43] there’s a certain kind of length of loop, I guess, where the loop is a little bit too short.

[00:08:50] And so you need to lengthen the feedback loop to the point where it’s at the bottom of that

[00:08:55] J curve. And the bottom of the J curve here is essentially, it’s the cheapest possible

[00:09:02] feedback loop that you can have relative to the amount of learning that you can get out of the

[00:09:10] feedback loop. To get the kind of intuition for this, let’s imagine that your team commits

[00:09:18] in sprints. And let’s say we have two teams, team A, team B. Team A has two week sprints,

[00:09:25] and team B has two month sprints. At the end of every two weeks, team A is able to do some kind

[00:09:34] of retrospective and adjustment to whatever their plans are. And team B doesn’t do that until,

[00:09:40] you know, the two month mark. Going back to our original principle here, we can kind of see which

[00:09:46] one of these is more risky, just naturally. In team A’s circumstance, the risk of making a mistake

[00:09:55] in the direction that you’re going is mitigated by the fact that you’re likely to catch that

[00:10:00] mistake whenever that two week retrospective rolls around. You can change direction after

[00:10:06] two weeks. However, the risk of making a mistake for team B is that it’s very possible that you’ll

[00:10:14] continue down that mistake pathway and you will not catch that for the duration of two months.

[00:10:21] So this could be very expensive. Now, of course, there is a cost associated with

[00:10:27] the interruptions that the feedback loop reset has. It is kind of like the changeover process

[00:10:35] for sprints. If you’re used to using sprints, that kind of retrospective, the actual time that

[00:10:41] the retrospective takes. And this is why it’s important to recognize that there is indeed

[00:10:47] a threshold where you should have long enough that the time required to do that changeover

[00:10:54] is justified by the amount of learning that you get out of that retrospective.

[00:11:00] Now, to be clear, I’m using terms that are probably most familiar to folks who have

[00:11:04] practiced Scrum, but this feedback loop is not something that is software engineering specific.

[00:11:09] This is something that you can do with any kind of process, with anything where you have any level

[00:11:16] of uncertainty of the plan and the pathway. You can apply the same basic concepts, this idea that

[00:11:22] you have some kind of action, you have some kind of measurement to determine the effectiveness of

[00:11:26] that action. You decide how effective it was based on observing that measurement

[00:11:32] and making a decision about that. And then you decide what to do about it.

[00:11:36] Then you start that all over again. You make some adjustment and you start the feedback loop back

[00:11:40] over. Why is this such an important principle? Why does this matter so much that we have this

[00:11:48] optimization curve, this J-curve of optimization for feedback loops?

[00:11:54] There’s a lot of reasons why it’s important to optimize for this. The most important probably

[00:12:00] from a business standpoint is risk mitigation, especially in areas of uncertainty. Software

[00:12:07] engineering tends to have a lot of uncertainty and tends to have this kind of pivot need.

[00:12:14] On a regular basis, you probably want to be doing a retrospective to pivot and change your

[00:12:19] direction or change your decision, adjust your priorities, etc. And so having that in software

[00:12:25] engineering makes a lot of sense. But I want to call out one that’s not really intuitive.

[00:12:31] That is that one of the most important things that this enables is it reduces the friction

[00:12:38] to action. It reduces the friction to making a decision and taking action on something.

[00:12:45] Now, this should be balanced out by thinking about action bias or bias to action.

[00:12:53] Sometimes we talk about this in a positive light, but there is a downside to the bias to action,

[00:12:59] which is that sometimes we take an action because we don’t necessarily know what to do and

[00:13:04] we default to using the heuristic of, well, doing something is better than doing nothing.

[00:13:09] That’s not always true. But with a feedback loop, we can find that out. With a short feedback loop,

[00:13:16] we can find that out. And the cost of any given action being low enough that we learn from it

[00:13:23] and that we gain more value out of that learning than we did loss from the incorrect decision,

[00:13:29] this encourages action. Think about this. You want your engineering team to be more

[00:13:38] decisive. You want your managers to be more decisive. You want your engineers to pick up

[00:13:44] tickets and start working on them, make decisions about the product that they’re working on.

[00:13:50] You want them to deploy code more regularly. Make it so that the cost of mistakes is very low.

[00:13:58] The cost of mistakes being low encourages learning. And this is a direct correlation

[00:14:06] to how often you are reviewing to ensure that you are adjusting in response to your mistakes.

[00:14:11] This is when the learning occurs is in that feedback loop. So if you make your feedback

[00:14:16] loop shorter, you’re much more likely to learn. You’re much more likely to be able to make

[00:14:21] adjustments that matter. And here’s one more kind of final bonus benefit that we can’t leave this

[00:14:28] episode without talking about. Making your feedback loops shorter is going to increase

[00:14:33] the quality of the messaging within the loop. Okay. Think about this. We’ve talked about the

[00:14:40] communications theory stuff in recent episodes of the show and encourage you to go back and

[00:14:44] listen to that to get more of like a primer on what those communications theory, on what that

[00:14:50] actually means. But we talk about that feedback loop in the communications theory. If you think

[00:14:56] about a very long feedback loop, right? Imagine this being like, uh, shouting to somebody across

[00:15:02] the room, uh, in, in a noisy room, especially, right? Uh, and, and shouting across a very

[00:15:11] long distance or playing a game of telephone. These are, uh, very similar to very long feedback

[00:15:17] loops. And a short feedback loop has a nearly directly provided message. So we’re reducing

[00:15:26] the likelihood that some random effect that some other, uh, confounding variable has entered the

[00:15:34] picture. So when we do that measurement part of our feedback loop, the measurement has a much

[00:15:40] higher cohesion to reality. In other words, uh, it’s much more correlated to, um, some effect

[00:15:46] from our decision. And so if we’re making a decision and immediately looking at the feedback

[00:15:52] from that decision, making an adjustment and then repeating, right, we’re trying to figure out,

[00:15:58] okay, what parts of the decisions or the actions that I’m taking, how are they affecting the thing,

[00:16:05] the measurement that I care about? If I have a long feedback loop, then it’s very possible that

[00:16:11] more things are affecting that measurement. And so we learn less. It’s a, it’s a leaky, uh,

[00:16:18] feedback loop. And so it’s, it’s much harder to learn. It’s much harder to attach specific

[00:16:25] outcomes to specific actions because our feedback loop is too long. It’s easily corrupted. Um,

[00:16:31] there’s a lot of noise in the system. So this, this is an additional benefit. And also by the way,

[00:16:37] that’s part of why shorter feedback loops are cheaper. They are cheaper, not only just in

[00:16:42] direct spend, but they’re also cheaper because they’re simply more efficient. Uh, the, the system

[00:16:49] is more efficient. So you don’t have any additional waste, uh, on top of that feedback loop.

[00:16:55] Thank you so much for listening to another Principles of Working episode

[00:17:00] of Developer Tea. Once again, uh, the simple heuristic here for most of you, uh, is to shorten

[00:17:05] your feedback loops. That’s a simple heuristic. Uh, there is an optimal, um, length for your

[00:17:11] feedback loops and there’s multiple types of these. Uh, you don’t have to think about this

[00:17:16] just as your sprint, uh, cadence. You can also think about how tight can I get my feedback loops,

[00:17:22] uh, when I’m writing code. Can I get immediate feedback for my tests, for example, is a very

[00:17:27] common example to try to tighten the feedback loop on. Thank you so much for listening to this

[00:17:32] episode. If you enjoyed this episode, please consider joining the Developer Tea Discord

[00:17:37] community. Head over to developertea.com slash Discord. Thank you again to today’s sponsor,

[00:17:42] Unblocked. Get answers from pretty much every source that you use from Jira to GitHub to

[00:17:47] Confluence to, uh, Notion, all of the above. Go and check it out. Head over to getunblocked.com.

[00:17:54] That’s getunblocked.com. Thanks so much for listening and until next time, enjoy your tea.

Visão de gráfico