
Don't Be A Hero - icey
http://al3x.net/2010/01/09/dont-be-a-hero.html
======
michaelcampbell
I agree with Alex here, but the reality is that companies LOVE heroes. I see
it happen over, and over again (and usually with the same people). The manager
asks the hero how long something will take, he underestimates the task,
failing to account for testing, other inevitable issues, other priorites, etc.
Manager loves the answer.

There will be inevitable issues, and things come up in limited testing, but
the hero will work stupid hours on little sleep producing crap quality, just
to get SOMETHING going, even though it's a strict subset of what was promised.
Since SOMETHING is going, and the hero casually notes that it took them heroic
effort... he gets a "spot award" or some other trinket.

Manager got the answer they wanted, the customer got SOMETHING, and the hero
got his trinket. Everyone wins.

And it will cause headaches and issues untold for many months down the road.

Meanwhile, the non-hero estimates conservatively, management hates the answer,
the customer gets a well (or at least less fragile) something later and hates
that, and our non-hero gets the stink-eye.

A manager told me long ago that customers don't want it right; the want it
broken and quickly. That way they have something to bitch about. From a
producer's standpoint, they can then bring out the hero to fix what should
never have made it out to begin with, sometimes charge for it, and look like
they're "responsive". And the customer can feel all smug that they made the
vendor/producer do their little dance.

~~~
cema
Well, that sure seems to be a manager's point of view, rather popular. But is
it always correct?

~~~
michaelcampbell
I'm not sure what you mean; is it "correct" in that what I described happens?
Yes, it is. Not every time of course, but I've seen it happen quite a lot;
probably more often than not.

If you mean, is it "correct" in that "Is this the way things should happen?"
Then I would submit, no.

But, reality always wins.

------
lmkg
My experience is that Heroes are problems because they're a) bottlenecks b)
single points of failure. Using them as a crutch exacerbates both problems.
However, having the most productive person on the team do as much as they can
do is an easy trap to fall into. When one person is working on a totally
different level from everyone else, it's probably in their interest to leave
and find a different group that they're more peer-ish with. However, Heroes
tend to become Heroes by being the self-sacrificing type, so they're not as
likely to do so.

This also reminds me of Comparative Advantage[1] from basic economic theory.
If you have to people X and Y and two tasks A and B, and X is better than Y
and both A and B, should X do A and B for himself? Turns out no. X should only
do the task they're _more_ better at, and trade Y for the other; more gets
produced, and there's a ratio of exchange such that X and Y both end up with
more A and B than they would have otherwise (see [1] for rigorous definitions
and simple maths). It's the same situation, you should be taking work away
from the Hero so they can focus on what they're awesome at, rather than giving
them more work.

[1] <http://en.wikipedia.org/wiki/Comparative_advantage>

~~~
Retric
Cool, I think I edited an early version of that page and added some tables
with numbers and a small discription. It looks much improved from how I left
it.

~~~
eru
Yeah. Even with all the bureaucracy that we like to fret about --- Wikipedia
still works for most pages.

------
johnl
I agree with a hero being "dangerous" but I would say you should be looking at
the manager as the problem, not the employee. If one employee is doing all the
work it is because the manager or his manager is letting it happen.

------
gfodor
You usually need a "hero" to get an idea off the ground. At some point during
discussions about a new project the time comes to buckle down and actually get
some shit done. I've found it's often necessary for a small burst of Herculean
effort in the beginning by one, maybe two, people.

Then, after the initial burst, you can start forking things off and spreading
the knowledge around. The trick is finding these hero/wizards who care enough
to perform the burst but have small enough egos to share the reigns later with
others.

~~~
gscott
Those people who didn't want to do it in the first place are not going to be
exactly jumping out of there seats to pitch in and firm whatever was created
up and finish it out. Wish that were the case but I believe people want to see
the hero fail. Eventually the hero gets tired of never ending uphill climb and
leaves.

------
bootload
_"... If you’re playing the hero, or if you have a hero on your team, it’s
probably time for a serious talk with your coworkers and manager. ..."_

Manager?

 _"... You shouldn’t be getting paged at all hours. Sure, you might need to do
some occasional planned after-hours maintenance, or some very occasional
unplanned-but-process-driven disaster recovery, but you shouldn’t need a hero.
..."_

When you hear this you know your working in an established business or
corporate land. I know this is what you should aim for, but I've yet to work
or see a Startup that works so well it doesn't require this kind of
intervention.

~~~
jfarmer
It should only require that kind of intervention once (per type of incident),
and if it's a regular thing then it points to a more fundamental problem.

~~~
bootload
_"... It should only require that kind of intervention once (per type of
incident)... points to a more fundamental problem. ..."_

That's a better way to phrase it. I'd agree with that.

------
tristan_juricek
From another perspective, I left my last company because I felt the tension to
become the hero.

What's interesting is that there was another person who was also kind of
playing the hero role - but didn't quite have the development talent to make
the big contributions. Man, it destroyed the team culture between the boss and
the devs. It wasn't just that he "enabled mediocrity". He was seen as "being
mature" and "really cared". And the other devs saw his flaws rather than his
benefits. The devs began to roll their eyes when the boss talked about
"caring". Once this happens, it's an awfully hard ship to turn around.

------
clueless123
Given identical situations, average management will always take the
cheapest/shortest option. regardless of quality.

The quick fix in the middle of the night just takes attention form a serious
issue and delays it's repair till it later again becomes serious enough to
need managements attention.

A real hero will be professional enough to stop the presses, call attention to
the problem and assure it gets fixed once for all.

Using the "Technical Debt" analogy, a heroic solution is no more than
borrowing money from a loan shark at horrendous interest to pay todays due
mortgage.

------
koevet
Another negative aspect of a team relying on The Hero is the "knowledge black-
hole" effect. The Hero writes a lot of code, often poorly documented, and
builds these fragile cathedrals in his mind. Then suddenly he leaves the
company/gets sick/etc. and the undocumented, full of scary TODO/FIXME codebase
stays behind. The rest of the team is afraid of touching it and the cathedral
eventually crashes.

------
sreitshamer
Agree with Alex that heroism needs to be valued in the right way. When looking
for a programming job, figuring out whether the manager values heroism in the
right way is a great way of figuring whether they understand and value quality
people and quality work. Many managers can't tell a good programmer from a bad
one.

------
mattwdelong
I think Alex just described someone who should start their own startup.

Founder: A motivated workhorse, eager to please the manager; of course, the
manager being the customer.

