False Heroes

We’ve all worked with developers who prefers to get on with their coding alone. They’ll assign themselves a large set of tasks, tell everybody they’ve got loads to be getting on with, put their headphones in and you won’t hear from them for several days.

They might pin their name to a key change or issue, make all the required decisions alone and get it ready for deployment in record time. They may even be able to resolve complex issues with infrastructure or libraries, but not have the time to share those processes.

You likely know these type of developers by the names Ninjas, Wizards, Rock Stars, or 10x. These are terms of endearment used in praise of the activities above, or even in job advertisements looking to recruit developers with these habits.

What these behaviours actually do to your development team could not be further from a positive outcome.

Don’t get me wrong, the short term progress can be impressive. So impressive in fact that managers, and often less experienced team members won’t be able to help but praise our False Hero. Speed is always seen as a good thing in a word of complexity and deadlines. Solo progress without the need for peer input is often seen as something to aspire to.

But I’ve seen enough of these behaviours to know that these team members are actually False Heroes. They’re completely unaware of the damage they’re doing to longer term success.

They encourage the same behaviour from others around them. In a team this will lead to various negative habits, including code ownership, silos of awareness, single person decision making, and deployment without code interrogation.

If any member of a development team tends towards solo working the majority of their time, it’s a sign something in the team isn’t optimal.

The habits of a False Hero can be the result of various environmental factors, but more often than not it’s the praise of speed over quality, and the power that ownership of knowledge gives you in a team with a negative culture.

Speed-over-quality is praised where those who manage the team, or judge individual’s work don’t have enough awareness of the complexities of software development. They don’t always buy into the fact that the side-effect of more speed in an immature team is almost always reduced quality.

Power in knowledge ownership comes in teams where individual’s feeling safe isn’t prioritised. Mistakes are seen as a blame opportunity rather than one for learning. People are made to feel their job is at risk if they don’t live up to expectations and thrive, but without any of the necessary support.

So what should you do when you have one or more False Heroes in a team?

Well, start with encouraging group working methods. Pair coding, code reviews and mob programming will all result in better outcomes over time.

Contrary to what many think, these aren’t expensive methods of development when you factor in risk, quality and future velocity.

A mentor or coach as part of the team can be used as a hub for positive language and encourager of kindness, and a default of encouraging behaviours.

At the same time these team members need to know it’s a safe place to be when you aren’t showing individual brilliance constantly, or the owner of knowledge that nobody else in the team has.

Two great places to start are safety as a primary aspect of culture, and praise for team progress over that of individuals.

I’ll write more about those topics in the future. Let me know how you get on in your teams.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.