Kill Your Heroes, Stop Doing it Harder

November 25, 2012. Filed under management 129 software-engineering 15

The project launch is eighteen months late, company revenue is dropping significantly, key people are leaving and being replaced by new hires. What to do? Well, work harder!

Does it work?

Of course not. Unless your problem is that people aren't trying hard, then the "work harder" mantra only breeds hero programmers whose heroic ways make it difficult for non-heroes to contribute meaningfully. Later, as your new heroes finish martyring themselves on burnout, you're left with three exceptionally challenging problems:

  1. you've bred a cadre of dissatisfied and burned out heroes,
  2. you and your heroes have alienated everyone else,
  3. your project is still totally screwed.

This is a recurring pattern that many growing companies fall into, and it also occurs to projects within larger companies. Anywhere you find managerial desperation and a hardworking team, Do It Harder may be visiting.

The Fall and Rise of a Hero

One rainy day you walk into the office and your boss wants to talk to you. He needs you to finish your project, but he also wants you to finish your coworkers project, without the coworker feeling bad about it, because your coworker is still going to own the project, you're just going to do it (along with your other work, remember).

A few weeks later, the site starts crashing every few days, and the company really needs to launch the new version of the site. The boss pops in to let you know he deeply trusts you, and needs you to take over both efforts. You're a good guy and it sounds like a good opportunity, and you're pretty sure you can do a better job than the guys already working on it, so you say yes.

Congratulations! You're a hero programmer.

You're now working on five disparate projects, trying not to piss too many people off, but you're having trouble getting everyone involved. It seems like they're not really working as hard as you are, and it's a bit of a drag, since you're pulling seventy hour weeks and getting paged every Saturday night.

The other developers are glad that you're taking a lead on the problems that were terrifying them too, but all is not well. A couple are quietly bitter because of your newly elevated status, but most just don't know how to contribute anymore, because you and your hero peers are rewriting the existing system, debugging the outages, and cherry-picking the easy wins. What's left for them to do?

Day after day, and week after week the frustration between heroes and non-heroes grows stronger, tumbling toward inevitable disaster.

Kill the Hero Programmer

When it comes to solving the hero programmer, your options are limited: either kill the environment that breeds hero programmers, or kill the hero programmer by burnout.

They're truly unmaintainable beings, as their presence limits the effectiveness of those around them in exchange for a short-term burst of productivity fueled by long hours and minimized communication costs (minimized because most other people aren't able to do much).

These long hours burn your heroes out, and then they either quit or you shove them into a corner where they'll glower at you while remembering how their hard work and critical contributions culminated in them glaring at you from that corner.

You can rehabilitate heroes, but it's touch and go from the beginning, and healing takes time. They might hate you for a while, and they probably should, because you created them with your hamfisted attempt to fix your current problem.

A Long Time Coming, A Long Time Going

One of the observations from systems thinking is that while humans are prone to interpreting events as causal, often problems are better described in terms of a series of stockpiles which grow and shrink based on incoming and outgoing flows. The Dust Bowl wasn't caused by one farmer or one year of overfarming, but by years of systemic abuse.

Stocks and flows are especially valuable in understanding project and team failure. Projects fall behind one sprint at a time. Technical debt strangles projects over months.

Projects fail slowly, fixing them takes time too.

Working at a frenetic pace for a couple weeks or a month may feel like a major outpouring of effort and energy, but it's near impossible to quickly counteract a deficit created over months of poor implementation or management choices.

If hard work and breeding heroes doesn't work, what does?

Resetting Broken Systems

Your options for addressing a broken system depend on whether you're in a position to set policy. If you set the original direction and have the leverage to change directions, then resetting is as simple as standing up and taking the bullet for the fiasco you're embroiled in.

Taking the blame is painful, and only plays well with the crowds a couple of times. After that people won't trust you to lead them towards success, which makes some sense, since at that point you've lead them off the rails multiple times. Fair's fair.

If taking the loss doesn't leave you looking shiny, at least attaining closure is healing, and the team will have the opportunity to start healing as the schedule is reset and goals are adjusted. Without the leverage to change policy–and this doesn't have to be direct authority, influence is a powerful thing–you can't start the healing, but you can help reach the reset point more quickly. (Similar to Isaac Asimov's Foundation's goal relative to accelerating and minimizing the collapse of the galatic empire in the Foundation Series.)

Without policy, your tool is stepping back and allowing the brokenness to collapse under its own weight. A deeply flawed system can't be saved by bandaids, but can easily absorb your happiness to slightly extend its viability. By stepping back you conserve your energy, avoid creating rifts by pushing others away in hero mode, and will be ready to be a part of a new–hopefully more functional–system after the reset does occur.

This is a very uncomfortable process, and if you're a hardworking, loyal person, then it probably goes deeply against your nature. It certainly goes against my nature, but I believe that this is one case where following my nature is a detriment to both myself and those around me.

Projects fail all the time, people screw up all the time. Usually it's by failing to acknowledge misteps that we exacerbate them. If we acknowledge errors quickly, and cut our losses on bad decisions before burning ourselves out, then we can learn from our mistakes and improve.

Kill your heroes and stop doing it harder. Don't trap yourself in your mistakes, learn from them and move forward.