In a famous speech in 1943, Winston Churchill said, We shape our buildings. And afterwards, our buildings shape us. Churchill was making his argument for why he wanted to see a building that was destroyed in the war rebuilt. In today's episode, we're going to talk about how we shape our lives, the buildings around us, not just the physical ones. My name is Jonathan Cutrell, you're listening to Vellabartee. We shape the buildings around us. And we shape the structures, the systems. We shape the processes. We shape the other people, our teams, the companies we work with, our friends, our family, our communities. We continuously shape, and we are continuously shaped by what we have influenced. Think about it like this. For the most part, the decisions that you have agency over, maybe what you buy at the grocery store, while we choose to study in school or what part of town we choose to live in. We don't always have agency over these decisions, but when we do, we make choices. And those choices end up having downstream effects back on us. This is an interesting feedback loop. We've made some kind of input. We've chosen to buy ice cream or fruit. And then weeks later, our environment, our previous choices which have built that environment, have a shaping effect back on us. This is kind of an echo of our original decisions. This is true on our teams, often in more subtle and difficult trace down ways, especially because, unlike buying food for our pantry, the direct impact of our feedback to the people around us, not just traditional feedback, but all of the untraditional feedback that we provide as well. Our facial expressions, our tone, the frequency of our slack messages to each other, all of these kinds of feedback affect our teams. It affects the people that we work with every day in ways that may not necessarily be predictable. Something that you say may have an effect on your team, a lasting effect, one that shapes the process that your team follows for the next year. In fact, there are things that you will say to people on your teams that could outlive your tenure at the company. This is one of the reasons why we have things like processes that we're following because we've always followed them. At some point, those processes were built as a result of a series of feedback. We need to be aware of this for a lot of reasons. One of the main reasons that we need to be aware of this is because response to feedback is often as strong or perhaps even stronger than an individual's own convictions. A simple practical example of this is a software engineer who has a high standard for the work that they deliver. Let's say they're working on a project and the project is late, whether by their fault or by the fault of some kind of planning mechanism, maybe the deadline is actually too ambitious, but for whatever reason, everyone agrees that the project is running behind some deadline. Now, the manager may come in and say, I would like for you to deliver this faster. The software engineer now has a choice to make. Either they take shortcuts on the work that they know is going to take longer if they don't take shortcuts, if they adhere to their own conviction, if they adhere to their own values of generating good quality work, they can reduce that quality to make their manager happy. The risk of reducing the quality is delayed. The risk of retaining the quality is immediate. And so even though that person has strong convictions and capacity to create good quality engineering, they have a situation. They have a specific set of feedback that's being provided to them that encourages them to go against their abilities, to go against their convictions in order to avoid immediate risk. Similarly, we also provide encouraging feedback that produces a reinforcement loop for bad behaviors that we don't necessarily want to reinforce. The simplest example of this is the engineer who takes on the late night bug, the late night outage, the overworking their normal hours. Now, it's our intuition to celebrate that engineer, to thank them for extending themselves for going above and beyond, we may even be tempted to mention this in something like a performance review as evidence of why this person is doing so well. The problem is this behavior is in response to something that we don't want. We don't want this situation to happen again. We don't want an outage to happen in the middle of the night. We don't want engineers feeling like the only way they can succeed or the only way to excel is to spend more time than you normally would commit for the company. So instead of congratulating or celebrating that this individual has gone above and beyond, that they've spent their own personal time, these are all behaviors that while we may have gratitude for their willingness to do something in an extenuating circumstance, we don't want to celebrate this to create a system of celebration for these kinds of acts. Instead, a good engineering manager would apologize. I'm sorry that this happened. I appreciate you dealing with this bad situation. What we're doing here is we're creating a feedback loop of this being a negative thing that we don't want to repeat in the future. How do we fix this so that we don't have to do this anymore? In tandem, take your celebration and your congratulations to the folks who are fixing problems upstream, the people who are preventing outages that would otherwise happen after hours. The way that we think about this systems around us, the teams, the people, the tools that we use even, we should be thinking about them in terms of feedback and response. This is the feedback loop. We have some kind of input and the system responds with some kind of output. And then we repeat that over and over. And those systems, those teams, they respond and they change sometimes in small ways and in progressive ways and sometimes in big ways. Sometimes the way that our feedback affects a system is completely unexpected. But ultimately, if we are aware of this, we can get in front of it. We can use our feedback to shape things how we would prefer to shape them rather than accidentally having to clean up when we've shaped them incorrectly. Thanks so much for listening to today's episode of Developer Tea. If you enjoyed this episode, this discussion, I'd encourage you to come and provide your feedback to our community. Head over to developertea.com slash discord. This is a discord community. It's totally free. There's no catches. We're not trying to sell you anything in there. Instead, we just want you to come in and commit to connecting with other engineers who are looking to grow in their careers and in their lives. Thanks again for listening to this episode. If you enjoyed this episode, make sure you subscribe and whatever podcasting app you're currently using. Until next time, enjoy your tea.