The dark side of devotion

In many of the projects I've worked on, there's been a skilled and respected developer that knows close to everything there is to know about the project. The original requirements, the twists and turns along the way, and every in and out of the code base.

He or she might not be the most skilled coder on the team, but when it comes to devotion, dedication, and sense of responsibility for the application, he is surpassed by no-one.

This person is usually one of the original developers, and it's common that the management rewards all this amassed wisdom and devotion with a lead role, formal or informal.

For you as the manager responsible for the team, this probably sounds like a great arrangement.

I mean, with the application development being led and guided by someone who is more or less the Gandalf of your project, what could go wrong?

Just imagine:

All current and future development would produce a minimum of regressions and technical debt; since Project Gandalf's all-surpassing knowledge and sense of responsibility would spread to all the other developers on the team. Productivity would skyrocket, as would customer satisfaction and sales, paving the way to prosperity and total market domination.

In reality, things tend to be a little more complex. And even positive traits can have unexpected side effects.

For instance, what is most likely to happen if Project Gandalf (let's call him PG for simplicity) is:

• incredibly helpful and loves to help his peers out whenever they get stuck (the green-grass-and-unicorns-scenario above)
• a genius who works best alone
• a perfectionist with extremely high standards and expectations that no-one can live up to
• super busy, since everyone needs access to that knowledge and skill set

Let's examine those traits and conditions in order and see what they imply.

The helpful mentor

Usually, the team loves this guy. Solid as a rock, he's always there to help. But let's face it: people, in general, are prone to take the path of least resistance. And when PG is just a Slack message away, it can be tempting to ask for help instead of trying to figure things out by oneself first.

This behavior effectively makes PG a crutch for the whole team to lean on, which puts you as manager in a vulnerable position. What happens if PG gets a job offer he can't resist? Will the rest of the team fill his shoes? Will they be able to deliver during the transition phase?

The lone wolf genius

The genius PG often acts as he's still the sole developer of the project. He is probably the most dedicated and productive developer you will ever have on your team, but the downsides are plenty.

Since the application is PG's baby, it's not that uncommon that he claims the most exciting development for himself, leaving the less attractive parts to the rest of the team.

This situation can be tricky to recognize. After all, PG is the man with the vision, so it seems logical to let him handle the advanced stuff. Same goes for new ideas and brainstorming: PG's ideas can often appear more feasible than the ones of his peers.

If you fail to address this, it will eventually create a lot of tension in the team. People don't like to be sidelined, so don't be surprised if your retention suddenly starts to go through the roof.

Also, given PG's skill level, he is probably fond of using advanced and sophisticated solutions – which can be virtually impenetrable for a junior developer.

This competence gap often results in misunderstandings and incorrect use of the code, and it's common that simpler, redundant solutions start the emerge on the side as a result.

Code bases like this are a nightmare to navigate and maintain, not to mention the impact they have on the onboarding of new developers.

The perfectionist

High standards is yet another seemingly doubtless positive trait. On the surface, it sounds great: PG enforces that the application gets built homogeneously and that everyone follows the coding standards and best practices.

But as they say: with great powers come great responsibility. It is all too easy to fall into the ego trap and subconsciously dismiss all code that doesn't look like your own as being of inferior quality.

And when this false sense of quality responsibility goes too far, all sorts of nasty things start to happen. From pull requests that never get approved (due to nit-picking over variable naming) to never-ending discussions over best practices (which, for some reason, tend to align with PG's way of doing stuff), to outright obstruction.

In short, this type of behavior can effectively neuter peoples' motivation, creativity, and productivity. And with most communication happening in written form, alas being susceptible to misunderstandings, it can get real ugly real fast.

The absent hero

No matter if PG is a helpful soul or not, his skill set and knowledge will put him in high demand all over your company.

This situation will give him little to no time to help out with the small stuff, leaving his peers to their own devices when they get stuck.

The good thing about this is that it forces people to start digging themselves. And with a code base in decent shape, you might as well end up with a couple of new PGs on your team as a result.

Then what about the downside? Well, just as with the genius personality type, PG's absence might as well lead to technical debt, when junior developers are creating redundant solutions or taking shortcuts.

In conclusion

If you are lucky to have a Project Gandalf on your team, make sure that you give him or her enough space to thrive, but not at the expense of the other team members. 

Be wary of overly complicated solutions (unless warranted) and be very sensible about team dynamics. Is it ok to ask for help? Do people receive the guidance they need? Are people too prone to ask for support? Are the quality requirements reasonable?

And most important: have you unintentionally created an A-team and a B-team within your team?

Pay attention to the vibe and atmosphere in the team, as well as general gossip. Make sure that knowledge sharing is happening and that everyone gets recognized.