You've probably had the urge to be a hero before, and if you are a manager, especially, this can put you in a sense of conflict. Should you come and save the day, or should you step back and let things run their course? In today's episode, I want to explore the idea of why heroics can be confusing, perhaps even toxic in workplace. And interestingly, this is nothing to do with the kind of person, the personality type that would try to be a hero. My name is Jonathan Cutrell, you're listening to Developers He, my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. So what does it mean to be a hero? Let's break this down into kind of the nuts and bolts. What it would take to be considered a hero? In most cases, heroes are born out of some kind of disaster. The hero comes and saves the day. They help someone avoid or respond to some awful event. Now, the most important factor that is very often ignored about heroes is that the awful event must be apparent. In other words, if we had a hero that saved us from an awful event, that we didn't know was going to happen. And how would they achieve the title of hero? And herein lies the main issue, the big problem of heroics. When we think about heroics, there are a lot of different behaviors that we might applaud, that we might look at and say, ah, these are the important behaviors of saving the day. And it makes sense that we would crave the heroic persona. It makes sense that we would want that in our lives for a couple of reasons. One, nobody wants to experience the negative sides of those disaster events. We all would like to have someone swoop in and help us avoid those. So there's kind of a rational reason why heroes are something that we would appreciate. But there's more to it than that. And specifically, there is some kind of cycle that we maybe unintentionally crave in this heroic response. The cycle looks something like this. We have good times, we have bad times. We have peace, time, and we have war time. Sometimes we even use these words in our work. We might use the term battle, for example, when we're talking about fighting a bug. And so there's this sense that a dramatic timeline is somehow going to provide us excitement. Now, this isn't something that we would explicitly say out loud. Nobody's going to sit down and say, one of the things I look for in my job is a little bit of drama. Nobody really believes, at least cognizantly, that they want to invite drama. And yet, there is some sense of reward that we have when a hero does save the day. And in this episode, I want to talk about some of those heroic acts that we might take on. But I want to dig deeper into this idea that we can avoid heroics and achieve even better outcomes. If only we can set aside our innate craving and addiction to that dramatic cycle. But first, I want to talk about today's sponsor, Launch Darkly. Launch Darkly is today's leading feature management platform, empowering your teams to safely deliver and control software through feature flags. By separating code deployments from feature releases, you can deploy faster, reduce your risk, and rest easy. This is a huge problem with major releases, especially when you have multiple teams working on multiple releases, all simultaneously, on the same product. This can be a nightmare. In fact, not only a nightmare, you'd be asleep if it was a nightmare. This could keep you up all night because you're having to watch your servers, you're having to watch the logs, you're having to watch bug reports file in on a launch night. What Launch Darkly allows you to do is launch that code completely decoupled from the actual release of the feature. This is for small businesses. This is for medium businesses. This is for huge businesses, for example, with Launch Darkly IBM. And from deploying twice a week to over 100 times a day, we've been able to roll out new features at a pace that would have been unheard of a couple of years ago, said IBM's Kubernetes delivery lead, Michael McKay. You can learn more about how to separate your code release from your feature releases and sleep easy by heading over to launchdarkly.com. Thanks again to Launch Darkly for sponsoring today's episode of Developer Tea. So there are some seemingly obvious ways that you could act like a hero on a software engineering team. And that there are more subtle ways you could act like a hero. So obvious ways are staying up late and pushing out code well after the normal hours that the rest of the team would be working. And there are very clear reasons why celebrating somebody who does this is a bad idea. Remember that so much of our behavior as humans is based on the cycle of Q, which is some kind of signal, some kind of trigger. In this case, the trigger might be, oh no, we are, we're supposed to launch this feature and we're not ready yet. We have two days worth of work and only one day to do it. So we're supposed to launch this feature tomorrow, but we can't reasonably expect inside of our normal hours to do it until two days from now. That might be the Q. The behavior and then the reward, the behavior in this case might be, you know that you have the free time tonight. You're deciding that you're going to take on this extra work on behalf of your teams that they don't have to do it or so that someone else is going to be happy, that the release is done on time. And so you take on the work, which is the behavior and finally the reward. In this case, the reward might be, and perhaps the worst possible reward, which is the social recognition of someone who has done something that is very good by staying up late and working extra. And the additional reward might be the praise from a superior, somebody who is in a position of power over that team. Okay, so the reason why this is bad is very clear. If we continue to reinforce this habit, then the consequence of being late on the deadline becomes very minimal. Number one, right? This is a problem because if we fail to plan initially, then we can kind of allow ourselves to believe that the hero is going to come in and so we've been and saved the day. And we get used to this because we're conditioned to be used to it. Not because it's the right thing to do and not because we are bad people, but because we've conditioned ourselves with the cue, the behavior, and the reward. And so if we reinforce this idea, then it also becomes normalized that the response to a late timeline is to work late into the night. And this is problematic. This is problematic unless you have a culture where everybody is kind of opted into this idea that they really enjoy working late at night. This is a very rare scenario because most teams have a variety of people with a variety of backgrounds. And not only that, those people's lives will change over time. They may have new responsibilities that they adopt into their lives, some other kind of responsibility that takes the time that the otherwise would have been overworking. And now this behavior that's been trained suddenly, they can't participate. There's no opportunity for the person who's doing a very good job to ever be the hero. This is obviously a problem. Okay, so this is a very obvious version of Heroics, but there are other versions of Heroics that are less obvious than you probably wouldn't call saving the day necessarily, but it kind of works the same way. Examples of this are having information that is not available except to a few select people on the company and then those select people being a gateway. And gateways or gatekeepers provide a certain type of heroics when somebody needs something that go to these people and they provide them what they need. Once again, if we look at that Q behavior and reward, we see a very similar pattern. That person is in need, that there's some kind of crisis possibly in that moment. They go and they ask for the thing that they need. And just by virtue of having that information kept locked up into one person's access, that person is now modded in some way because they were available. Now this happens with really trivial things, perhaps it's not as much of a problem, but when it happens with information like knowledge about a system, knowledge about a code base, well now we start getting back into that dangerous territory because this person just by virtue of having information that other people don't have, they become a linchpin. It's well known that this is a high risk scenario because of losing that person. If you were to lose that person if they left the company, it would be very hard to replicate that knowledge. And so you'd have to go through a pretty serious learning process without somebody who has that firsthand knowledge and the nuance information that's necessary. And so a lot of times the prescription is to work on documentation or work on teaching the information about that particular system to another software engineer. But it's very often forgotten, some of the damage that this causes while that engineer is securely on the team. Specifically, the reinforcement of the idea that this person's job security for example is based on the scarcity of that information. In other words, once they no longer are the only person that has that information, they lose the ability to be the hero, to be the hero of that particular code base. And so this creates a perverse incentive where that person has the economic incentive at least to avoid giving the information to other people. And perhaps in very extreme cases, this is probably not very common, but in extreme cases, allowing complexity to increase, allowing things to get harder to understand in that code base. Certainly, there are very few motivators to make things easier to understand. Unless we create those new habits, we create the new feedback loops, we find new cues, we find new behaviors, and we find new rewards. This requires us to rewire our thinking about what it means to be a hero. Remember, a lot of the reason why heroes exist in the first place is that something went wrong. There is some catastrophe event that is occurring. Now we don't think about villains very often. It's very possible that the villain and the hero are one and the same in a given story arc. The villain, or perhaps a better name for this, might be the unwitting person who caused the event, who precipitated the terrible event to begin with. They are very often forgotten in the shadow of that hero. When something bad occurs and a hero comes along and saves the day, we forget that it would have been better, probably. It would have been better had we avoided the bad situation to begin with. Now it's very clear. Now that we've talked through this and we've explained why there's all these perverse incentives and all these situations that cause hero making to be pretty bad for business, pretty bad for our team's health. It's pretty clear why we want to be heroes. It also is clear that there is no hero in peacetime. It's hard to find someone to praise or to give credit to when nothing goes wrong. So this is kind of the takeaway or the homework, I guess. A very hard thing to do. But to create a new criteria for celebration, to create a new criteria for celebration, we need to look at the things that we want to be happening more often on our teams. Do we want to have peacetime celebrated? If so, what are the kinds of behaviors that help us avoid those bad occurrences? How can we investigate and find those behaviors so that we celebrate the behavior? We reinforce it. We find the cues that precipitated that behavior. We reinforce it through celebration. And we can avoid heroic solid together and perhaps more importantly, avoid the negative events as well. I'll leave you with a final kind of bookmark. Hopefully you can think back to this episode when you see or hear about a hero. And once you think first, rather than down the line after you've had a chance to celebrate the hero, first I want you to think what went wrong to make this necessary? What occurred to make the hero an important part of this process? How could we have made the hero unnecessary? Thanks so much for listening to today's episode of Developer Tea. Thanks so much again to today's sponsor, Launch Darkly. If you want to have heroless feature releases, head over to launchadarkly.com. So you can separate your feature releases from your code releases and sleep easy at night. Thanks so much for listening to today's episode. If you want to join the Developer Tea Discord, we're starting to open up these invites to people who are listening to these episodes all the way through. We're going to start doing this only at the end of the episode. You can head over to developertea.com slash discord to join today. Thanks so much for listening and until next time, enjoy your tea.