Heroes appear when something has gone wrong. What does a team look like with no heroics?
Heroes appear when something has gone wrong. What does a team look like with no heroics?
Today's episode is sponsored by LaunchDarkly. LaunchDarkly 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 risk, and rest easy.
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com/contact.
If you would like to join the new experimental Discord group, reach out at developertea.com/contact, developertea@gmail.com, or @developertea on Twitter.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
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 a workplace. And interestingly, this has nothing to do with the kind of person, the personality type that would try to be a hero. My name is Jonathan Cottrell. You're listening to Developer Tea. My goal on this 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 of what it would take to be considered a hero. In most cases, heroes are born out of some kind of disaster. A hero comes and saves the day. They help someone avoid or respond. They're shown 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 what was going to happen, then 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. 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, LaunchDarkly. LaunchDarkly 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, bringing players together and bringing players together and bringing players together and 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 LaunchDarkly 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 LaunchDarkly, IBM went from deploying twice a week to over a hundred 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 LaunchDarkly for sponsoring today's episode of Developer Team. So there are some seemingly obvious ways that you could have a code release that you could have a feature release that you could have a act like a hero on a software engineering team. And that there are more subtle ways you could act like a hero. The 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 business is about the code. At the very least, you may have taken the plunge from bringing evolution to evolution and 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'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 and you're deciding that you're going to take on this extra work on behalf of your team so 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 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. 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 swoop in and save 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. On most teams, this is problematic, unless you're a team that's going to be working late. Unless you have a culture where everybody has 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 they 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 that 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 in the company. And then those select people being a gateway. Gateways or gatekeepers provide a certain type of heroics. When somebody needs something, they go to these people and they provide them what they need. Once again, if we look at that cue, behavior, and reward, we see a very similar pattern. That a 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 lauded. 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 nuanced information that's necessary. And so a lot of times the prescription is to work on documentation or work on teaching the information about the system. Or to work on 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. 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 that, and 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. And 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 there's no hero. It's hard to find someone to praise or to give credit to when there's no hero. It's hard to find someone 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 heroics altogether, and perhaps more importantly, avoid the negative events that we're experiencing. 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. I want you to 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, LaunchDarkly. If you want to have hero-less feature releases, head over to launchdarkly.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. See you soon.