How to lead unproductive team

Question

As a lead developer I have to supervise two very unproductive and irresponsible colleagues. The problems are:

• Deadlines are always missed by two-four weeks.
• Junior-level tasks may take a week instead of a day or may be not done at all.
• Even the simplest code committed for peer review may be totally untested and broken.

An attempt to discuss the problem shown the following motivation:

• Strong prejudice about learning any new technology.
• No motivation towards responsibility for code quality.

I even have to argue with them for days just to make them fix their own code after peer review comments. The problem became even worse because of lack of supervision due to quarantine. It should be noted that my colleagues are young (30 and 35 y/o).

As far as I understood: they were working without supervision for a long time (more than a year), managed to show some results and had zero responsibility. Now they don't want to bear any responsibility as before.

I discussed the problem with my manager and it was suggested to gather some evidences for argumented layoff. I understand that position but I still want to try to overcome the problem. I know about the practice of "performance reviews" but it may take a long time to introduce it for every developer.

Is there any way to deal with such problematic teams?

UPD:

Thanks for all the help! The answer from @scaryclam is the best fit for my situation. I also want to remark the answer from @Flater because bad experience is the most valuable.

Answer 1

You seem to have taken on a team that has little to no motivation and some seriously bad habits. As the lead, you need to understand that you have responsibility to 1) set clear and achievable expectations and 2) hold your team members to them.

Your team have had a long time to build their bad habits, so you need to bring some clarity to what you expect, why you are setting these expectations and when they need to show that they can live up to these expectations.

You should also be documenting what your team is living up to or failing to do. Talk to them 1-2-1 and take the time to understand why as well. If a previous manager has created a working environment where doing things on time is not celebrated but punished by extra work, or an ex-tech lead gave a load of bad advice about learning new things etc, try and understand that and address it fairly. Create an atmosphere of trust and safety. Sometimes a team is failing because bad management or toxic colleagues have created an environment where their behavior is the only way to survive. If that's the case, then you can turn things around by gaining their trust, showing that living up to delivery promises brings good things and that you will listen to them and help them, even when they fail.

If you team truly is dragging their feet, don't have a good excuse and won't change, then yes, make sure that you gather enough evidence of this, and don't be frightened to lay people off. Bad employees can have an affect on more than just the immediate team, so removing them isn't just going to save the company money, it's also going to leave space for others who are able to bring some value.

Answer 2

This is an anecdotal answer, as I've been in your exact position. Sorry for the long read, but it gives you an idea on the situation you're in, how you can sometimes resolve it, and how it can sometimes be unresolveable.

As a consultant, I was hired by a company to fix their development processes. I quickly identified a problematic work culture with little to no developer guidance and a toxic undertone. The solution to this problem falls into two categories: Developers who mean well, and those who don't.

The short answer

Is there any way to deal with such problematic teams?

As long as the developers want to improve and are simply lacking guidance, then yes. If they actively don't want to improve, then no.

Developers who mean well

Initially, I assumed that it was innocent ignorance. The company put too much work on all developers and their bad practice (cutting corners, writing slapdash code, no testing, ...) could be a way to cope with the workload. Without guidance, junior developers will develop bad practices without realizing that there's a better way, and if the pressure is constantly too high, they have no time nor effort to dedicate towards investigating if they can improve their (bad) practices.

So what I did is dig into the actual work they did. I didn't just observe the task itself, but also the code they committed, how long it took them to commit the code, and I investigated bugfixes (after the fix was implemented) to backtrack where the bug occurred and how it could've been prevented from the get go.

Using that information, I started tailoring my feedback to developers. Instead of giving them a theoretical rule ("you should do [thing]"), I used their concrete experience ("If you had done [this], then [this later bug] wouldn't have occurred").

Every developer (except one, which I'll get to) immediately improved their practices, deadlines were being met more often and bug reports decreased significantly. This proved to me that the issue here wasn't one of work ethics, but rather a lack of guidance and overhead. Every developer has been hired by the company as a junior, and they had all learned their bad development practices at this company. Those who stuck around had become senior developers, who in turn trained the newly hired juniors, thus causing a recursive loop of bad practice.

If the developers are well intentioned, it's a matter of making them understand the benefits of better practice. This requires concrete examples and clearly noticeable improvements to quality of life (both of the code and the developer's day to day tasks), but once shown, developers will take to them.

But what if your developers are toxic or ill-intentioned? This is where we get to the one developer who didn't improve with guidance.

Developers who don't mean well

This developer's behavior was very problematic. No testing, writing code in a language (French) that half the staff doesn't speak, refusing to learn new technologies or approaches, claiming sole ownership over their code and actively reverting any commits that touched "their" code without their explicit permission, actively ridiculing anyone who pointed out an improvement to their code, debugging on the production database because taking a backup takes too much time, ... the list is endless.

However, this developer was rated the highest by the company. Not because of their practices, but because they were able to solo projects. The company didn't understand development practices, but it does understand money, and a developer who bangs out projects in half the time seems very profitable and should be rewarded, right?
What the company didn't realize is that these projects ran well past their deadline as we'd spend three times longer fixing bugs. Even though the company thought they were being faster, they didn't factor in bugfixes as the bug reports would only come streaming in after the software had its first release.

The problem was that this developer's code was so shoddy and unreadable that no one but them could work with it, and there were seven software packages that could only be supported by this one developer because anyone else immediately advocated a complete rewrite to avoid the bugfest that it was. This led to the company relying on this developer, which gave them a false sense of superiority and that they were doing the right thing.

When I provided guidance (under the assumption of them being a well intentioned developer), I was met with an absolute refusal to take any advice. They would ridicule any suggestion that their code could be improved, argue to no end about inane matters such as indentation, and would refuse to write any test as is "wastes time they should be spending on fixing bugs".
After weeks of not getting through, I decided to fix their code for them (which is not my job) and then discuss improvements with them afterwards in the hope that seeing the improvements would show them that it could be done. But they actively reverted my changes and screamed at me in public for touching their code.

At this point, I addressed the manager. The screaming was unacceptable, but even more importantly, I was at a point where I would not be able to improve this developer's performance unless "I physically forced their fingers on their keyboard to write different code" (hyperbolically), and forcing others to do things they don't want to do is obviously not acceptable.
The ball was in management's court, they needed to reprimand (or threaten to reprimand) this developer because they completely refused to even consider improving their work. That's a HR problem, not a technical one.

And the company never did. I left after another few months because I just did not want to deal with the toxicity anymore. I later found out that this developer had been actively blackmailing their employer, threatening to refuse to work on the seven projects that only they could maintain, which would cost the company more than they were spending on the developer's wage. And thus the company always gave in. This led to the other developers, who had actually significantly improved their development process, to give up as well, as they were being rated more poorly than this bad practice developer (and thus not given any raises or promotions). Last I heard, after a massive exodus of developers, the bad practice developer is now training all the new hires.

This is a bit of a downer ending, but when you're dealing with toxic or ill-intentioned developers, the only recourse is to get the company to correct the issue - either by correcting the developer or firing them. All you can do is assess the situatuion and provide concrete evidence that this developer is underperforming and actively refusing to cooperate with their colleagues.

Answer 3

Given from the description you give, especially the fact that the whole team is under-performing and not just a single individual it sounds like this a problem with the process and not the individual developers. My way of tackling an under-performing team:
1. Observe how the team is working and what the underlying problems are
2. Let the team know what is expected from them
3. Fix one problem after the other

1. Observe

• Deadlines are always missed by two-four weeks.
• Junior-level tasks may take a week instead of a day or may be not done at all.
• Even the simplest code committed for peer review may be totally untested and broken.

These are symptoms of the process going wrong, but you don't know the root cause yet. I won't get into the detail for each one of these points, as those could be individual questions, but taking missed deadlines as an example, this could happen due to unrealistic expectations, bad estimations, unplanned distractions, wrong prioritization or changing focus.
One of the first things you should do is observe the team in its normal way of working and see how things are going wrong. Try to identify the root causes of the symptoms management is upset about. Talk to the team members every day and have catch-ups as often as necessary (I usually start with weekly 1-on-1s with teams that are under-performing and then I move to biweekly, when I am more confident about the specific team member). If there is a lot of things going wrong you have to prioritise; try to focus on the ones that management is most upset about and that have the most impact.

2. Set Expectations

An attempt to discuss the problem shown the following motivation:

• Strong prejudice about learning any new technology.
• No motivation towards responsibility for code quality. I even have to argue with them for days just to make them fix their own code after peer review comments.

This usually happens, when team members don't see a reason to change. They might think "This is how we always worked, and it served us well for a long time". You have to kill that attitude and let them know that their managers are unhappy with the team performance and that their asses are on the line. Be consistent and clear in your message, rather over-communicate than under-communicate: If missed deadlines and poor code quality are the top problems, talk about deadlines and code quality every single day and during the 1-on-1s. "We cannot miss the April 30th deadline." and "There can be no way that we push a commit that does not pass unit tests in CI/CD"

3. Fix problems Now that you have identified the problems and made the message clear, you can fix problems. Keep in mind that changing behaviour of a group is a hard and slow process. You might be tempted to try to fix everything at the same time, as so many things go wrong. But for every change you make, you will have to follow up on it and repeat the change multiple times before you can make it a habit. Only introduce so many changes you can follow up on and the team can adopt. Prioritize things by the expected result and the size of the change. Often the right small change can already have a big impact.
E.g. if the biggest problem of the team are missed deadlines and the main cause of this is that lower priority stories are picked up that don't contribute to the main project, you could make it a rule not to pick up low priority stories if there is any high-priority stories left. Then for the weeks to follow you make sure that this rule is followed every single stand-up.
There will be times when rules cannot be followed, this can often lead to even deeper underlying issues with the project and you need to follow-up on that, until the team can follow the new process and you hopefully start to see some results. After you see the first changes being implemented you can re-assess the situation. Some problems might have already gone away, others might still be there. Keep changing one thing after the other and never stop improving ...

If everything goes well, don't forget to keep reporting progress to the higher-ups. The teams reputation might be bad and the fruits of the changes take a while to manifest. Make sure to show that there is progress and the management can be optimistic that the team will be performing to their satisfaction soon. You don't want to put in a lot of effort, just to see the developers being let go anyways, because you didn't advertise the teams improvement enough.

Answer 4

To produce results, you need ability and work ethics. Your team lack one or both.

The next task for each team member you do the code review. First you try if it works (that’s not the same as testing, that’s what QA does, but basic checking). If that fails, the review fails, and you tell them to fix it, and not to put things that are not working up for review. “Working” is the first requirement for code. The next time if it doesn’t pass here you ask them what they tested. And what they didn’t test and way. Make clear that code that doesn’t even work is not acceptable. And hint that there might be consequences. Like “My boss is not happy with this team’s performance and is asking me who I’d suggest to replace”.

Writing working code doesn’t take longer than broken code. Obviously as the team lead, tell them that you are there to help if they can’t get something working. All this should be a first step to improvement.

Answer 5

The other answers are already very good. But for me one very important thing is missing: First you need to find out why they are underperforming so much. If you assume, that they do it on purpose and simply don't WANT to perform better, then you can stop reading here, then the only advice can be: get them fired... But else: Try to find the real reasons.

MISSING DEADLINES / JUNIOR LEVEL TASKS

Missing deadlines and doing "junior-level" tasks in much more time than assumed may both have the same reason:

Who exactly sets the deadlines and classifies the tasks as "junior-level"?

I have gone down this road a lot of times with different colleagues: Tasks that I consider easy and "can be done in one day" as I am an experienced developer in one special field seemed to be impossible to solve or need a much longer timer for others.
There were two different reasons for this:

1. They simply were junior developers and didn't know how to do those things
2. They were experienced developers but in different fields and just didn't know enough in that special field of expertise.

Having deadlines that someone else defined because of his knowledge and estimation can be very frustrating, if they do not fit your abilities / own estimations.
The solution for this is to include the developers in the planning process: Let them agree with the deadlines and take them accountable for their own word.

CODE QUALITY

The poor code quality might be a direct result from the tense timelines: If I cannot do my tasks within the allotted time frame, then I do as much as I can and leave out all the "unnecessary" stuff like testing or even try- running my programs.

So: Give them the responsibility to set their own deadlines and then hold them responsible for holding these. If they still miss their deadlines although they agreed on it, then you might be in the situation to let them go, as they are not able to meet very important expectations.

LEARNING NEW THINGS

Again: not wanting to learn new things MIGHT have the same reason: If one already has to much to do to achieve his goals then he might reject to learn something new as this will -at first- slow down progress further and increase the pressure because of tense time lines...

TL;DR: Try to take the pressure from your developers by giving them the chance to influcence their own work / dead lines / etc. Talk to them. Ask for their opinions. Find out WHY. Then decide how to proceed.

Answer 6

but I still want to try to overcome the problem.

This is your fault, you're unwilling to take disciplinary action when everything reasonable has already failed repeatedly. You're not doing your job properly. With responsibility comes hard decisions. You either make them or you're as much a problem as anyone else.