Script

Introduction to hero-driven development

Hero-driven development refers to a team having an over-reliance on star performers to get the job done, rather than having a stable, reproducible process in place that anyone can implement.

While it can be exciting to work in such a mode, it does not scale and will eventually lead to the burnout of the heroes in question, and a slower skills ramp-up for the remaining team members who rarely get exposed to harder topics.

In addition, heroes inevitably become knowledge bottlenecks in the team, which becomes a major problem when the heroes quit, or even just go on vacation. It is for this reason and many more that I refer to hero-driven development as an anti-pattern:

"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive." [1]

Time and again, I find myself exposed to hero-driven cultures in the technology industry, let’s look at some of the common signs next.

Common tell-tale signs

The following represent some red-flags for hero-driven behaviours in a team, but there are many others:

• Working very long hours.
• Stress.
• Applying changes to production that have not been fully tested.
• Adding more capacity to production right in the middle of a service-impacting traffic spike.
• Burnout (team members quitting, taking time off for health reasons, becoming demoralised etc.).
• Management celebrating "getting the project across the line" despite apparently insurmountable odds, AKA "hero worship".
• A lack of clarity on objectives.

A hero does well in these environments, because they are able to react quicker than those around them, and they don't mind not having a life outside of the project, at least while they are young and single. Eventually it catches up with them however, and resentment can kick in which is frankly justified.

I once worked with a brilliant principal engineer, who was so sick of fire-fighting he used the children's character "Fireman Sam" as his official company avatar, but sadly few got the joke.

Technology projects should be stable and predictable however, allowing for sensible work practices that do not burn people out, while also allowing for planning schedules that actually reflect reality. Working in a hero-driven environment can be fun for a while as the adrenaline kicks in, but a prolonged adrenaline rush will quickly result in frayed nerves.

The problems with heroes

Staking your future on heroes is a high-risk/high-reward endeavour. While the rewards are quite obvious, the risks are less so and require some explanation. Let's look at some of the common risk factors:

• Heroes are expensive - they are highly-skilled subject matter experts, and as the best and the brightest in your teams, they command the highest packages if you are serious about retaining them.
• Heroes can burn out and quit - because being a full-time hero is exhausting. As a manager, we need to keep a very close eye on this to ensure that the workloads remain reasonable, and you may have to ring-fence your heroes to protect them from undue external pressure.
  • Heroes are in-demand - therefore, they are highly-likely to get head-hunted.
  • Heroes have egos - while not universally true, some heroes have big egos and must be managed accordingly. If you take a young engineer, place them on a pedestal by constantly telling them how brilliant they are, you may end up creating a monster so you must be careful.
  • Heroes don't know how to say no - in general I found found this to be true during my career: the best engineers don't know how to reject work, and will happily drop their current task to take on unplanned work when someone asks them for help. It's one of the aspects that makes them a hero in the first place: they love helping people with their problems. As a manager, in this instance you may have to protect the hero in question from themselves, by saying "no" on their behalf.
  • Heroes are bad at giving estimates - again this is a generalisation based upon my own experience, but as heroes tend to be proactive optimists, with a great "can-do" attitude, they tend to underestimate the amount of effort required to carry out complicated tasks. Heroes see solutions, not problems, which means they can have a blind spot where unforeseen problems can blow out their estimates.
  • Heroes don't scale - while it might be tempting to think you can have a team packed full of heroes, just like the Avengers, it is not possible to do this as heroes exist in small numbers globally, and having more than one in a single team can be problematic due to ego conflicts. In general when building a brand new team, I like to hire the hero firstly to lead the team, then empower them to hire their mid-level and junior team-mates. Put the heroes on the most challenging tasks, and the remaining work can be carried out by the bulk of your team members.

The problems with being a hero

If you are a hero, you probably already know by now that being a hero in a dysfunctional organisation sucks. You spend your day constantly fire-fighting, with new problems being presented to you left and right, while your regular project work suffers.

I once said to a team of talented French engineers I managed: "If you are the only one that knows how to bake baguettes, that sucks for you because everyone will come to your desk for bread. It's better to teach others how to bake baguettes". That's the secret to getting heroes to scale: they need to nurture other heroes in the team, but sadly most don't do that, as they are too busy just fixing stuff directly.

Remember if you are a known hero in your organisation, everyone is going to keep coming to you with their problems to solve, until you either burn out through exhaustion, or you train them to fix it for themselves.

For managers, remember once again to ring-fence your heroes by for example ensuring that all ad-hoc requests for their time are made through you, to give you the ability to make priority calls on their behalf. To use an analogy, your top engineer should not be busy fixing someone's printer.

Conclusion

I once knew a senior business analyst who told me early in my career that "many organisations strive to shoot from the hip more effectively". These organisations are perpetually stuck in tactical, reactive mode, and rarely have time for strategic planning as they are just too busy getting things done. Sadly, those things getting done are often the wrongs things, due to a lack of careful planning in the first place. It becomes a vicious circle.

Hero-driven development is an anti-pattern: remember if you need a hero, something has already gone wrong.

Wrap-up:

Lets recap what we have covered today:

1. Hero-driven development refers to a team having an over-reliance on star performers to get the job done, rather than having a stable, reproducible process in place that anyone can implement.
2. While hero-driven development might be fun in the beginning when the adrenaline is flowing, it will burnout the heroes in question over time and is therefore not sustainable.
3. Put simply, hero-driven development is an anti-pattern and should be avoided.
4. There are many warning signs for this anti-pattern, and as a leader you need to watch out for these.
5. Heroes work well in a chaotic environment, for example at a start-up, but as a leader you need to ensure such chaotic environments stabilize over time.
6. Heroes are great fire-fighters, but it is much better to prevent fires in the first place.
7. To prevent such fires from occurring in the first place, technology projects should be stable and predictable. Predictable, realistic delivery goals is the safe objective.
8. There are many problems with heroes that you need to be mindful of, for example:
   1. They are expensive.
   2. They can burn out and quit.
   3. They can be head-hunted out of your team.
   4. They can have big egos, and cause friction in your team.
   5. They struggle to say no to new requests.
   6. Their estimates are often too optimistic.
9. Fundamentally, the biggest issue with the hero-driven anti-pattern is that it does not scale: you cannot build a whole organisation exclusively full of heroes.
10. Being a hero long-term sucks, because everyone will come to you with every fire that they want you to put out. If you are a hero, learn to knowledge-transfer and delegate as much as you can.

I hope you enjoyed this episode, and I look forward to covering the next topic in this series with you! In the interim if you want to follow me online, you can find my blog at TechLeader.pro, or follow me on Twitter @TechLeaderPro.

Thanks for your time, take care and have a great week!

References

[1]: Wikipedia entry on "Anti-pattern" - https://en.wikipedia.org/wiki/Anti-pattern

[2] : My original 2013 blog post on "Hero driven development" - https://techleader.pro/a/423-Hero-driven-development

Download

techleaderpro-episode-17.mp3

File details: 15.4 MB MP3, 10 mins 41 secs duration.

Title music is "Still Cold" by Crystal Shards, licensed via www.epidemicsound.com

Subscribe

Apple Podcasts (iTunes)

Spotify

Google Podcasts

Amazon Music

Main RSS feed

Sponsor

Five.Today is a highly-secure personal productivity application designed to help you to manage your priorities more effectively, by focusing on your five most important tasks you need to achieve each day.

Our goal is to help you to keep track of all your tasks, notes and journals in one beautifully simple place, which is highly secure via end-to-end encryption. Visit the URL Five.Today to sign up for free!