Are you the best developer, or the lead developer?

Like a few people I’ve seen Avengers:Infinity War. Actually twice. But this post is nothing to do with Infinity War. Whilst watching one of the scenes on Nidavellir I was reminded of a line from Thor: Ragnarok:

What are you, Thor, god of hammers?

The context of this conversation is Odin’s pending death, and the revelation that Thor has an older sister Hela, whom he must defeat. However at this point Thor’s hammer Mjolnir has been destroyed. So what, you may ask, does this have to do with leading development teams?

On the face of it, not an awful lot. Thor has become reliant on Mjolnir to resolve all of the problems, all of the time. He has forgotten that he is the god of thunder, and that Mjolnir is but one tool at his disposal.

Becoming the Lead or Principal

In working your way up to become the team lead/principal it is likely that your managers have come to rely on you, at least in some part. Part of the reason you have been elevated is that you create solutions quickly and effectively, and you have good knowledge of the systems in your care.

But what happens when the team is in a sticky situation?

The temptation to revert to what you were doing before your promotion will be strong. Additionally the pressure from management to revert to that quick problem solving, solution creation behaviour will also be strong. But is that the right thing to do?

You don’t have to be the team’s Mjolnir

Unless you’re in a team of one or two, many of the responsibilities that you inherited at the point of promotion are around enabling your team to perform to the best of their abilities. But if you swoop in and save the day any time that there is an issue then, by definition, you aren’t allowing your team to perform to the best of their abilities. Now or in the future.

One of the key jobs of any team lead/principal is to help your team grow their knowledge. This isn’t just out-and-out technical knowledge, but also understanding of the business that is making use of that knowledge. By coming in and fixing all of the problems you are denying your team crucial opportunities to grow.

Sure it’s likely at first that problems will take a little longer to fix. Also it’s entirely probable that problems won’t be approached in the way that you would approach them, or fixed in the way that you would fix them. But as long as the team is fixing the issues and learning does this matter?

If the team are struggling with an issue then that is the time for you to do your job, mentor your team, offer insight based on your experience. But try and avoid dictating solutions, as this is probably the least effective way for your team to learn.

Sometimes you need a hammer to hit a nail

Once in a while it will be necessary for you to get your hands dirty fixing something, there aren’t enough people around, it’s Christmas day. When this happens the trick is to share the knowledge with the team, and try to ensure that it doesn’t happen again.