I want you to take a moment and imagine three or even four days ago. Try to replay a mundane event. Let's take transit. Imagine that you are headed to work or headed to school. Imagine each individual movement and each turn that you have to take to arrive wherever it is that you are trying to go. If you are like pretty much every other human, these things seem to happen automatically. In fact, many of us have had that experience where we realize once we arrive at the place that we are going that we didn't really even think about where we were going and sometimes we even go to the wrong place, even though we knew where we were supposed to go. This kind of automatic behavior can be really bizarre, but it's also incredible. It's amazing that we can tune out this kind of surrounding information and focus on other things, sometimes entirely daydreaming while we are operating our normal every day. In the last episode, we talked about feedback loops. As it turns out, feedback loops are responsible for this kind of behavior. My name is Jonathan Cutrell and you are listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in your careers. The feedback loop discussion that we had on the last episode is really important context for this episode. We explained the concept of a feedback loop. In short, a feedback loop starts with some kind of measurement, whether that's an implicit or explicit measurement, whether it's quantitative or maybe you're just feeling something, you take some kind of input, a measurement of some kind of stimulus. Then you evaluate that measurement and that evaluation converts that raw information into meaningful information that you can then act on. Your actions in a perfect feedback loop would have a direct impact on the next measurement and therefore the next evaluation and you guessed it on the next action. feedback loops are in many ways the kind of base unit necessary for learning. The experimental process is based on this concept, the idea that you can try something, which would be the measurement, evaluate that measurement against a hypothesis, something that you, a guest would happen, change a variable, and then start it all over again. An understanding feedback loops and building better feedback loops, this is fundamental to becoming a better engineer, a better manager, a better product owner, a better worker in general because once again it is the fundamental unit necessary for learning. We're talking about better ways of building these feedback loops, kind of principles or guidelines for building good feedback loops in the last episode. We talked about validating your inputs in your feedback or in your rules and then the loop cycle timeline. In other words, the amount of time that you spend for measurement to the next measurement. This is important to our example at the top of the show. We talked about these automatic rules that we have. We're going to discuss today a concept for examining those rules. If you've ever found yourself sitting in front of your workplace instead of the grocery store because you followed some automatic rules, what we often call muscle memory or sometimes you call it having our brains on autopilot, if you had those automatic default actions that you took, then you have experienced a feedback loop that had the wrong rules. We're going to talk about how to fix that kind of problem and then we're going to talk about places where perhaps we are missing our feedback loops all together. But first I want to talk about today's sponsor, Lynneau. With Lynneau, you can deploy a server in the Lynneau cloud in just a few minutes. The critical point here is that Lynneau is offering $20 worth of credit for new customers. We'll tell you how to get that in just a moment. You can build pretty much anything on Lynneau. They have a brand new cloud manager, by the way, because Lynneau is built by developers. I don't know if you all know this about Lynneau, but it's a bunch of Developer That run a company for developers. They have developers internally that are building code. In fact, you can find Lynneau's code at github.com slash Lynneau. The manager is at github.com slash Lynneau slash manager. In fact, if you want to go and work at Lynneau, they have jobs open at Lynneau.com slash careers. The reason that this is relevant in an ad read for this company is that when you have a company of developers who are providing your service, they understand your needs. For example, if you wanted to automate your deployment and you want to do it with your specific way of doing things, you can do that. Lynneau offers an API and a CLI to do those things. You can provision, secure, monitor, and back up your cloud. But it's not just developer friendly. It's also leading in the industry. You can pick from any of the 10 worldwide data centers. Next year, that was eight, the newest data centers from this year are in Toronto and Mumbai. Coming soon to Lynneau, by the way, Object Storage, Lynneau Kubernetes Engine, and GPU processors. So for those of you who are getting into machine learning, you should check out Lynneau. Head over to Lynneau.com. This is how you get that $20. Lynneau.com slash Developer Tea. You can use the code Developer Tea. 2019 at checkout. Thanks again to Lynneau for sponsoring today's episode of Developer Tea. So we've revisited this model of what a feedback loop looks like. You have some kind of stimulus, which you measure either implicitly or explicitly. You evaluate your measurement. You make meaning out of it. And then you take an action in response to whatever your evaluation was with hopes of impacting the next measurement. And then everything starts over again. But there's an interesting thing that can happen when you leave the feedback loop the same way. When you have it, stay static like this. And that evaluation to action step, even though you have some kind of valid information, some valid measurement, some valid stimulus, something that is clean, right? So you can put clean whenever it arrives at your evaluation process. The problem that you can face is that you have rigid or incorrect rules or models that guide your evaluation to action. So how do we fix this? Well, it seems pretty obvious when we frame it this way. But this is an entire area of research in organizational thinking. Organizations tend to have these kinds of feedback loops. They have some kind of stimulus, they measure it, and then they have these set up policies, ways of reacting to particular measurements. And sometimes those policies are wrong, or at least they're wrong in terms of producing the results that they want. And this is typically the case if your policies are too rigid or maybe they're out of date. They haven't changed along with changing circumstances. So the fix for this, and you can Google this, it's not something I came up with here on this podcast, it's called double loop thinking. So essentially what this means is as you are taking in feedback, you're considering whether or not your models, the fundamental principles that you're making your evaluations and decisions based on are correct. So the information that you're gathering may not change at all. But the way that you evaluate and then react to that information may change entirely. And of course as a result of that, when your reactions change, the feedback loop changes entirely in your measurements, probably going to reflect something different. So give you a very simple example of this. It's imagine that you are a manager and you are evaluating whether the work that your team is doing is on time according to some milestone planning that you have done together. And when the team is behind, you have a simple rule to apply more pressure. And so the team will respond to that pressure by working more hours and theoretically being more productive. And initially the measurements that you take, they seem to reflect that this is a good strategy. And you actually are producing more work. And so the first week rolls around, the second week rolls around. And unfortunately around the third week, you have continued to apply more pressure under the assumption that the more pressure that you apply the more work that gets done and therefore the closer you get to being on time. But unfortunately in that third or fourth week turns out that your measurements reflect that the team is not producing very good work. In fact, the team seems to be producing less work than before. Then before you started applying any pressure at all. And so following the same rules that you have set up because you're following behind once again, you continue to apply more and more pressure. Now, obviously this is an exaggerated example. Hopefully if you're listening to this show, you can see the obvious problems with applying more and more pressure with this linear assumption about the way that humans respond to pressure. And if you were to have this kind of rule, you can imagine that it's the feedback mechanism is actually damaging, it's self-damaging because the more pressure you apply, the worse things seem to get. And though they initially turned out better. If instead as you were trying out this new approach of applying a little bit of pressure, you could step back and evaluate from more of a principled approach whether that adjustment makes sense or how the model works, the different pieces of the puzzle. If you were to look at the model itself, if you were to look at the rules, and evaluate if they seem like they're going to work out, you may find that there are errors in those models or there are errors in your thinking, not just small ones, not just incidental ones, but major ones, like in this example. And this is the second loop that we've been discussing, the second loop that we mentioned, the double loop thinking, that first loop being your normal feedback loop, but that second loop, including some of the evaluation of your rules. That is the third guideline for building better feedback loops to engage in double loop thinking. Now this doesn't mean that you're constantly questioning whether or not your approach is valid, although there is a good argument for questioning often whether your approach is valid, but it does mean that you should do this on a regular basis, you should evaluate your models. Let's go through one final guideline at the end of this episode here, and that is quite simply establishing new loops where they are clearly missing. And additionally, this is kind of a bonus guideline, eliminate or interrupt loops that aren't helpful. The reality is in places where we often want to improve, we don't have sufficient feedback loops established. We either aren't measuring something or maybe we're measuring it very poorly, we have some kind of abstract measurement for it, some kind of implicit measurement that needs to be converted to an explicit measurement, or maybe we aren't doing any kind of formalized feedback loop at all. And so in these areas, it's important to identify this particularly from a level of where you want to improve. Going back to our previous episode, the last episode of Developer Tea, identifying places that you want to improve is the first step to understanding where you need to look at your feedback loops, but it's also important to recognize that feedback loops are, they don't live in a vacuum, and they often overlap with other feedback loops. So if you have some set up, for example, maybe you are copied on every email that comes into the support queue, and you're using this as some kind of feedback mechanism, whether you're doing that on purpose or not, this can add noise, and it can decrease the effectiveness of your other feedback loops. So it's important to not only add feedback loops in places where you want to improve, but also recognize that having too many can make the environment a little bit too noisy. We'll talk about signal to noise ratio in another episode of Developer Tea, in maybe the next episode actually, because this extra volume, the extra signals that you have can impede on your ability to clearly hear the signals that you care about. Thank you so much for listening to today's episode of Developer Tea. Hopefully you can easily see that feedback loops are incredibly important to your growth as an engineer, to your growth as a human being. Today's episode wouldn't be possible without our sponsor, Linode. However, to Linode.com slash Developer Tea, and use the code Developer Tea2019 at checkout, remember that ends at the end of this year. So you have about 15 days or so by the time this episode comes out, to go and take advantage of that $20 worth of credit that Linode is providing. Today's episode, like every other episode, is a part of the spec network, head over to spec.fm to find other shows that are designed for engineers and designers who are looking to level up in their careers. Head over to spec.fm to find those shows. If you enjoyed today's episode, I'm going to ask you to do one thing. Think of one person who in 2020, they will appreciate this show. Imagine who that person is, and then share this episode with them. This is the best way to help the show continue to exist by helping other people find the show. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell, and until next time, enjoy your tea.