Hey everyone, it's been a little bit since we last released an episode of this show and I'm excited to be back. A quick update. I've been working on a new recording studio. You might hear a little bit of a difference in my voice. We've got a treated room now. A bunch of time and effort into making this studio a notch above where we had it before. Hopefully that comes out in the quality of the audio. I also am a musician. I like recording music and so that was a side benefit as well. I also got a new job recently. I now work at Calendly. If you're not familiar with Calendly, go and check it out. Calendly.com. Onboarding to this job has taught me a lot. I've learned so much in just a short few weeks. I'm going to be sharing a lot of what I'm learning as I go through this onboarding process. Once again, as a senior engineering manager. I'm going to be sharing some of that experience. I'm also going to share with you in upcoming episodes an interview that I did with my coach. I have a coach now. His name is Brian. I'm going to have an interview releasing soon with Brian and I talking about some of the things that you might be interested in learning if you're in the market for a job. Brian can also help you. But in today's... In today's episode, I want to focus in on a very specific behavior. A very specific characteristic behavior that you'll very often you'll see this on a list of values at a given company. A list of values for the individuals who work at the company or for the org more broadly. And the value is usually stated as... As bias to action. Bias to action. Now, not long ago, we released an episode of this show that talked about kind of the downside of the bias to action. Bias to action is actually something that humans tend to have anyway. This is interesting because very often when we get into a new engineering role or if we've been in one for a long time. Our bias to action shows up. In some of the wrong ways. So we're going to clarify the difference between our kind of natural bias to action versus what companies tend to be talking about when they put this on their list of values. So this idea of bias to action. This is actually a very important trait or characteristic of behavior. If you can learn how to use it properly. All right. So if you are joining... If you are joining an organization, especially if you're joining a startup, an organization that is going through some kind of change, some kind of ambiguity. These are the organizations that tend to need people that have a bias to action. What does a bias to action mean in this context? And how does it differ from our natural bias to action? Let's talk first about our natural bias to action. The natural bias to action. The natural bias to action is the need to do something. The overwhelming sense that given a situation, we should respond somehow. Now, notice that this is... We can kind of resolve this need, this feeling, this requirement that is in our brains of acting by doing almost anything. It doesn't have to be a productive action to resolve this. So in other words, our bias to action might lead us to send a slack message about why we can't do the other thing. Right? If the... Let's say that the demand on the table is... We need to figure out how to break down this piece of work. It's too large. It's too ambiguous. We need to work with... Somebody in a product department or stakeholder. Somebody to break this work down. All right? So our internal kind of natural bias to action informs us that we need to resolve the need somehow. One way that we might do this is an easy way. And it turns out that we like the easy path. Easy way to resolve this might be to recognize that you don't know who this is. You don't know who the stakeholders are. You may send a slack message or update the JIRA ticket and say, we don't have a list of the stakeholders. And you've resolved your bias to action. Now, hopefully you can guess that this is not the same bias to action that is in those company values or in the engineering values. It's not the same thing that's on that job description. So what is the difference? It's the same thing. When we see bias to action as... As a positive trait of, let's say, a senior engineer. Or when we see it on a job description. What it's really talking about is a bias to agency. Or another way to think about this is a bias to believe that you can solve a given problem that's laid in your lap. Now, that's not as catchy. And so we say bias to action. But we don't mean any action. What we really... What we really mean is you have a tendency to find a path to a solution. To find a way to solve the problem that's been laid in front of you. Now, our built-in bias to action doesn't do that necessarily. It resolves rather than solves. The big difference here is that resolution is something that reduces our cognitive load. Resolving may come in many different forms. Delegation is a type of resolution. Other kinds of resolution might actually include doing the thing. Solving the problem. But other kinds are making excuses. An excuse, properly placed, is resolving the problem as far as our cognitive load is concerned. We can kind of let go of that problem until it comes back again. And it's important to pay attention to this. Because cognitive load, especially when it's high, will result in us making decisions to shed it. In other words, when we're really stressed out, when we have a lot going on, we're more likely to do things that essentially are a shortcut. So this is not really what we want to encourage or kind of seek. Instead, what we should be doing is to make decisions. Instead, what we should be doing is to make decisions. Instead, what we should be doing is to make decisions. Instead, what we should be doing is to make decisions. Instead, what we should be doing is focusing on the outcome. The problem that we're looking at is not about resolving the cognitive dissonance or cognitive load. We should be creating pathways or systems to manage our cognitive load so that we can actually spend the time necessary to resolve and solve the problem. Another heuristic you might want to use, or maybe a kind of a warning flag, is the opposite of bias to action in the business sense is a bias to a dead end. If someone is coming to you asking you a question that may lead to an opportunity or some kind of solution, and you respond with something that is essentially shutting them down, this tends to be kind of the opposite of a bias to action. Now, this doesn't mean, that you should never shut something down. That's not what we're saying. But if you have a tendency or a pattern of doing that, then you're not likely to be kind of cast into the role of someone who generally is known for finding solutions. So this is a characteristic, and there are a lot of tools you can use to kind of head down this road. We'll explore just a few kind of linguistic ones here very quickly. The first is a root cause analysis. This is the basic idea of using something like a five wise. There are other kind of techniques you might want to use. But when somebody comes to you with a problem or a question, you may want to dig to find out a little bit more. Why is it that we haven't been able to plan for that project yet? Why is it that we can't figure out who those stakeholders are? Why is it that that bug keeps on coming up? Why is it that that bug keeps on coming up? Why is it that that bug keeps on coming up? Why is it that that bug keeps on coming up? Why is it that that bug keeps on coming up over and over again? Or why is it that we have tests that are always failing, but nobody feels the need to fix them? Another linguistic trick that you might use, it's not really as much of a linguistic trick as it is a mental model, is to kind of start from the solution and back your way into it. So what would be necessary for this to be true? What is it that's standing in the way of us operating in this particular way? So let's say a process change, change is being proposed in a leadership meeting. You're a senior engineer or maybe you're an engineering manager, and there's a lot of concern about the process change, but nobody's really identifying what exactly would need to happen to allow this process change to succeed. So your opportunity here as a leader in your team or at your company, is to ask the question, what exactly should we do to make this successful? What is missing? Not necessarily why can't it be successful? It's kind of a different question. Instead, we should be thinking about what actions can we take? What are the next steps? What should I be thinking about in order to accomplish this? Not why can I not accomplish this? There's a subtle difference, but that subtle difference can make or break your next promotion. It can make or break the success that you see in your career and ultimately the actual solutions you produce. I encourage you to consider, are you falling prey to the kind of inbuilt or innate bias to action, which is not incredibly useful, or are you actually practicing? This tenacity to find real solutions. Thanks so much for listening to today's episode of Developer Tea. We should be back on a relatively normal schedule very soon. We're still finishing up some things with the new studio, but as that gets wrapped up, we should be back to our normal kind of two episodes a week or so schedule. So please go ahead and subscribe if you haven't. Maybe you unsubscribed at some point and you can subscribe once again in whatever podcasting app you're currently using. This will probably be the only episode for this week because it is the 4th of July holiday in the United States. And a lot of you probably would miss the next episode if we were to try to release one on Thursday or Friday. Please enjoy the time and we will be back next week with another episode. And once again, soon we will have an interview with Brian Pulliam. Thanks so much for listening. And until next time, enjoy your tea. Bye. Bye. Bye.