How to deal with low performer team leader from a direct report perspective?

Question

Context

The development team is basically made up of three devs and the team leader. This setup is in place for about six months.

We are working using the SCRUM methodology. The main issue is that the team leader is developing way less than he should. The manager expects that a TL to code at least 50% of the time, but he is delivering as if he worked less than 20%.

Since SCRUM is about delivering as a team, we are helping the TL with his stories/tasks, but he seems to lack fundamental programming knowledge to be able to fully understand what he is doing. This means that, despite our help, it often happens that his stories are not done at the end of the sprint. Also, he keeps forgetting our explanations and comes often comes with the same questions after a couple of weeks.

I have also sent him links to online resources to "catch up", but he does not seem to ever have the time for those courses.

Many stakeholders that are integrating with our application are bypassing the TL and discussing directly with other team members, as the TL is not good at clarifying the demands either.

This situation led to significant frustration among the team members, as they perceive the situation as "unfair" and "unproductive".

The internal clients are quite unhappy that it takes more than expected to deliver some features, but there was no clear complaint about it. However, they are trying to force unrealistic deadlines (in the current setup, but that would be realistic in a setup where the TL would be able to code).

What has been tried/considered as actions

• already tried by another team member a while ago - another team member has previously worked with the same person for another project and noticed the same issues. He actually emailed their manager about the situation, the manager acknowledged but did nothing to change anything. However, now we have a different manager

• current approach - we are focusing on doing our jobs and making sure that all activities are properly logged in JIRA. This is partially working in that it is clearly visible who does most of the work in a sprint, but the frustration is still there, especially for the younger team members. Also, we are leaving only the simplest and less riskier stories to be handled by the TL.

• talk to the manager - I have tried this in a similar situation (previous company, a low performer team member), but it led to no results. I am kind of reluctant to try this approach again

We also have retros, but I think such a topic cannot be discussed during these meetings.

Personally, I am not that affected by the current situation, but other team members are.

Is there anything else I should try or just stick to the current approach until someone with enough power notices and does something?

Answer 1

If you were doing Scrum, you could bring this up in the Retrospective. Just as with a manager (see below) you should frame it as how to improve your workflow.

However, despite calling it Scrum, you are not doing Scrum. How do I know? Well, there is no lead in Scrum. People can be either the Product Owner, Scrum Master or a member of the development team. "Lead" is not a job in a Scrum team. And since you did not mention any Scrum Master, the first and most obvious person to address this with, I would conclude... you are not doing Scrum. You are just misusing the name.

So there is no other option than talking to your manager. Make sure you phrase your request as an improvement for the company and the team. For example, say "we would be a lot faster if we would focus more: the developers on developing their own tickets and the lead on interfacing with the stakeholders. The lead trying to develop takes away focus time from both of us that could be spent more productively". Assuming that this is true (don't make up lies), leave it to your manager to figure out why their lead needs more focus interfacing with the stakeholders and why they take away your focus when they develop.

Answer 2

I think as you've realised you really have two options:

1. Do nothing, put up with the current situation and hope things get better. If it's not affecting you badly, then this is certainly the easiest option short term but does run the risk of things getting worse longer term.
2. Talk to your manager - this is exactly the sort of situation managers are there to deal with, and if they don't deal with it, then they are a bad manager. It sounds like you have had a couple of bad managers, but that doesn't mean that all of them are; certainly your default assumption should be your manager is a good manager until proven otherwise.

If you do talk to your manager and nothing improves in the medium term, the option is then to go directly to your manager's manager. That is of course escalating the issue, and comes with its own risks - really only you can weigh up how that would be interpreted in your organisation.

Answer 3

To me it reads that you have two problems:
1.) Your TL is under performing, which frustrates other team members since it appears as "unfair". 2.) Internal clients are trying to force unrealistic deadlines

For 1)
This sucks, but I like to challenge you and the other team members see fairness. Is work only fair if everyone does the same amount of work? Does it matter? What should matter is that the work you do gets recognized and compensated. Don't look at what your TL is doing or not doing, look at it as an opportunity for yourself. If you leading difficult integration discussions for your team, instead of your team lead this is great for you. It can help you to step into a more senior role yourself. Make sure this is recognized in performance discussions and you get credit for it.

For 2.) This is a different problem since it makes your team look bad. But I don't think this would be any different it your TL would do his coding work at "100%" Estimating work in software development is notoriously hard and no matter how good a developer your TL is, internal clients will never know how much your team can really handle. If there is no mechanism to protect you from unrealistic deadlines now, there won't be with the team at "100%". You need to talk to your PO to add only as many as your team can handle: If you are using Story Point estimations and you delivered on average 20 points per sprint, don't put 25 in your sprint.

Make sure you raise concerns about deadlines early, and keep working the pace `you a0re doing (what other choice do you have anyways?). It is now up to the PO to manage stakeholders expectations, if they don't it is on them.

it often happens that his stories are not done at the end of the sprint.

Another thing I would suggest, is to not assign all stories to people at the beginning of the sprint. Estimate for the whole team, how much can be done in the sprint and especially don't have stories on the critical path assigned to the team lead. This will improve the predictability of your team.

Answer 4

The main issue is that the team leader is developing way less than he should.

According to who? You, or the team's manager?

The manager expects that a TL to code at least 50% of the time, but he is delivering as if he worked less than 20%.

According to who? You, or the team's manager?

The issue here comes down to one question: does the manager believe that the team lead is developing less than he should?

If yes, then this is the manager's issue to resolve, and as he is already aware of it, then nothing more is to be done. (Let's call this case "A").

If no, then there are two reasons for that.

In the first, the manager is unaware of how much the team lead is delivering, and if he were to know, he would think this is less than it should be. (Case "B").

In the second, manager is aware of how much the team lead is delivering, and is satisfied with that (or satisfied enough that nothing will change). (Case "C").

Let's examine case C first. In the work place you are going to meet people whose success confuses you. Sometimes it is because they know how to play politics, sometimes it is because they've been there a long time, but sometimes it is because you, yourself, are too junior to recognize what that senior person really does (read the second part of this answer I wrote to another question - Am I being too hasty about wanting to be recognized?).

Regardless of the reason, it is just the way it is, and to have a successful career you're going to have to learn to just accept this.

For case B, it is a bit tricky, as you might want to inform your manager. You'll need to discuss it carefully, as you'll need to ascertain that this isn't case C, and will need express that you're only bringing this up because the team is overworked, etc, not out of spite.

The approach for case A is similar to B, except that you definitely don't want to approach the manager more than once (or more than once every N months) with the same issue.