As a team lead, how to deal with a developer not doing his tasks

Question

TL;DR

I am a team lead of a new team with new hires, and the senior developer is stuck with some tasks for a month, every day he reports no updates, or very vague progress reports.
He is the only one with some experience with the tech, and he was the one who chose the tasks.
When having a 1v1 call to understand his progress, it was clear for me he made no effort, even the most obvious steps, like checking the logs for a production problem, he never did.
Junior developers are doing fine.
I have no idea if it is frustration, personal issues, lack of technical knowledge, or may be looking for another job and slacking off.

How should I approach this situation?

• Have another 1v1 call with him and confront him (I am afraid of reducing his motivation even more)
• Assign him to a totally different application (we divide work on a concept of app ownership, it will impact the colleagues who have already put effort on their applications)
• Ask management to give us more time and hope he is able to complete his tasks
• Report it to our manager, the one who hired him. (I would rather avoid)

---

If you need more context:

I work for big company, a new team was assembled with new hires, and as a veteran developer, I became the team lead/project owner.
Our team support legacy applications, mostly marked for discontinuation, often with poor documentation and bad code, I don't know if it was clear when hiring the new hires.
We are contractors working for a client, failure on supporting an application can hurt the reputation of the entire team.
We are all Java developers working from home, from different countries.
Our team inherited a C# application. I asked the team, if somebody had any C# experience, one of the senior developers, let's call him "John", said he had a little experience and that he would like to take the challenge.

The tasks (I am oversimplifying to avoid exposure):

1. We received a feature request: to assume a default value for a certain field when ingesting an xml file. Not very complicated.
2. To investigate an error in production. We received this request from an automated email, the email had a link for a dashboard, name of the alert, hostname and time of event but not many details about the error.

The progress

These tasks are in progress for almost a month now. Management is pushing me to provide updates.
On our daily stand up meetings, most of the time he reports "no updates", sometimes he says he found some clues, but never something concrete. He also reported multiple times he was going to ask a person from outside the team, let's call her "Mary", that had previous experience with the application.
When asked the team if somebody had impediments to their work, he never reports anything.

Recently we had a meeting to discuss his tasks, and asked him to show me what he had so far (I gave him 1 week warning to prepare for this meeting). My feeling is that he made no effort to address the tasks:

• He never checked the logs for the production error (he knows where the logs are, but he had no idea of what was the error message)
• He could not say where in the code it reads the xml file, after asking if he could do it now, he did a "find all" command in his IDE by himself and immediately found the line.
• When asked what came from the talk with Mary, he said he haven't talked to her yet, and then immediately scheduled a meeting.
• All he did was to explain the task itself but with more elaborate words, he was not able to present any results

My impressions about "John"

• He is very articulate with his words, he sounds like he is very confident about his stuff
• When he chose his tasks, he sounded very excited about working with C#
• Even the simplest tasks, like "Team, can you please update our home page with your contact details", he is always the last one doing it

---

Update

All answers and comments were very helpful. I followed what nvoigt suggested and paired him with our most proactive junior developer, they were working together in a call, and even though the junior had 0 knowledge about the system, they managed to fix the production issue in less than 2 hours.
Surprisingly, for the last 2 days he has been a lot more engaged, at least he was able to show me some real progress and is close to finish his second task. Working with a good influence gave him some motivation.

Answer 1

I do not disagree with the other answers, normally, you should take on more of a leader role and make sure they do their job.

However, maybe you don't want to be confrontational or won't get backing from your supervisor or HR, so you may want or need a slightly softer touch than "being boss".

Being the sole developer on a project you know little about is very challenging. Sure, you can Google a lot of things, but at some point you will be stuck with no way forward. And no person to talk about it, to get feedback, fresh ideas, another perspective.

So pair your failing developer with a colleague. This serves two purposes: one, it gives them a team, a way to speak about problems, getting help, without officially asking for help. There are cultures (and "western with a shitty boss" is one of them) where asking for help has serious downsides, you might be yelled at, reprimaneded or worse. Even if yours is different, they might have experiences to the contrary from former companies, so they are reluctant to ask for help. This way they get help, without asking for it. The other purpose is it gives them someone to compare themselves to. To see they are lacking. They don't want to be the guy who gets nothing done. Nobody wants to be "that person". And having another team mate will make that clear for example in standups. They will be motivated to either work more, or at least share more about their work, if they actively look bad if they don't. It removes the "this is all new to me" shield they hide behind, because their colleague has the same problems.

Maybe it works. Maybe it doesn't. You can still do the more formal, more bossy way afterwards, but it might be hard to do this softer approach, once you did speak to them in one of the other suggested ways.

Answer 2

Senior developer is stuck with some tasks for a month, every day he reports no updates, or very vague progress reports. He is the only one with some experience with the tech, and he was the one who chose the tasks. When having a 1v1 call to understand his progress, it was clear for me he made no effort, even the most obvious steps, like checking the logs for a production problem, he never did.

He is taking the piss, to put it plainly.

And to similarily condense your question, as it has a lot in it, it really boils down to:

What should I do with X who is taking the piss (rather brazenly) and doesn't even feel like providing updates, not to mention explanations, anymore?

That helps to see the answer clearly - you need to start doing your job.

They plenty of chance to explain, ask for help, excuse, whatever, and they have not taken any of it. Instead, you seem to accept them telling you "Yo, boss I did absolutely nothing for work this day/week" which should be raising your alarm bells and take absolute priority right away. 

As side note remember that what you see, so does everyone else on your team. They are not blind; they see X is not doing their work and seemingly getting away with it.

My first point of call in sorting this would be "the possibly-last understanding 1:1" in which I open with the issues, explain how I know that work is not happening for a month, how I tried to give them time to fix whatever is stopping them from work (because something is happening, despite them telling otherwise) and so far, there's no improvement. Continue to explain that while they don't need to explain to you what's going on (their personal problems are not yours to pry into) you cannot afford to have this unexcused lack of performance, and if things don't change you will have to escalate the matter.

Give them a moment to think and then hear out the response and... Really take it from there. There are too many theoretical scenarios here to realistically cover them all, but generally unless they provide really valid explanation stick to the firmness of how this MUST improve quickly. And then if it doesn't escalate it further, noting how you gave them this and many other opportunities to resolve it ahead of kicking it up.

Hopefully that talk gets them to get their act together as that's always the outcome you hope for. But if not, I am sure you can find another person to not do their job.

Answer 3

Leaders have to lead. You are the leader. This really comes down to two main things:

1.) Project Management
2.) People Managment

Part of leading is setting the milestones and deadlines. As the team lead you are the defacto project manager. If not for the entire project, then for at least for your team.

Holding this person's and the rest of your team's feet to the fire is critical.

Your managers shouldn't be expected to accept "unknown" for update information and when to see results.

Since, as a group, you aren't fully experts in C#, focusing on identifying what you don't know would be helpful as a priority. Human nature is to focus on the easy stuff. That tends to account for a lack of progress. Only you can tell if that is the issue here.

The key point about managing people is enforcing what is acceptable behaviour from your direct reports.

The four possible actions are:

• Do the task
• Ask for clarification
• Explain why you are wrong
• Quit

Ignoring you isn't on the list. Neither is you accepting that behavior.

This shouldn't be construed as a boss barking out orders. That is poor leadership. Good leaders do everything they can to make their team successful. But when it is all said and done, their team members must perform the tasks assigned and communicate any impediments quickly.

I hope this doesn't sound harsh, but it is what it comes down to.

UPDATE: The point of my answer is two-fold. By ensuring the project is accountable in small pieces it is easier to know when something or someone has gone off of the rails. The second point is to make clear that going off of the rails isn't acceptable. That impediments are to brought to the team quickly so they can be addressed before missing deadlines.

Answer 4

Not very complicated.

That is always the crucial question. Are there, or could there be, real complications? Is this a task you actually know how to do?

Certainly, it doesn't seem reasonable for it to take a month to alter an XML parser to assume a default value, if that's the only thing going on in a month, and without additional explanation or context.

But there could be additional difficulties. Can it be compiled, can it be tested, is there testing data already available, etc?

"Investigating a production error" of course could take any amount of time, and could fail to produce any results.

If these are new staff and everything about a codebase and wider system is unfamiliar to them, and retained staff knowledge is non-existent, it might not be reasonable to think any real progress will occur on such an investigation, and you may well be faced with someone bumbling incoherently because they don't know what they're looking at, and seemingly doing very little work because they're being prematurely exhausted by the scale of the difficulty and the lack of any support.

A lack of initiative, and a lack of taking obvious steps, are all consistent with being overwhelmed with the execution.

The most sensible thing for you at this stage would be to simply declare that he seems to have gotten bogged down and that he's stopped making sense. Take account of any remarks he may have in response.

Avoid an accusatory tone - it's not particularly normal for an experienced developer to just avoid work they are capable of, and even a dishonest worker who didn't like their job would only want to minimise their effort without drawing attention or being detected (not blatantly failing to get simple tasks done).

Going forward, look to assign a second person to "put their heads together".

You say he's articulate, so he shouldn't have too much trouble explaining to somebody else what's going on so far, on a one-to-one basis and in front of a screen together.

If the task suddenly flies along, then obviously the immediate problem is solved. On the other hand, if there is still no progress, then the second person is likely to have a perspective, and unless that second perspective is "I can't get anything done with this guy, he's a real piece of work", then it becomes unlikely that any part of the problem is with the person.