Hero or Zero: Why 10x Developers Can Derail Development Teams (And What To Do About It)
What do you think of when you hear the word “hero”?
Many would think of a hero as a cape-wearing super-powered savior tasked with rescuing the world from certain doom, or someone who storms a castle, slays the dragon, and goes home to a glorious fanfare of victory.
We have “heroes” in software development too. If you’ve been on a team for any length of time, they’re easy to spot. They’re often the most knowledgeable member of the team, as they don’t tend to change teams very often. They’re also often the first ones to respond to problems that pop up, or new requirements delivered to the team. They may or may not be the one who is responsible for leading the team on paper — in fact, in my experience, about half were official leads, while the other half were the people to whom leads would look for advice. Some in the industry would refer to these folks as “10x developers” — folks who can output at 10x the rate of a “typical” developer.
During my nearly two-decade tenure in software development, I’ve been in situations with many incredibly intelligent individuals on a variety of development teams. Sometimes when a complex requirement came our way, a “hero” would claim ownership of that story, immediately dash off to hole up a room far away from our noisy open office workspace, and develop the solution in a vacuum at a lightning-fast clip.
Things would usually be fine for a few months until, for whatever reason, excrement hit the fan. An alert would be triggered and, inevitably, that particular section of code implemented by the hero a while back would end up in the triage path. Under pressure, other members of the development team could not figure out exactly how it worked without the hero’s help, causing resolution of the problem to take much longer than necessary. Sometimes the section of code in question dealt with complex multithreaded blocks of functionality or unusual interactions between microservices. Other times the issue stemmed from critical business logic to which our “hero” was privy due to his/her participation in meetings as the team’s sole representative where the desired behavior of that logic was discussed in depth. I should emphasize that the problem that occurred might have absolutely nothing to do with the hero’s implementation at all! It could have been an issue related to operations or infrastructure (this was often the case)…but regardless, the problem was incredibly difficult and stressful to diagnose until and unless the hero charged in to save the day.
The commonality is that even though progress is achieved in the short term by the speedy implementation of stories courtesy of a “hero”, all of that progress can be undone quickly when it counts and the rest of the team is on the phone trying to resolve an issue with a critical commerce API and the “hero” is MIA. Potentially millions of dollars down the drain.
That’s not to say that 10x developer “heroes” don’t improve teams and supercharge development, but it’s their tendency to jump into action that serves as both their biggest strength and their biggest weakness. Heroes will jump at the first sign of trouble. Any slight hint of a dragon attack and they’re already on their way out the door, sword and crossbow in hand. They often have an insatiable appetite for problem solving and are the first ones to tackle anything that pops on the team’s radar, everything else be damned. I’m reminded of a certain somewhat quirky canine from a Pixar movie a few years back…
This tendency to code first and ask questions later can derail an Agile team too, because tracking work becomes difficult if the “hero” is running around picking up everything that ends up on the team’s radar without taking it through the team’s prioritization process.
Managing a “hero” developer’s career is extremely challenging — as a manager, you certainly want to keep them technically engaged enough to keep them around, while at the same time encouraging them to share their expertise with others. Sharing knowledge is something they may or may not be willing to do — some “heroes” love going outside the kingdom to teach the art of dragon-slaying, while others prefer to only deal with the dragons residing in their own castle’s backyard. Besides, talking takes up valuable coding (or dragon-slaying) time, so getting a hero to share their tips and techniques with the larger team can be harder than it sounds…
Mob Programming
Mob programming is one way of encouraging team members to share knowledge. I’m emphasizing mob programming (vs. pair programming) here for a reason — “heroes” can often dominate pairing sessions, leaving other developers unwilling or unable to significantly contribute. This can also leave a “hero” bored. Mob programming is much more interactive, and while it may frustrate “heroes” due to the somewhat slower pace compared to individual development, it shows others on the team how to slay dragons. This technique could be used sparingly for specific types of problems (namely, the complex sections of code most likely to cause trouble for those triaging issues).
Teachouts and Walkthroughs
Teachouts and walkthroughs at the code level can be useful for complex pieces of logic that the entire team should be aware of. When new critical features are introduced, it’s important that a development team understands how those features are implemented — at least well enough to manage critical support when it counts.
Coaching and Mentoring
Emphasize coaching and mentoring for willing heroes. Many “heroes” have no intention of becoming managers, and would relish in the ability to coach or mentor other developers on their teams. It may not come naturally to them, but it is the manager’s responsibility to ensure that those who participate in coaching and mentoring are rewarded for their efforts. If more rewards appear from coding in a vacuum than empowering members on their team, the “hero” is going to code in the vacuum every time. Slaying dragons is far more exciting than mock battles after all.
This is by no means an all-inclusive list. These are only some tips and tricks that I’ve seen provide some measure of success in focusing “heroes” to amplify the effectiveness of their fellow team members. The villains will still be conquered, and the product will still be delivered, hopefully by the team at large rather than a single “hero”. It takes a village after all, whether it’s building software or slaying dragons.
