Hero engineers can be deadly to team culture, it's time to retire those capes
ochronus.online
ochronus.online
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.
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.
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.
The thing I'm thinking is: In the military, roles and units of soldiers/ops are very clearly defined: The purpose of the unit, the actions that individuals within the unit execute, etc. So I would imagine that special-forces calibre people would not often show up in more elementary troops and/or they'd make promotion, shift upwards/side-ways to somewhere where their skills would be a better match to the goal of the unit.
In business teams you usually have much more variance in requirements on the team, the individual members, their skills and knowledge, and oftentimes also much more variance in capabilities per team member (possibly related to the fact that the missions for these teams are not always clear-cut and the fact that the teams have to handle widely varying stuff from moment a to b). I think that for smaller businesses this variance is even higher as compared to teams in larger corporations.
Regardless, I think it is damn interesting to look at what armies do organization- and skill-wise, I've never looked at that more in-depth.
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.
* "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.
Anyone got a counter-example?
Counter-examples aren't there because these companies "good practiced" themselves into the grave.
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.
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.
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.
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! "
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.
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.
While you're working unpaid overtime, I'll go work somewhere where "work life balance" is not just something they put in the company description.
My point is, the option and choice to work harder is one of a few options that can be chosen. That choice should never be forced upon the team or individual members, but if done freely it can work out great.
And who said anything about unpaid overtime?