We're going to talk about a working principle in today's episode of Developer Tea. And this principle is one that is core to every agile discussion, every lean discussion. And it's core to another industry, and that's the learning industry, or specifically learning theory. And this principle is based on things that come from behavioral science and study of psychology. The principle is based on the idea of feedback loops. Here's the principle. It's very simple. 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. I'm going to say that again because it's kind of a long one. Make your feedback loops short enough that any singular action is cheap enough that when you're wrong, the value of learning that you get from being wrong is cheaper than the cost of being wrong in the first place. Said another way, shorten your feedback loops so that mistakes provide learning that outweighs the cost of making those mistakes. There's a very interesting underlying structure here that I want to expose, but I want to focus on the first one. I want to focus first on the idea of shortening your feedback loops. What does this mean exactly? It can mean a lot of different things depending on the context. Very importantly, the requirement to shorten a feedback loop in this principle is two things. One, it allows you to, on a regular basis, review in some kind of retrospective way. You're looking back at whatever decision, whatever action you've taken, and looking at, measuring some. You're looking at what kind of result. You're trying to understand what was the impact of the action that I took. Shortening the feedback loop has all kinds of good effects that we're going to talk about after our sponsor message today. But the important thing to qualify the shortening of the feedback loop, you need to be able to change direction. It's not enough just to continuously retrospect on what you've been doing. You need the agency to be able to make adjustments. Otherwise, all of a sudden, you're going to have to make adjustments. You're going to have to make adjustments. You're going to have to make adjustments. You're going to have to make adjustments. All of this ends up being kind of a lost cause. If all you're doing is you're retrospectively looking at what you have done in the past two weeks, but you don't have any agency to adjust your heading, you can't change anything about what you're learning, then it's not really fitting the mold of shortening the feedback loop. The feedback loop includes, very importantly, includes, is adjustment. All right? The parts of the feedback loop, just very briefly, the parts that you need to have for the feedback loop to be complete. First is an action, some kind of action, whatever it is, a decision, you know, maybe some kind of code deployment that you do, whatever it is. Second is a measurement of that action. So some kind of, hopefully, some kind of measurement of that action. Some kind of objective measurement in the best case. Three, review of that measurement. And here we're looking to see if we believe that the measurement is indeed tightly cohesive with our action. Four, some decision about the decision. In other words, if you're looking at the measurement, you may make a decision about the decision. Right? That is some kind of judgment call about the decision that is instructive for the final piece, which is some kind of adjustment before restarting that loop. So the adjustment acts as the prompt for the next action. If you're missing any of those pieces, then your feedback loop is not complete. And shortening, you know, just some part of that does not actually check the box here for this principle. We're going to take a quick spot. We're going to take a quick break. And then we're going to come back and talk about why. Why do we care about shortening the feedback loop? What kinds of effects does that have, et cetera, right after we talk about today's speech. Speaking of feedback loops, what was the last time that you had a long feedback loop? Because you're trying to answer a question about your code base, and you spent hours digging through Slack channels, PRs, Jira tickets, and wikis, trying to figure out what was going on. Or perhaps somebody on your team has recently faced this, and then they had to ping you, and you had to bounce out of the IDE, or you got interrupted in a meeting or something to answer this question. Maintaining a shared understanding of the code base, it does get harder. As an engineering team grows and as the code base grows, getting answers to questions becomes more time-consuming when you're onboarding new team members or working on refactoring existing projects. Our sponsor today, Unblocked, helps solve these problems. It provides helpful and accurate answers to questions about your code base in seconds. Answers are specific to your team and your application because it complements source code with relevant discussions from GitHub, Slack, Jira, Notion, Confluence, and more. Like an extended team member who never sleeps, Unblocked is aware of every decision, every discussion, for every part of your code base. And with Unblocked, teams are shipping faster by spending less time digging for information and dealing with it. Check it out at getunblocked.com. So our principle today is not just simply shorten your feedback loops. That is a good heuristic. Very likely, most people can probably benefit from shortening their feedback loops. But the economic principle is that you should be able to shorten your feedback loops. And that's what Unblocked does. The economic principle here is the one that I want to talk about. And that is to understand why we care about shortening our feedback loops in the first place. And it's an economics problem. And when we say economics, we're not just talking about necessarily money economics. This could also apply to your time, to your effort, to your satisfaction. There are economics that apply to all of those things. So understanding why do we care about shortening the cycle time. There's a couple of reasons. There are a number of reasons why we care about shortening the cycle time. First of all, one kind of sub-principle here is that shortening cycle time, or rather shortening the feedback loop time, we kind of consider these things very similar, cycle time and feedback loop time. Shortening your feedback loop time, generally speaking, will result in a cheaper loop. It is a less expensive loop, a less costly loop. And this makes intuitive sense. If you think about, okay, our feedback loop is one day versus five days. Well, our total loop cost, if you want to call it that, our total loop cost is five times as much, in terms of time at least, for the five-day loop versus the one-day loop. Now, there's an important caveat here, and that is that shortening your feedback loop to too short of a period of time will incur some kind of overhead, you know, kind of a curve. That looks like a J, where the cost actually goes back up compared to the value of the learning that you get from the retrospective portion of the feedback loop. So, let me say that another way. There is a certain length of time, there's a certain kind of length of loop, I guess, where the loop is a little bit too short. And so, you need to lengthen the feedback loop to the point where you can get the feedback loop to the point where you can get the feedback loop. So, you need to lengthen the feedback loop to the point where it's at the bottom of that J curve. And the bottom of the J curve here is essentially, it's the cheapest possible feedback loop that you can have relative to the amount of learning that you can get out of the feedback loop. To get the kind of intuition for this, let's imagine that your team commits in sprints. And let's say we have two teams, team A, team B. Team A has two-week sprints, and team B has two-month sprints. At the end of every two weeks, team A is able to do some kind of retrospective and adjustment to whatever their plans are, and team B doesn't do that until the two-month mark. Going back to our original principle here, we can kind of see which one of these is more risky, just naturally. In team A's circumstance, the risk is that team B has two-month sprints, and the risk of making a mistake in the direction that you're going is mitigated by the fact that you're likely to catch that mistake whenever that two-week retrospective rolls around. You can change direction after two weeks. However, the risk of making a mistake for team B is that it's very possible that you'll continue down that mistake pathway and you will not catch that for the duration of two months. So this could be very expensive, and of course, there is a cost associated with the interruptions that the feedback loop reset has. It is kind of like the changeover process for sprints. If you're used to using sprints, that kind of retrospective, the actual time that the retrospective takes, and this is why it's important to recognize that there is indeed a threshold where you should have long enough that the time required to do that, to do that changeover, is justified by the amount of learning that you get out of that retrospective. Now, to be clear, I'm using terms that are probably most familiar to folks who have practiced Scrum, but this feedback loop is not something that is software engineering specific. This is something that you can do with any kind of process, with anything where you have any level of uncertainty of the plan and the pathway. You can apply the same basic concepts. This idea that you have, you have some kind of action, you have some kind of measurement to determine the effectiveness of that action. You decide how effective it was based on observing that measurement and making a decision about that, and then you decide what to do about it. Then you start that all over again. You make some adjustment and you start the feedback loop back over. Why is this such an important principle? Why does this matter so much that we have this optimization curve, this J curve of optimization? At theijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij etc. And so having that in software engineering makes a lot of sense. But I want to call out a one that's not really intuitive. And that is that one of the most important things that this enables is it reduces the friction to action. It reduces the friction to making a decision and taking action on something. Now this, it should be balanced out by thinking about action bias or bias to action. Sometimes we talk about this in a positive light, but there is a downside to the bias to action, which is that sometimes we take an action because we don't necessarily know what to do. And we default to using the heuristic of, well, doing something is better than doing nothing. That's not always true. But with a feedback loop, we can find that out. With a short feedback loop, we can find that out. And the cost of any given action being low enough that we can do that, that's a good thing. And so I want to talk about that. Learn from it and that we gain more value out of that learning than we did loss from the incorrect decision. This encourages action. Think about this. You want your engineering team to be more decisive. You want your managers to be more decisive. You want your engineers to pick up tickets and start working on them, make decisions about the product that they're working on. You want them to deploy code more regularly. You want them to deploy code more regularly. Make it so that the cost of mistakes is very low. The cost of mistakes being low encourages learning. And this is a direct correlation to how often you are reviewing to ensure that you are adjusting in response to your mistakes. This is when the learning occurs is in that feedback loop. So if you make your feedback loop shorter, you're much more likely to learn. You're much more likely to be able to make it. And so I want to talk about that. And I want to talk about that in a little bit. adjustments that matter. And here's one more kind of final bonus benefit that we can't leave this episode without talking about. Making your feedback loops shorter is going to increase the quality of the messaging within the loop. Okay. Think about this. We've talked about the communications theory stuff in recent episodes of the show. I encourage you to go back and listen to that to get more of like a primer on what those communications theory, on what that actually means. But I want to talk about that. And I want to talk about that. And I want to talk about that. If we talk about that feedback loop in the communications theory, if you think about a very long feedback loop, right? Imagine this being like shouting to somebody across the room, in a noisy room, especially, right? And shouting across a very long distance or playing a game of telephone. These are very similar to very long feedback loops. And a short feedback loop has a nearly directly, provided message. So we're reducing the likelihood that some random effect, that some other confounding variable has entered the picture. So when we do that measurement part of our feedback loop, the measurement has a much higher cohesion to reality. In other words, it's much more correlated to some effect from our decision. And so if we're making a decision and immediately looking at the feedback loop, we're reducing the likelihood that some random effect has entered the picture. from that decision. Making an adjustment and then repeating, right? We're trying to figure out, okay, what parts of the decisions or the actions that I'm taking, how are they affecting the thing, the measurement that I care about? If I have a long feedback loop, then it's very possible that more things are affecting that measurement. And so we learn less. It's a leaky feedback loop. And so it's much harder to measure. And so we learn less. And so we learn less. And so we learn less. It's much harder to learn. It's much harder to attach specific outcomes to specific actions because our feedback loop is too long. It's easily corrupted. There's a lot of noise in the system. So this is an additional benefit. And also, by the way, that's part of why shorter feedback loops are cheaper. They are cheaper not only just in direct spend, but they're also cheaper because they're simply more efficient. The system is more efficient. So you don't have any additional feedback loops. So you don't have to do that. You don't have to do that. You don't have to do that. You don't have to do that. You don't have to do that. You don't have to do that. You don't have to do that. You don't have to do that. You don't have to do that. You don't have to do that. You don't have to do that. You don't have to do that. You don't have to do that. You don't have to do that. You don't have to do that. on top of that feedback loop. Thank you so much for listening to another Principles of Working episode of Developer Tea. Once again, the simple heuristic here for most of you is to shorten your feedback loops. That's the simple heuristic. There is an optimal length for your feedback loops, and there's multiple types of these. You don't have to think about this just as your sprint cadence. You can also think about how tight can I get my feedback loops when I'm writing code? Can I get immediate feedback for my tests, for example, is a very common example to try to tighten the feedback loop on. Thank you so much for listening to this episode. If you enjoyed this episode, please consider joining the Developer Tea Discord community. Head over to developertea.com slash discord. Thank you again to today's sponsor, Unblocked. Get answers from pretty much every source that you use, from Jira to GitHub to Confluence to... to Notion, all of the above. Go and check it out. Head over to getunblocked.com. That's getunblocked.com. Thanks so much for listening, and until next time, enjoy your tea.