What kind of decisions are you optimizing for? This is a question that you should ask yourself both about your own decisions and the decisions that you are expecting from others. In today's episode, we're going to focus on this from both the individual contributor level but also the managerial level. Incentives shape our decisions and we need to be thinking about the way that we are incentivizing or providing negative incentives and how those things are shaping the decisions around us, including our own. My name is Jonathan Cutrell and you're listening to Developer Tea and the show exists to help driven developers like you find clarity, perspective and purpose in your career. And this is a hard question to answer. What kind of decisions am I optimizing for? Because most people don't really ask this kind of question very often. Most people follow the incentives and it's not just basic incentives like money but also unspoken and sometimes accidental incentives like social status or even a simple appreciation from a co-worker. In these kinds of pieces of feedback, they drive us. They drive us to do things that perhaps maybe we wouldn't have done otherwise. Of course we all work for various reasons. Most of us are working to live, to have enough money to fund our lives. A lot of us also work because it's much more enjoyable to work than it is to not work. So the decision to work comes with a lot of clear and obvious factors but what we do when we're working is less obvious. How we choose to spend our time. That's a harder thing to understand. And how we choose to spend our time is often reflective of our prioritization process. And we can have an explicit prioritization process that's supported by whatever our company structure is, whatever our working structure is, or we can have an implicit prioritization structure or maybe even a mix somewhere in between these two. And this is actually often the case. We have one explicit prioritization structure and then we have a different prioritization structure, an implicit one that we derive based on those feedback loops that I was talking about earlier. And so if our feedback loops don't reinforce our explicit prioritization structures, then we make decisions that may be in conflict with those priorities. So we're going to talk about this from the individual contributor perspective first and then we'll talk about today's sponsor and come back and discuss this from the managerial position. So if you are a developer and you're in a role, we're contributing to a project or a series of projects and you don't have anybody that you are managing. You're not directly shaping or judging their decisions. And your influence is less based on your power position and it's more based on your persuasion position. So I want to talk more about the decisions that you make and the position is the same. You are still persuading yourself. That persuasion causes you to choose one way or another. For example, if you have some feedback that comes to you and it's outside of some established structure or maybe you don't have a structure and that feedback comes from somebody who is in some level of authority over you. Now this person is not your direct manager for example, maybe they are in a different position of authority and now you have a problem. This person has brought to you some kind of information, it's outside of the normal way of handling that kind of feedback and it's in conflict with some other priority that you have. Now I want you to think back about moments where you felt that kind of pressure. Maybe that feedback wasn't a person that came to you. Maybe that feedback was you saw somebody else do something that they got some kind of praise for. Somebody in the company said that that person was doing a great job whenever they did that thing. An example of this may be someone staying up really late to finish up a feature. In this behavior of staying up really late to finish up a feature is not really necessarily in your values, it's not really stated as a value of the company. In fact the company probably has a value like balance, taking care of yourself, not spending an exorbitant amount of energy when you could have just done that same work the following day, probably done that work with better accuracy. And so you're at a conflict point because someone in the company recognized the extra effort and attributed a positive kind of social factor to that effort. So even though you have an established value and you believe it's best for yourself to not participate in that kind of behavior, you also have a piece of feedback that says I will be rewarded either socially or maybe even down the road financially if I overextend myself enough. And so your response is conflicted. You either choose to overextend yourself to receive some kind of positive reinforcement or you choose not to overextend yourself because your convictions are stronger. Another example with negative reinforcement rather than positive reinforcement this time. You have an idea that you want to present to the team. Let's say this is kind of an architectural change. It's not something that you can do without buying. Something that everybody would have to agree with. And you bring it to the team and half of the team likes it and the other half of the team doesn't like it. And your manager is in the half that doesn't like it. And they respond to you by saying that this idea is not a valuable use of our time. Now even though the manager may be right, sometimes it's hard to hear. Sometimes it's difficult to hear that a judgment has been passed on one of your own ideas. And so the next time you have an idea, perhaps you have a conflict. You're reticent. You don't want to bring an idea to the table that is turned down and then another idea that's turned down because eventually you look like somebody who has bad ideas. And so the social pressure and the difficulty of that feedback may drive you to withdraw your input to lay low. And this can be detrimental for a team. But regardless of the reason for your decisions, we need to understand how you can optimize your mindset so that you're not making these kinds of decisions. One of the most important factors that you can consider when you're making decisions like this is the impact and the time frame for that impact. Sometimes we want to make decisions that have a very short term impact. Like for example, in our first example, we talked about overextending ourselves for one night to gain approval of our peers. Sometimes we want to implement something that has a longer term impact. For example, we don't want to be seen as the person who has bad ideas. And so perhaps we withdraw so that we can protect our reputation in the long term. Often the conflict that we have with others is also about this time scale. For example, if you brought an idea to your team, it may be that the idea is good, but it's good for the three year mark and the team is optimizing for the shorter term mark, like a six month mark, or maybe they're optimizing for a much longer term mark, like 10 years. And most decisions happen to have this kind of restriction, where the quality of the decision is not just about the fact of the decision, but also about the timeline, or perhaps another axis. When you combine a series of these axes together, you get context. Sometimes you're making a decision given one frame or one set of axes, one context. And that decision could have been made given another context. When you're faced with this kind of conflict, this pulling between one incentive and another, for example, values versus social appreciation, you should consider what time frame you're talking about. Perhaps for example, you can gain some social credit for spending a little bit of extra time on a project, but you'll also, if you extend that time frame, you probably can't sustain that. And even if you could, you probably don't want to. And so it's important to understand these decisions, both in terms of their long term impact on other factors, but also in terms of their long term impact on your decision-making process. For example, if you get that social praise from overextending yourself one night, then you will learn that. And even cognitively, perhaps subconsciously, you'll attach that praise that you got, that positive reinforcement with a behavior that you don't necessarily want to practice. So it's important to understand these behaviors and where you draw your own lines in order to make better decisions in the long run. We're going to talk about today's sponsor. Then we're going to talk about how managers can be more aware of what they are encouraging, what they're optimizing for, and provide a better long term focus for sustainable success, rather than a short term focus that comes with volatile success. We'll talk about that right after we talk about today's sponsor, Linode. Speaking of long term, Linode has been with Developer Tea for quite a while. In fact, I just now saw a booth, a Linode booth at the Lee Developer Conference in New York this past week. And I just want to say that Linode is such a big proponent of the developer community. And part of the reason for that is Linode is made up of developers. In fact, the person that was sitting at the booth was himself a developer. And this company cares about the developer experience. They also care about open source. In fact, many of their tools can be found on their GitHub if you go to GitHub.com slash Linode. You can actually contribute and fork some of Linode's dashboards, for example. They have nine data centers around the world. They actually have two more that are going up, one in Canada and one in India this year. They feature native SSD storage in a 40 gigabit internal network. So your server to server communication is super fast. Go and check it out. Head over to Linode.com slash Developer Tea. You can use the code Developer Tea2019 at checkout for $20 worth of credit. All new customers are going to get $20 worth of credit just head over to Linode.com slash Developer Tea and use the promo code Developer Tea 2019. Go ahead and check out. Thanks again to Linode for sponsoring Developer Tea. So what kind of decisions are you optimizing for as a manager? Is a developer manager? This is true for pretty much all managers. So this isn't related necessarily to an engineering manager position directly. This is also true for people who are in kind of executive positions. We need to understand that the things that we incentivize, the things that we celebrate are the things that will ultimately end up being optimized for. So if you want to optimize such that your code is dependable, it's well tested. It is safe. The developers who are working on it, they rarely push anything that brings down the server. And you need to understand what factors contribute to that. Now we're not going to try to go into every factor that contributes to reliable software. But perhaps a handful we can talk about testing would be one of them. Having multiple developers understand that code base so that if one developer is sick or on vacation, another one can step in. Having the code in a state where developers feel confident in the changes that they are making, having some kind of verification process that developers walk through. For example, having one or another developer, two developers review the code and review the functionality of that code. Perhaps having systems of redundancy that step in whenever something does indeed fail. These are always that you can increase your confidence. And there certainly are more. But if you want to optimize for these ways of increasing confidence, then you may think about these factors and their kind of opposite factors. For example, having code that isn't reviewed or isn't tested going into master or going up to production. Having only one developer in a silo, this could cause problems. Having changes that need to be made so fast that unfortunately the developers don't feel confident in that change because they haven't had the time to test that change. And so we end up in the scenario where we have both factors that we understand that could contribute to the reliability of a code base and factors that could detract and those happen to be usually opposite factors. And if you walk through a kind of a logical practice of discerning what would contribute to those factors. So for example, what would contribute to a developer pushing changes too quickly? Perhaps that developer feels rushed. Maybe they feel like they need to push changes in order to meet a particular deadline. Or maybe they feel that their personal velocity is too slow. And so in order to keep their good standing in their job, they need to move quicker, they need to ship faster and therefore they end up shipping less reliable code. And so by optimizing the speed of a developer, the development process, you end up potentially compromising the reliability of that same software. Hopefully, that's not groundbreaking information, but there are less intuitive second order factors that you may not consider. For example, hiring an expert. If you hire an expert, you may get a lot of benefit out of that expert's knowledge. But if you allow that expert to work alone, it's very possible that they will end up creating a silo. Because of their expertise, it's possible that if you allow them to kind of do their thing, right? Then they end up doing things, creating things that may be really difficult for other Developer To understand. And that creates a bottleneck. That creates a situation where a developer is siloed. And so if that developer chooses to leave, then no one has context. No one knows how to manage what they left behind. This can make software unreliable. It can make other developers feel afraid to touch the code. Now often we wouldn't think that hiring an expert could have a negative impact on our team. And that's because decisions are complex. Systems affect everything in the system. There's very few decisions that won't affect something else, both adversely and positively. This is true for even the smallest of actions. Even the smallest thing like an emoji, this seems crazy, but the emojis that you send to people's Slack messages or if you send gifs back in text message threads, these are reinforcement mechanisms. These are ways of expressing yourself. And the other person will receive these expressions as feedback on their actions. You can either positively reinforce actions that have positive effects on your team or you can positively reinforce actions that have negative effects on your team. And then you can also use the other side, negative reinforcement on things that may have negative impacts on your team. And as it turns out, even though it's not intuitive, we often provide negative reinforcement for behaviors that could have positive impacts on our team. This is the example that we talked about earlier where we encourage someone to withdraw, to not bring their ideas to the table by shooting them down too harshly. So it's important to kind of create some heuristics for yourself. For example, it's very likely that a good heuristic is to avoid negative feedback unless something is relatively critical. Negative feedback is a very strong mechanism that we can use in the workplace. The reason for that is because given enough negative feedback, a person may fear that their job is in danger. This is especially true for managers. And so negative feedback ends up speaking much louder than positive feedback. Negative feedback may give me the hope of some kind of better position, maybe a raise. But the downside of getting fired is much larger than the upside of getting a raise. And so if we want to ensure that people are responding more to the positive feedback or more in a balanced way, we should be much more careful with our negative feedback. This is one of many heuristics that you can derive for yourself based on how you want to optimize for decisions on your team and for yourself. Thank you so much for listening to today's episode of Developer Tea. And a huge thank you once again to Linode for sponsoring today's and many other episodes of Developer Tea in the past. I have a huge favor to ask of you. It's very simple. If you enjoyed today's episode, if you found it valuable, I would love for you to share it with other people. You can do this in two simple ways. One is to literally send them this episode, a link to this episode. You can send it most podcast apps. You can also send it directly from the spec.fm website. Or either or I guess you can do both. The other great way to help to show reach more people is to leave a review in the iTunes. There's a link in the show notes to do this. This is such an excellent way because perhaps thousands of developers will read that review and make a decision on whether or not to download this show and that can help their careers. So I'd love for you to share this episode if you think it could help other developers careers. Thank you so much for listening and until next time, enjoy your tea.