The Problem with Internal Superheroes

This article was originally published here.

On the surface of it, the idea of an internal superhero seems like a great notion for any business. At one time or another, we’ve all found ourselves pulling our hair out while our co-workers flap around like headless chickens, as we try in vain to save a project that has gone wildly off the rails. In those situations, many of us find ourselves wishing and praying for someone, anyone, to step in and save the day. Someone who understands the workflow and systems inside-out, and who is able to pull off those seemingly miraculous feats of software engineering even when time constraints are at their tightest. Someone you can turn to in a bind and know that they will be able to fix any issue.

The Internal Superhero

These individuals, who we often mistakenly view as being the jewels in a crown when it comes to software development teams, can be an absolute godsend in an emergency. The problem is, we all too often start to view the internal superhero not just as someone to be called upon in times of crisis, but as the only person we can call on. This level of responsibility on one person’s shoulders does not establish a sustainable way of working.

Any sports fans out there will be familiar with the concept of a star player, the player who is integral to the success of the entire team. The star player, just like the internal superhero, should not be achieving results in isolation. They are still part of a team, they don’t walk onto the pitch or field on their own, just as the internal superhero is supported by the other developers around them.

However, in both cases, while it can appear from the outside that this key individual is helping to achieve a more productive environment, an over-reliance on this single individual puts the success of the entire team in jeopardy. What happens if they should be out of the game for any reason at a critical point? Play doesn’t just stop for everyone else.

Bottlenecks and Constraints

It’s easy to assume that by offloading as many tasks as possible to the internal superhero, dramatic improvements will be made in terms of efficiency. In reality, what tends to happen is that the internal superhero finds themselves inundated with work. No matter how good at software development one person is, they are still only one individual. There are limits to what all of us can do by ourselves and within a set amount of time.

Bottlenecks and constraints are the banes of any software development team. They both inevitably lead to backlogs. If you are relying on your internal superhero to clear this work alone, you may as well be handing them a sieve and asking them to bail all the water out of a sinking ship. As soon as they get a task done, two will no doubt have been added to the backlog.

The internal superhero can definitely help to improve the efficiency of a software development team, but only if they are being utilized the right way. Often it can seem that these individuals are masters of all trades. But these guys are only human, like the rest of us. They will have their own unique strengths and weaknesses. It is much more effective to identify your internal hero’s strengths and encourage them to share knowledge with others to improve the whole team’s understanding of all the systems and processes involved.

There’s nothing wrong with delegating the occasional task to them when you need to, but don’t fall into the trap of making them responsible for everything.

(For more on identifying bottlenecks in your development pipeline, be sure to read our post on the Theory of Constraints.)

Overreliance

The other big disadvantage of being dependent upon a single ‘superhero’ is that, should that individual become sick, even for a day, it can throw your entire workflow into chaos if anything happens. In the book “The Phoenix Project,” the author uses the example of Brent. We all know a Brent, they are a part of every software development team. Brent is the guy in the team who is seemingly able to do everything. Not only is he able to do everything, he is all too happy to do it.

Of course, any software developer would be proud to be thought of as being a Brent. Who wouldn’t want the accolade of being able to head off just about any of the many potential problems that software developers commonly face? The problem is, in the long run, this situation is only going to create more stress for everyone. Brent is under the constant pressure of having to fend off any difficulties the team faces. If he is unavailable, or just having a bad day, other people are going to have to pick up the slack.

The risk of relying on one individual to handle multiple aspects of development is that they will inevitably develop their own workflow and way of organizing. When other members of the team are suddenly thrust into the breach, they won’t know ‘Brent’s’ way of doing things. This means they will have to spend time devising their own workflow and finding a way of coordinating with one another before they can get stuck into the real work.

Burnout

As well as the effects that the internal superhero can have on the team as a cohesive unit, being a superhero can also have personal long-term implications. If your internal superhero ends up suffering from burnout, their performance can slip and they can even become the cause of mistakes. Even if they are able to continue working through their burnout, they may well struggle to keep up with the expected pace which will impact the system and overall productivity. This is when the problem of overreliance becomes very clear.

A Team of Heroes

It’s all very well grounding your internal superhero by pinning their cape to the floor, but it’s important to begin establishing solutions soon to defeat your overreliance long-term. Start by turning your superhero into a supermentor. Stripping a superhero of responsibility is just going to demoralize the individual in question and isn’t the best use of a great mind. The key is to redirect all their knowledge and system insights in a productive manner. The following tactics will encourage a spread of information and learning with the whole team:

• Prompt learning: If an issue fix is required, ensure the superhero teams up with other individuals and guides them through the disaster recovery scenario rather than fixing the problem by themselves.
• Documentation: Establish a routine of holding blameless post-mortems following technical incidents in which the root of the issue and the post-recovery steps are all recorded and shared across the company for organizational learning.
• Peer programming partnerships: Pair your superhero with other individuals on a routine basis to use this peer review system. The process involves a “driver” engineer writing code and a “navigator/observer” inspecting the code as it’s being written. This collaboration promotes ad-hoc training, knowledge sharing, and skill distribution as well as quality control at source rather than at the end of the value stream.
• Knowledge transfers: Whether this is in the form of game days to “rehearse failures” with your superhero acting in guidance capacity only (rather than the usual leading role) or training sessions, it’s critical to support a culture of ongoing learning for everyone involved on the team. Build a team of heroes through skill-sharing and collaboration and stop the overreliance on any one individual.

On the surface, an internal superhero might seem like a valuable addition to any software development team. However, long-term, they tend to throw up more problems than they solve. Identify your internal superheroes and start to shift the weight of responsibility. Encourage a culture of documentation, shared knowledge, and ongoing learning to make your whole team a collective of superheroes instead.

Caylent offers DevOps-as-a-Service to high growth companies looking for help with microservices, containers, cloud infrastructure, and CI/CD deployments. Our managed and consulting services are a more cost-effective option than hiring in-house and we scale as your team and company grow. Check out some of the use cases and learn how we work with clients by visiting our DevOps-as-a-Service offering.