What if I'm a better developer than my Team Leader?

Question

Based on his daily commits, I see that he writes lots of bad code and doesn't follow any good practices.

I tried talking to him about better ways of writing code like SOLID, DRY, etc (tried to be as friendly as possible), and I'm always reviewing junior devs' code but it feels like it's a lost battle because for every line of code I refactor there will be 10 new ones and there is no accountability for bad code.

I don't expect the junior devs on the team to know about good practices so I can't blame them but the team leader should know, right?

So what if I'm a better developer than my Team Leader? Would it be recommended if to try "take his place" as a team leader? If so, what approaches would be effective?

Answer 1

A common mistake in engineering is that "the team lead has to be the best and if they're not I can haz they're burger".

Sadly, the term is "team lead", not "best developer".

Think of it like this - Abraham Lincoln lead the Civil War, but he was not a general, nor a great fighter. Steve Jobs led Apple, but he was not a great engineer.

Leadership isn't about being the best - it's about inspiring others to follow you, about guiding a ship that has many, many moving parts - some of which want to go the wrong way, some of which want to replace the leader! - to the end destination.

Just because you're a competent engineer will not make you a good engineering manager, nor even a team lead. If you cannot convince your team lead to follow best practices, then what hope do you have of leading?

And what joy would you get from imposing this view? Do you even know why SOLID and DRY are good? Are you aware that in Clean Coding, Robert Martin pines for the days of cut and paste code? Just knowing, and using, a principle isn't enough to convince others why it's good. Maybe doing that makes the development time shorter, or maybe your team lead is of the (sensible) opinion that code cut and paste a few times is much more simple and easier to handle than a sprawling factory pattern beast that is combining fundamentally different business logics.

If you want to lead, then I suggest you instead setup a weekly hour long team meeting, where you walk everyone through replacing some code and discussing the implications - engineers like chatting about code, and this is a good way to get consensus. Or go read up on Agile and push something like Kanban.

But don't get into the trap that sheer skill is equivalent to leadership. It's rarely true in any other aspect of human life, it's certainly not "more true" in engineering. Why would it be?

Leadership needs a vision, and leadership needs sales. Of the two, sales is the more important. Vision might defines how successful and well remembered you'll be - but sales gets you there. There are plenty of leaders with little vision, but I'm not sure there are any who cannot sell.

Answer 2

Before I answer your questions, I believe it's important to mention that assuming you are right and you are a better developer than your team leader, that shouldn't be a problem. A team leader doesn't need to be the best developer in the team. He/she should be the best at leading, at getting out the most of each team member (developers and non-developers), at solving internal and external problems that block the team's flow and productivity, and the best at building a team, among many other things.

So, answering your questions:

Should the team leader be familiar with best practices?

In my opinion, yes, the team leader should be familiar with certain best practices. Once again, this person won't necessarily be an expert in every software development concept, but he/she should be familiar or competent with many of them.

What if I am a better developer than the team leader?

Let's take the example of a football team. The captain is not necessarily the most technical player, but he/she is the best at leading and captaining a team.

You may (or may not) be a better developer, but most likely, your team leader is better than you at doing many other things that maybe you don't even realize this person is doing.

Focus on being the best developer you can be, no matter how good or bad you are compared to your team leader.

Should I try to 'take his place' as a team leader?

I wouldn't do this, at all.

What should I do?

If you tried to be friendly and explained about better practices and still your team leader is coding in a way you don't feel comfortable with, there are not a lot of easy paths you can follow. You can try to have a more serious conversation with him, always being respectful, explaining your concerns, but I highly doubt it will go down well.

Raising this with someone up the chain is another option, and again, it will rarely work in your favour.

If the situation continues like this after you've tried talking to your manager, sometimes it's easier and more reasonable to find a team and a team leader that is in line with your way of thinking and working, rather than trying to convince many people to change or improve to match your wishes or standards.

Answer 3

I agree with the existing answers: that it need not be a problem that a team leader / development manager might not be the best developer on the team. Leadership and management ability don't necessarily have a great deal of overlap with robust software development skills.

The reason this answer differs to theirs, though, is that I think there is still a problem here:

for every line of code I refactor there will be 10 new ones

I think it's fine for a team leader to be a less-than-stellar coder if they're not doing much coding or putting themselves on the critical path (i.e. if they prioritize their leadership role over development), but it sounds as though in this case, he is.

In that case, I suggest your question isn't so much "what if I'm a better developer than my Team Leader?", as "how can I introduce best practices in the face of resistance from established/senior developers?"

That's tricky and will take patience. Code reviews are a step in the right direction, as are static analysis tools, unit tests coverage, and so on - though getting their use accepted may be a challenge. There are other answers to questions like that which would be well worth researching.

Thinking aloud, I wonder also whether your Team Leader may be feeling under pressure to keep coding in addition to leading the team. It may be that he feels he needs to be as productive as he was while "just" a coder, as well as doing his leadership role. Perhaps a perceived lack of time might be to blame for the poor quality of his check-ins; perhaps he needs more trust in his team to do the work while he takes a back seat. I don't know, but it might be worth considering the situation from his point of view - maybe even discussing it with him informally, just to sound him out ("good morning boss - so, got much on today?" might be eye-opening!). This will help to learn whether he is a poor programmer who doesn't even know it but has the authority to overrule anyone who points it out (a very difficult situation to deal with), or was once a good programmer but his leadership responsibilities mean he doesn't have time to do it properly any more, and he just needs to learn to let you and the rest of the time handle it. With a better understanding of that, your path may become clearer.

Would it be recommended if to try "take his place" as a team leader?

No.

If you see a leadership role as the next step in your career, then by all means, work towards becoming Team Leader (which may some day mean succeeding the current Team Leader, but that's somewhat less aggressive than "trying to take his place" sounds!). Personally, I'd start here.

If, OTOH, you just want to be the best developer you can be, and you have fallen into the trap of thinking that Team Leader is reward or recognition for being the best developer... focus instead on improving practices both in yourself and across the team, and leave the leadership and management to those who want to lead and manage. (That role is, or should be, a lot more about people than about coding). This might help see the difference.