Vox

Leitura de 17 min

Ban the Heroics On Your Team

Summary

The episode explores the concept of ‘heroics’ in software development teams—situations where individuals swoop in to save the day during crises. Host Jonathan Cottrell argues that while heroic acts are often celebrated, they create harmful cycles and perverse incentives. He breaks down the psychology using a cue-behavior-reward model, showing how heroics normalize poor planning and create dependency on individuals.

Cottrell identifies two main types of heroics: obvious ones like working late nights to meet deadlines, and subtle ones like gatekeeping knowledge or system expertise. Both types reinforce the idea that crises are necessary for recognition, and they discourage behaviors that prevent problems in the first place. The episode examines how heroics can undermine team health by creating single points of failure and disincentivizing knowledge sharing.

The host suggests that the real problem isn’t the heroic individuals, but the systems that make heroics necessary and rewarding. He challenges listeners to reconsider what behaviors their teams celebrate, advocating for recognition of ‘peacetime’ achievements—actions that prevent disasters rather than respond to them. This requires consciously creating new feedback loops that reward planning, documentation, and collaboration.

Ultimately, Cottrell proposes that teams should aim to make heroes unnecessary by focusing on prevention and creating cultures that celebrate avoiding problems rather than solving them dramatically. The episode concludes with practical questions teams can ask when they encounter heroic behavior to identify systemic issues that need addressing.

Recommendations

Tools

  • LaunchDarkly — A feature management platform that allows teams to separate code deployments from feature releases using feature flags, helping reduce risk and avoid heroics during major releases by enabling controlled rollouts.

Topic Timeline

  • 00:00:00 — Introduction to the problem of heroics in teams — Jonathan introduces the episode’s topic: the conflict managers face when deciding whether to be a hero or let things run their course. He explains that heroics can be confusing and toxic in workplaces, and promises to explore why this happens and how to achieve better outcomes by avoiding dramatic cycles.
  • 00:01:06 — Defining what makes a hero and the hidden requirement — The host breaks down what it means to be a hero, noting that heroes emerge from disasters where they save people from awful events. He identifies the crucial, often ignored factor: the awful event must be apparent to those being saved. This leads to the core problem—heroes need visible crises to be recognized.
  • 00:02:50 — The psychological cycle we crave in heroic responses — Cottrell explores why we crave heroic personas, noting both rational reasons (wanting to avoid negative events) and a deeper psychological cycle. He describes this as a dramatic timeline alternating between peace/war times that provides excitement and reward, even though people wouldn’t consciously admit to wanting workplace drama.
  • 00:06:17 — Obvious and subtle forms of heroics in software teams — The host distinguishes between obvious heroics (like staying up late to push code) and more subtle forms (like gatekeeping information). He analyzes both using the cue-behavior-reward model, showing how they create harmful patterns that normalize crisis responses and create dependencies on specific individuals.
  • 00:10:44 — The dangers of knowledge gatekeeping and perverse incentives — Cottrell examines how information gatekeeping creates hero dynamics, where individuals become linchpins by controlling scarce knowledge. This creates perverse incentives where people might avoid sharing information to maintain their heroic status, potentially even allowing complexity to increase to preserve their unique value.
  • 00:13:40 — Rewiring thinking about heroes and celebrating prevention — The host argues that we need to rewire our thinking about heroism by recognizing that villains and heroes are often connected in the same story arc. He suggests creating new criteria for celebration that focuses on behaviors that prevent problems rather than solve them, asking teams to consider what went wrong to make a hero necessary.
  • 00:15:07 — The challenge of finding heroes in peacetime — Cottrell observes that there are no heroes in peacetime—it’s hard to praise someone when nothing goes wrong. This leads to his main takeaway: teams need to create new celebration criteria that reinforce behaviors helping avoid bad occurrences, investigating and finding those behaviors to celebrate prevention over crisis response.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2021-03-24T07:00:00Z
  • Duration: 00:17:44

References

Podcast Info

Transcript

[00:00:00] You’ve probably had the urge to be a hero before and if you are a manager

[00:00:09] especially this can put you in a sense of conflict. Should you come and save the

[00:00:19] day or should you step back and let things run their course? In today’s

[00:00:28] episode I want to explore the idea of why heroics can be confusing perhaps

[00:00:37] even toxic in a workplace and interestingly this is nothing to do

[00:00:42] with the kind of person the personality type that would try to be a hero. My name

[00:00:49] is Jonathan Cottrell you’re listening to developer T my goal on the show is to

[00:00:53] help driven developers like you find clarity perspective and purpose in their

[00:00:58] careers. So what does it mean to be a hero? Let’s break this down into kind of

[00:01:06] the nuts and bolts of what it would take to be considered a hero. In most cases

[00:01:13] heroes are born out of some kind of disaster. A hero comes and saves the day

[00:01:22] they help someone avoid or respond to some awful event. Now the most important

[00:01:31] factor that is very often ignored about heroes is that the awful event must be

[00:01:40] apparent. In other words if we had a hero that saved us from an awful event that

[00:01:48] we didn’t know was going to happen and how would they achieve the title of hero?

[00:01:57] And herein lies the main issue the big problem of heroics. When we think about

[00:02:08] heroics there are a lot of different behaviors that we might applaud that we

[00:02:15] might look at and say ah these are the important behaviors of saving the day.

[00:02:20] And it makes sense that we would crave the heroic persona. It makes sense that

[00:02:29] we would want that in our lives for a couple of reasons one nobody wants to

[00:02:35] experience the negative sides of those disaster events we all would like to

[00:02:40] have someone swoop in and help us avoid those. So there’s kind of a rational

[00:02:45] reason why heroes are something that we would appreciate but there’s more to it

[00:02:50] than that and specifically there is some kind of cycle that we maybe

[00:02:59] unintentionally crave in this heroic response. The cycle looks something like

[00:03:06] this we have good times we have bad times we have peace time and we have

[00:03:12] war time. Sometimes we even use these words in our work. We might use the term

[00:03:18] battle for example when we’re talking about fighting a bug and so there’s this

[00:03:25] sense that a dramatic timeline is somehow going to provide us excitement.

[00:03:35] Now this isn’t something that we would explicitly say out loud nobody’s going

[00:03:39] to sit down and say one of the things I look for in my job is a little bit of

[00:03:43] drama. Nobody really believes at least cognizantly that they want to invite

[00:03:49] drama and yet there is some sense of reward that we have when a hero does

[00:03:58] save the day. And in this episode I want to talk about some of those heroic acts

[00:04:03] that we might take on but I want to dig deeper into this idea that we can avoid

[00:04:11] heroics and achieve even better outcomes. If only we can set aside our innate

[00:04:20] craving and addiction to that dramatic cycle. But first I want to talk about

[00:04:26] today’s sponsor LaunchDarkly. LaunchDarkly is today’s leading feature

[00:04:34] management platform empowering your teams to safely deliver and control

[00:04:38] software through feature flags. By separating code deployments from feature

[00:04:42] releases you can deploy faster reduce your risk and rest easy. This is a huge

[00:04:49] problem with major releases especially when you have multiple teams working on

[00:04:54] multiple releases all simultaneously on the same products. This can be a nightmare.

[00:05:01] In fact not only a nightmare you’d be asleep if it was a nightmare. This could

[00:05:07] keep you up all night because you’re having to watch your servers, you’re

[00:05:11] having to watch the logs, you’re having to watch bug reports file in on a launch

[00:05:15] night. What LaunchDarkly allows you to do is launch that code completely

[00:05:22] decoupled from the actual release of the feature. This is for small businesses,

[00:05:29] this is for medium businesses, this is for huge businesses. For example with

[00:05:34] LaunchDarkly IBM went from deploying twice a week to over a hundred times a

[00:05:39] day. We’ve been able to roll out new features at a pace that would have been

[00:05:43] unheard of a couple of years ago said IBM’s Kubernetes delivery lead Michael

[00:05:49] McKay. You can learn more about how to separate your code release from your

[00:05:54] feature releases and sleep easy by heading over to LaunchDarkly.com.

[00:06:00] Thanks again to LaunchDarkly for sponsoring today’s episode of developer

[00:06:03] team. So there are some seemingly obvious ways that you could act like a hero on a

[00:06:17] software engineering team and that there are more subtle ways you can act like a

[00:06:22] hero. The obvious ways are staying up late and pushing out code you know well

[00:06:31] after the normal hours that the rest of the team would be working and there are

[00:06:38] very clear reasons why celebrating somebody who does this is a bad idea.

[00:06:43] Remember that so much of our behavior as humans is based on the cycle of Q which

[00:06:52] is some kind of signal some kind of trigger. In this case the trigger might

[00:06:56] be oh no we are you know we’re supposed to launch this feature and we’re not

[00:07:01] ready yet. We have you know two days worth of work and only one day to do it.

[00:07:06] So we’re supposed to launch this feature tomorrow but we can’t want we can’t you

[00:07:12] know reasonably expect inside of our normal hours to do it until two days

[00:07:16] from now. That might be the Q. The behavior and then the reward the behavior

[00:07:23] in this case might be you know that you have the free time tonight and you’re

[00:07:29] deciding that you’re going to take on this extra work on behalf of your team

[00:07:34] so that they don’t have to do it or so that someone else is going to be happy

[00:07:38] that the release is done on time. And so you take on the work which is the

[00:07:44] behavior and finally the reward. In this case the reward might be and perhaps the

[00:07:50] worst possible reward which is the social recognition of someone who has

[00:07:55] done something that is very good by staying up late and working extra. And

[00:08:01] the additional reward might be the praise from a superior somebody who is

[00:08:07] in a position of power over that team. Okay so the reason why this is bad is

[00:08:14] very clear. If we continue to reinforce this habit then the the consequence of

[00:08:24] being late on the deadline becomes very minimal. Number one this is this is a

[00:08:33] problem because if we fail to plan initially then we can kind of allow

[00:08:38] ourselves to believe that the hero is going to come in and swoop in and

[00:08:42] save the day. And we get used to this because we’re conditioned to be used to

[00:08:47] it. Not because it’s the right thing to do and not because we are bad people but

[00:08:53] because we’ve conditioned ourselves with the Q the behavior and the reward. And so

[00:09:00] if we reinforce this idea then it also becomes normalized that the response to

[00:09:06] a late timeline is to work late into the night. And this is problematic on most

[00:09:14] teams this is problematic unless you have a culture where everybody has kind

[00:09:17] of opted into this idea that they really enjoy working late at night. This is a

[00:09:22] very rare scenario because most teams have a variety of people with a variety

[00:09:28] of backgrounds and not only that those people’s lives will change over time.

[00:09:35] They may have new responsibilities that they adopt into their lives some other

[00:09:43] kind of responsibility that takes the time that the otherwise would have been

[00:09:46] overworking. And now this behavior that’s been trained suddenly they can’t

[00:09:52] participate. There’s no opportunity for the person who’s doing a very good job

[00:09:57] to ever be the hero. This is obviously a problem. Okay so this is a very obvious

[00:10:06] version of heroics but there are other versions of heroics that are less

[00:10:12] obvious that you probably wouldn’t call saving the day necessarily but it kind

[00:10:20] of works the same way. Examples of this are having information that is not

[00:10:26] available except to a few select people in the company and then those select

[00:10:32] people being a gateway. And gateways or gatekeepers provide a certain type of

[00:10:39] heroics. When somebody needs something they go to these people and they provide

[00:10:44] them what they need. Once again if we look at that cue behavior and reward we

[00:10:52] see a very similar pattern that a person is in need that there’s some kind

[00:10:57] of crisis possibly in that moment. They go and they ask for the thing that they

[00:11:03] need and just by virtue of having that information kept you know locked up into

[00:11:09] one person’s access that person is now lauded in some way because they were

[00:11:17] available. Now this happens with really trivial things perhaps it’s not as much

[00:11:22] of a problem but when it happens with information like knowledge about a

[00:11:27] system right knowledge about a code base well now we start getting back into that

[00:11:34] dangerous territory because this person just by virtue of having information

[00:11:40] that other people don’t have they become a linchpin. It’s well known that this is

[00:11:47] a high-risk scenario because of losing that person right if you were to lose

[00:11:52] that person if they left the company it would be very hard to replicate that

[00:11:56] knowledge. And so you’d have to go through a pretty serious learning

[00:12:00] process without somebody who has that firsthand knowledge and the nuanced

[00:12:04] information that’s necessary. And so a lot of times the prescription is to you

[00:12:10] know work on documentation or work on teaching the information about that

[00:12:15] particular system to another software engineer but it’s very often forgotten

[00:12:21] some of the damage that this causes while that engineer is securely on the

[00:12:26] team. Specifically the reinforcement of the idea that this person’s job security

[00:12:33] for example is based on the scarcity of that information in other words once

[00:12:41] they no longer are the only person that has that information they lose the

[00:12:46] ability to be the hero to be the hero of that particular code base. And so this

[00:12:52] creates a perverse incentive where that person has the economic incentive at

[00:12:58] least to avoid giving the information to other people and perhaps in very extreme

[00:13:05] cases this is probably not very common but in extreme cases allowing complexity

[00:13:12] to increase allowing things to get harder to understand in that code base.

[00:13:18] Certainly there are very few motivators to make things easier to understand

[00:13:25] unless we create those new habits we create the new feedback loops we find

[00:13:32] new cues we find new behaviors and we find new rewards. This requires us to

[00:13:40] rewire our thinking about what it means to be a hero. Remember a lot of the

[00:13:46] reason why heroes exist in the first place is that something went wrong there

[00:13:52] is some catastrophe event that is occurring. Now we don’t think about

[00:13:58] villains very often it’s very possible that the villain and the hero are one

[00:14:04] and the same in a given story arc. The villain or perhaps a better name for

[00:14:12] this might be the unwitting person who caused the event who precipitated the

[00:14:18] terrible event to begin with they are very often forgotten in the shadow of

[00:14:25] that hero. When something bad occurs and a hero comes along and saves the day we

[00:14:32] forget that it would have been better probably it would have been better had

[00:14:37] we avoided the bad situation to begin with. Now it’s very clear and now that

[00:14:44] we’ve talked through this and we’ve explained why there’s all these perverse

[00:14:48] incentives and all these situations that cause hero making to be pretty bad for

[00:14:53] business pretty bad for our team’s health. It’s pretty clear why we want to

[00:14:58] be heroes and it also is clear that there is no hero in peacetime. It’s hard

[00:15:07] to find someone to praise or to give credit to when nothing goes wrong. So this

[00:15:16] is kind of the takeaway or the homework I guess a very hard thing to do but to

[00:15:24] create a new criteria for celebration. To create a new criteria for celebration we

[00:15:32] need to look at the things that we want to be happening more often on our teams.

[00:15:38] Do we want to have peacetime celebrated? If so what are the kinds of behaviors

[00:15:45] that help us avoid those bad occurrences? How can we investigate and find those

[00:15:53] behaviors so that we celebrate the behavior, we reinforce it, we find the

[00:16:01] cues that precipitated that behavior, we reinforce it through celebration and we

[00:16:07] can avoid heroics altogether and perhaps more importantly avoid the negative

[00:16:13] events as well. I’ll leave you with a final kind of bookmark. Hopefully you

[00:16:19] can think back to this episode when you see or hear about a hero. I want you to

[00:16:27] think first rather than down the line after you’ve had a chance to celebrate

[00:16:33] the hero. First I want you to think what went wrong to make this necessary? What

[00:16:40] occurred to make the hero an important part of this process? How could we have

[00:16:49] made the hero unnecessary? Thanks so much for listening to today’s episode of

[00:16:54] Developer T. Thanks so much again to today’s sponsor LaunchDarkly. If you

[00:16:58] want to have hero-less feature releases head over to LaunchDarkly.com so you

[00:17:04] can separate your feature releases from your code releases and sleep easy at

[00:17:08] night. Thanks so much for listening to today’s episode. If you want to join the

[00:17:12] Developer T Discord, we’re starting to open up these invites to people who are

[00:17:18] listening to these episodes all the way through. We’re going to start doing this

[00:17:21] only at the end of the episode. You can head over to DeveloperT.com

[00:17:26] slash Discord to join today. Thanks so much for listening and until next time

[00:17:33] enjoy your tea.

Visão de gráfico