5 ms·

Hero engineers can be deadly to team culture, it's time to retire those capes

22 points by ochronus 7y ago

afarrell 7y ago
General statement: The presence of a hero means something has gone terribly wrong. Anyone got a counter-example?
- candiodari 7y ago
  Given that it's about startups, I would argue that we should take into account that there's potentially strong survivor bias at work here. Counter-examples aren't there because these companies "good practiced" themselves into the grave.
- Bartweiss 7y ago
  Not a counter-example precisely, but it's a truism in software that something always goes wrong. Sometimes the hero comes from mismanagement and bad planning, but sometimes they're a response to 'natural' problems. I've seen a few heroes at largish companies who do this fairly sustainably by floating around different projects and teams. They're not necessarily the most brilliant engineers around, but they're a bit less subject to the tyranny of Brooks' Law than most people; they pick up new projects fast and are willing to work crunch hours to contribute. In most companies, I think the presence of someone in that role would be inherently unhealthy, but there seem to be a few places where it's a workable response to the general schedule slip of software development.
m_fayer 7y ago
In most startups, there's going to be that one engineer that's over the team's baseline as far as skill, sense of responsibility, and willingness to hurt themselves. Since most startups habitually commit potentially mortal strategic and planning errors, that one engineer will be repeatedly tempted to become "the hero." One of those times they will take the bait, and the cycle described in this post will commence. I would venture that the startups that make it are the ones who luck into having a good supply of these types, and they all have a long trail of burned out bitter "heroes" in their wake.
emeraldd 7y ago
My first thought on reading this is that the author is blaming the engineer for something that is as much a failure on the management side as anything else. The little clarification block at the bottom is too little too late in my opinion...
- ochronus 7y ago
  Fair point, thanks for the feedback! I'll consider moving that statement up ahead
- ochronus 7y ago
  aaand it's done. Thanks again!
Bartweiss 7y ago
The pattern outlined here and the problems it causes are certainly real - I think most people who've seen a few large projects will recognize it. I wonder, though, at the final section about how converting 'hero engineers' back into regular ones is possible, but unpleasant and unreliable. If you try to change someone's role to involve less work and shorter hours and they hate you for it, something has probably gone very wrong. I've been friends with a couple of perennial 'hero engineers', as opposed to people pushed into that by a specific crisis. By and large, they like working that way, and would be very unhappy to swap into 'normal' roles. That's a useful trait! It's just squandered by a career of 12+ hour days and random priority shifts. (More broadly, I think healthy insight that software doesn't come from lone geniuses often neglects the value of those people and tries to reduce them to line programmers. Roles like hero engineer, guru, or hermit hacker can be perfectly useful in a business - just not as ways to produce day-to-day features in a larger project.) What's the alternative? Some of them have become excellent managers, using the same resourcing and firefighting skills more proactively. Others have ended up as sort of 'internal contractors', doing hero engineer work with a few key changes. In particular: time off and/or not working long hours between crunches, setting priorities by importance rather than convenience, making their role clearly distinct from 'normal' engineering expectations, ensuring teams understand and have a say in changes, and recognizing that this is the 'unhappy path' for projects to take. It generally seems to work best for companies doing things like selling customized software platforms, since they have many different 1-6 month projects going with independent schedules and shared domain knowledge. In practice, this looks something like: a projects falls behind or gets new requirements, an extra engineer (or several) are brought in, they work long hours getting up to speed and helping solve problems, once things are stable they spend some normal-length days with the team on training and tech debt to avoid 'owning' the result, then take some time off before the next cycle.
MBCook 7y ago
Hero seems like the wrong term. Why not call them a workaholic? Whether they choose to put in that many hours or the company asks them and they comply... isn’t that what’s going on?
- valbaca 7y ago
  "Martyr" is probably more apt.
yeahitslikethat 7y ago
This is practically impossible advice. Hero engineers can't stand sitting back watching things fail because no one else on the team cares enough to succeed. For the hero, either the project succeeds or fails. Step up! But non heros instead look for a target to blame and then proceed to sabotage that person and the project to ensure they don't get the blame themselves. Their job is to find ways to work as little as possible. The hero's job is a successful project. If it fails the hero is to blame. At the end of the day, it's always the engineers' fault if it fails. I can't believe this article blames the problems on those who step up to fix them. Better just to ignore the problems? Reminds me of the folks who say, "don't work so hard! You're making the rest of us look bad! "
- deleted 7y ago
  [deleted]
- t0mbstone 7y ago
  No, the article is about the fact that when "heroes" stand up and "save" a poorly managed project, it creates a negative feedback loop that validates the poor management style and lack of planning. The "hero" also devalues themselves and their teammates by allowing management to abuse them and violate everyone's work-life balance. If this behavior is not nipped in the bud, it creates a toxic culture where projects are always being planned poorly, management's expectations are always misaligned with reality, and all of the engineers are burned out.
  - rubin55 7y ago
    Right, the issue here is that 1: a project is poorly managed and 2: that an individual decided to take up the banner and by sheer force of will (however unreasonable) "saves the project". I would say that if 1 is the case, then 2 might not be the best way to deal with it, but: What if a project is not particularly poorly managed? What if you simply have an ambitious deadline that the team as a whole tries to make, whereby different individuals probably perform differently? Is the "hero" or heroes, defined implicitly (in the article) by a higher pace, still to blame for a "toxic culture" as you call it? While you go ahead and nip that in the bud and make sure your teams are as average as possible, I'd go work somewhere where going the extra mile is actually appreciated.
grayed-down 7y ago
On some teams I've managed, I have had that one developer that's a great producer, but projected a great deal of negative energy into the group. This situation has to be dealt with as soon as it's recognized. Some of the actions I have resorted to is heavy "counseling", work from home, rent a small office separate from the main work space or bite the bullet and fire them.
hashkb 7y ago
I have been relied upon by management for quick fixes, breadth of familiarity with company systems, urgent code review of critical features nobody heard about until now, etc. * "hero" is a ridiculous word, we never feel like heroes and nobody treats us that way. we feel dirty and abused * of course it's a management problem, everything is, recognizing management problems is not part of the path to fixing them * the only thing management respects is hitting (arbitrary) deadlines, ergo that's our actual job Trying to leverage my position as a bottleneck to effect process change has ALWAYS resulted in a deteriorating relationship with executives. Maybe I'm not the most tactful guy, sure. But EOD it's their company. Just quit.
rubin55 7y ago
This article annoyed the hell out of me.. "Kill your heroes?", "Heroes can be deadly to team culture?" First off all, there can be many reasons why a project is late: bad time estimations, bad resource capability estimations, feature creep, to name a few. There can also be a whole list of things you can do about that: Revisit those time estimations, cue in time for training and education to better tacke the problems at hand, better scoping, and of course: the choice to work harder. The last option above should in all cases be a choice, not something that's forced on anyone, but if it's a choice, something that makes the individual happy, a challenge to tackle, then by all means, go for it and the team should be the better + happy for it. Of course this also means that one can not expect/force it on anyone. If I have a 6 person team and two people decide it's a good challenge to try and make the deadline, that does not mean the rest of the team are slackers; it also doesn't mean that those two are "heroes that need to retire their capes". When an individual decides to work harder, to reach a goal (or when the default pace of the individual happens to be higher in the first place), does that suddenly make the person or the practice toxic to the team (or "deadly" as the headline calls it)? What the article implies is that when a person tries (intentionally or not) to stand out from the group, it's bad for the group and bad for the person. This implication is highly alarming to anyone who would want to do his best to stand out, to be a better programmer than you were last week. A team is not a box that demands the average from each individual and punishes the one that stands out but a group of dynamic and different individuals that, through their differences achieve greatness.
- t0mbstone 7y ago
  Found the hero engineer
- saltcured 7y ago
  Aside from the hyperbolic "Kill your heroes" heading, the whole article is about management error. It doesn't even advocate firing the hero if they emerge, just recognition of this emergence as a warning signal that things are going wrong for the organization. I think the topic of the article is analogous to a military situation familiar from pop culture and current events. Let's focus on the human dynamics and ignore any technical baggage that might confuse the issue with 10x or rockstar developers and such. You can have regular infantry and special forces. The pathological situation would be expecting special forces levels of performance out of an infantry group, embedding a few special members to magically elevate them. It will deteriorate morale for all involved and produce unpredictable results, since they do not have the training and methods to work together effectively. But, don't get distracted into thinking that this argues that no regular infantry can be heroic. It's a metaphor, not a moral judgment. If properly managed, special units would have different missions which might complement the regular units. The special unit members are held to higher standards and still must cooperate. Self-serving cowboys typically get washed out, as the special teams demand high unit cohesion in order to accomplish their missions. But, the special team can excel together, not being limited by the roles, capabilities, and methods of a regular unit. It is not good for one member to try to stand apart from his unit. He can mentor and motivate from within, but members of the unit need to be able to rely on each other and to some degree substitute for each other. It would be a mistake to let him try to create his own special grade informally within the regular group, lacking the proper logistics and management support for that role. Another failure mode, not discussed in the article, is when an organization tries to be "all special". Lacking missions aligned to their preparation, they will eventually lose their skills and morale. They will start to perform unpredictably as they lose cohesion and focus. Also, in an attempt to grow a large special force, you would eventually run into supply problems and lower your entry or retention standards. Then, you might end up with forces special in name only, returning to the original scenario with a general infantry with some special members embedded in a toxic brew.
sys_64738 7y ago
Heroes exist due to incompetent management. Rule one of management is reduce risk and having a single developer fail the bus test is always management's fault.
- folkhack 7y ago
  > Heroes exist due to incompetent management. Yep - in the article incompetent management was laid out pretty clear: * The project is 3 months late * but he also wants you to finish your colleague’s project * But of course the original two projects are priority. But please fix the bug because it’s important I've been the "hero engineer" and I think that this manager is totally ignoring what he's already postulated. I'm not happy if I'm on a team that's three months behind and being tasked to do other's work because they're incapable, and I'll end up with a chip on my shoulder when I'm the only producer on a team (seriously, who wouldn't?). And mostly - you're damn-straight I'm gonna leave! Why would I STAY!? This sounds like a manager who has no business in picking a team of engineers to work on a project, which IMO happens way too often. We should be whiteboarding our leadership just as much as the engineers. In the US it's a pattern of zero technical competence at the middle management level... this leads to articles like this where high-performing developers are demonized for "bad attitude" immediately after the author outlines REAL reasons anyone may be unhappy with their employment. Welcome to the new work world though - where it's about the narrative of work more than it's ever about the work.
FatDrunknStupid 7y ago
Not going to make many friends with this post but let's start with - 'all generalisations are bollocks (including this one). I'm often the guy you describe, but, I 'work' much less than other people. I think about stuff and type it in when it's ready. Fires go out, things settle down. Changes are made. I get sacked because everyone else is 'working'(read typing and bum on seat) when I'm looking out of the window.

22 points by ochronus 7y ago

afarrell 7y ago

General statement: The presence of a hero means something has gone terribly wrong. Anyone got a counter-example?

candiodari 7y ago
Given that it's about startups, I would argue that we should take into account that there's potentially strong survivor bias at work here. Counter-examples aren't there because these companies "good practiced" themselves into the grave.
Bartweiss 7y ago
Not a counter-example precisely, but it's a truism in software that something always goes wrong. Sometimes the hero comes from mismanagement and bad planning, but sometimes they're a response to 'natural' problems. I've seen a few heroes at largish companies who do this fairly sustainably by floating around different projects and teams. They're not necessarily the most brilliant engineers around, but they're a bit less subject to the tyranny of Brooks' Law than most people; they pick up new projects fast and are willing to work crunch hours to contribute. In most companies, I think the presence of someone in that role would be inherently unhealthy, but there seem to be a few places where it's a workable response to the general schedule slip of software development.

m_fayer 7y ago

In most startups, there's going to be that one engineer that's over the team's baseline as far as skill, sense of responsibility, and willingness to hurt themselves. Since most startups habitually commit potentially mortal strategic and planning errors, that one engineer will be repeatedly tempted to become "the hero." One of those times they will take the bait, and the cycle described in this post will commence. I would venture that the startups that make it are the ones who luck into having a good supply of these types, and they all have a long trail of burned out bitter "heroes" in their wake.

emeraldd 7y ago

My first thought on reading this is that the author is blaming the engineer for something that is as much a failure on the management side as anything else. The little clarification block at the bottom is too little too late in my opinion...

ochronus 7y ago
Fair point, thanks for the feedback! I'll consider moving that statement up ahead
ochronus 7y ago
aaand it's done. Thanks again!

Bartweiss 7y ago

The pattern outlined here and the problems it causes are certainly real - I think most people who've seen a few large projects will recognize it. I wonder, though, at the final section about how converting 'hero engineers' back into regular ones is possible, but unpleasant and unreliable. If you try to change someone's role to involve less work and shorter hours and they hate you for it, something has probably gone very wrong. I've been friends with a couple of perennial 'hero engineers', as opposed to people pushed into that by a specific crisis. By and large, they like working that way, and would be very unhappy to swap into 'normal' roles. That's a useful trait! It's just squandered by a career of 12+ hour days and random priority shifts. (More broadly, I think healthy insight that software doesn't come from lone geniuses often neglects the value of those people and tries to reduce them to line programmers. Roles like hero engineer, guru, or hermit hacker can be perfectly useful in a business - just not as ways to produce day-to-day features in a larger project.) What's the alternative? Some of them have become excellent managers, using the same resourcing and firefighting skills more proactively. Others have ended up as sort of 'internal contractors', doing hero engineer work with a few key changes. In particular: time off and/or not working long hours between crunches, setting priorities by importance rather than convenience, making their role clearly distinct from 'normal' engineering expectations, ensuring teams understand and have a say in changes, and recognizing that this is the 'unhappy path' for projects to take. It generally seems to work best for companies doing things like selling customized software platforms, since they have many different 1-6 month projects going with independent schedules and shared domain knowledge. In practice, this looks something like: a projects falls behind or gets new requirements, an extra engineer (or several) are brought in, they work long hours getting up to speed and helping solve problems, once things are stable they spend some normal-length days with the team on training and tech debt to avoid 'owning' the result, then take some time off before the next cycle.

MBCook 7y ago

Hero seems like the wrong term. Why not call them a workaholic? Whether they choose to put in that many hours or the company asks them and they comply... isn’t that what’s going on?

valbaca 7y ago
"Martyr" is probably more apt.

yeahitslikethat 7y ago

This is practically impossible advice. Hero engineers can't stand sitting back watching things fail because no one else on the team cares enough to succeed. For the hero, either the project succeeds or fails. Step up! But non heros instead look for a target to blame and then proceed to sabotage that person and the project to ensure they don't get the blame themselves. Their job is to find ways to work as little as possible. The hero's job is a successful project. If it fails the hero is to blame. At the end of the day, it's always the engineers' fault if it fails. I can't believe this article blames the problems on those who step up to fix them. Better just to ignore the problems? Reminds me of the folks who say, "don't work so hard! You're making the rest of us look bad! "

deleted 7y ago
[deleted]
t0mbstone 7y ago
No, the article is about the fact that when "heroes" stand up and "save" a poorly managed project, it creates a negative feedback loop that validates the poor management style and lack of planning. The "hero" also devalues themselves and their teammates by allowing management to abuse them and violate everyone's work-life balance. If this behavior is not nipped in the bud, it creates a toxic culture where projects are always being planned poorly, management's expectations are always misaligned with reality, and all of the engineers are burned out.
- rubin55 7y ago
  Right, the issue here is that 1: a project is poorly managed and 2: that an individual decided to take up the banner and by sheer force of will (however unreasonable) "saves the project". I would say that if 1 is the case, then 2 might not be the best way to deal with it, but: What if a project is not particularly poorly managed? What if you simply have an ambitious deadline that the team as a whole tries to make, whereby different individuals probably perform differently? Is the "hero" or heroes, defined implicitly (in the article) by a higher pace, still to blame for a "toxic culture" as you call it? While you go ahead and nip that in the bud and make sure your teams are as average as possible, I'd go work somewhere where going the extra mile is actually appreciated.

grayed-down 7y ago

On some teams I've managed, I have had that one developer that's a great producer, but projected a great deal of negative energy into the group. This situation has to be dealt with as soon as it's recognized. Some of the actions I have resorted to is heavy "counseling", work from home, rent a small office separate from the main work space or bite the bullet and fire them.

hashkb 7y ago

I have been relied upon by management for quick fixes, breadth of familiarity with company systems, urgent code review of critical features nobody heard about until now, etc. * "hero" is a ridiculous word, we never feel like heroes and nobody treats us that way. we feel dirty and abused * of course it's a management problem, everything is, recognizing management problems is not part of the path to fixing them * the only thing management respects is hitting (arbitrary) deadlines, ergo that's our actual job Trying to leverage my position as a bottleneck to effect process change has ALWAYS resulted in a deteriorating relationship with executives. Maybe I'm not the most tactful guy, sure. But EOD it's their company. Just quit.

rubin55 7y ago

This article annoyed the hell out of me.. "Kill your heroes?", "Heroes can be deadly to team culture?" First off all, there can be many reasons why a project is late: bad time estimations, bad resource capability estimations, feature creep, to name a few. There can also be a whole list of things you can do about that: Revisit those time estimations, cue in time for training and education to better tacke the problems at hand, better scoping, and of course: the choice to work harder. The last option above should in all cases be a choice, not something that's forced on anyone, but if it's a choice, something that makes the individual happy, a challenge to tackle, then by all means, go for it and the team should be the better + happy for it. Of course this also means that one can not expect/force it on anyone. If I have a 6 person team and two people decide it's a good challenge to try and make the deadline, that does not mean the rest of the team are slackers; it also doesn't mean that those two are "heroes that need to retire their capes". When an individual decides to work harder, to reach a goal (or when the default pace of the individual happens to be higher in the first place), does that suddenly make the person or the practice toxic to the team (or "deadly" as the headline calls it)? What the article implies is that when a person tries (intentionally or not) to stand out from the group, it's bad for the group and bad for the person. This implication is highly alarming to anyone who would want to do his best to stand out, to be a better programmer than you were last week. A team is not a box that demands the average from each individual and punishes the one that stands out but a group of dynamic and different individuals that, through their differences achieve greatness.

t0mbstone 7y ago
Found the hero engineer
saltcured 7y ago
Aside from the hyperbolic "Kill your heroes" heading, the whole article is about management error. It doesn't even advocate firing the hero if they emerge, just recognition of this emergence as a warning signal that things are going wrong for the organization. I think the topic of the article is analogous to a military situation familiar from pop culture and current events. Let's focus on the human dynamics and ignore any technical baggage that might confuse the issue with 10x or rockstar developers and such. You can have regular infantry and special forces. The pathological situation would be expecting special forces levels of performance out of an infantry group, embedding a few special members to magically elevate them. It will deteriorate morale for all involved and produce unpredictable results, since they do not have the training and methods to work together effectively. But, don't get distracted into thinking that this argues that no regular infantry can be heroic. It's a metaphor, not a moral judgment. If properly managed, special units would have different missions which might complement the regular units. The special unit members are held to higher standards and still must cooperate. Self-serving cowboys typically get washed out, as the special teams demand high unit cohesion in order to accomplish their missions. But, the special team can excel together, not being limited by the roles, capabilities, and methods of a regular unit. It is not good for one member to try to stand apart from his unit. He can mentor and motivate from within, but members of the unit need to be able to rely on each other and to some degree substitute for each other. It would be a mistake to let him try to create his own special grade informally within the regular group, lacking the proper logistics and management support for that role. Another failure mode, not discussed in the article, is when an organization tries to be "all special". Lacking missions aligned to their preparation, they will eventually lose their skills and morale. They will start to perform unpredictably as they lose cohesion and focus. Also, in an attempt to grow a large special force, you would eventually run into supply problems and lower your entry or retention standards. Then, you might end up with forces special in name only, returning to the original scenario with a general infantry with some special members embedded in a toxic brew.

sys_64738 7y ago

Heroes exist due to incompetent management. Rule one of management is reduce risk and having a single developer fail the bus test is always management's fault.

folkhack 7y ago
> Heroes exist due to incompetent management. Yep - in the article incompetent management was laid out pretty clear: * The project is 3 months late * but he also wants you to finish your colleague’s project * But of course the original two projects are priority. But please fix the bug because it’s important I've been the "hero engineer" and I think that this manager is totally ignoring what he's already postulated. I'm not happy if I'm on a team that's three months behind and being tasked to do other's work because they're incapable, and I'll end up with a chip on my shoulder when I'm the only producer on a team (seriously, who wouldn't?). And mostly - you're damn-straight I'm gonna leave! Why would I STAY!? This sounds like a manager who has no business in picking a team of engineers to work on a project, which IMO happens way too often. We should be whiteboarding our leadership just as much as the engineers. In the US it's a pattern of zero technical competence at the middle management level... this leads to articles like this where high-performing developers are demonized for "bad attitude" immediately after the author outlines REAL reasons anyone may be unhappy with their employment. Welcome to the new work world though - where it's about the narrative of work more than it's ever about the work.

FatDrunknStupid 7y ago

Not going to make many friends with this post but let's start with - 'all generalisations are bollocks (including this one). I'm often the guy you describe, but, I 'work' much less than other people. I think about stuff and type it in when it's ready. Fires go out, things settle down. Changes are made. I get sacked because everyone else is 'working'(read typing and bum on seat) when I'm looking out of the window.