
Hero engineers can be deadly to team culture, it's time to retire those capes - ochronus
https://ochronus.online/kill-your-heroes
======
m_fayer
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.

------
MBCook
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
"Martyr" is probably more apt.

------
rubin55
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.

~~~
saltcured
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.

~~~
rubin55
Really interesting take on it, and one I haven't considered before. Is there a
name for this "military situation"? Sounds interesting and logical, at least
from a military perspective.

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.

------
emeraldd
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
Fair point, thanks for the feedback! I'll consider moving that statement up
ahead

------
Bartweiss
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.

------
hashkb
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.

------
afarrell
General statement: The presence of a hero means something has gone terribly
wrong.

Anyone got a counter-example?

~~~
Bartweiss
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.

------
sys_64738
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
> 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.

------
grayed-down
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.

------
yeahitslikethat
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! "

~~~
t0mbstone
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
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.

~~~
laughingbovine
"Ambitious" deadline a.k.a. crunch time required to meet deadline == poorly
managed

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.

~~~
rubin55
What if you have an autonomous team that set the ambitious deadline
themselves? What if the deadline initially seemed realistic but later became
more questionable?

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?

