How to deal with a developer that has poor skills but with whom I get on well? [closed]

Question

I'm a Tech Lead since 4 months, as a Freelance, for an end customer.

One of "my" developer has really poor skills and, despite a severe amount of time spent to teach him and help him, I haven't noticed any improvement.

For a task that a good developer would achieve within 1 day, he spends 4 days and his solution never passes the code review in one shot.

The issue is that I didn't suspect such a lack of skills/programming knowledge at the very beginning and that resulted in us making some "jokes" and getting on well etc for this period.

Within a few hours, I will be meeting his responsible (Business Dev) to make a point about my team's developers.

I don't know how to tackle that interview.

Should I tell the truth? And therefore severely disappoint the developer? Should I hide it? And keep doing the majority of his job to keep deadlines? Of course this second solution is weird, but I'm a kind of sensitive person and I dislike to "turn my jacket" towards people.

Have you experienced this kind of situation?

Answer 1

It pays to be honest about things. Hiding or ignoring the issue will only make things worse in the long term.

The guy probably knows that he's under-skilled/motivated and most probably feels bad about that.

It's obvious that you want to help him out, so work towards doing that. Do what you'd do with any junior role, extend the estimates for his work and try to offer some mentorship to get him over this hump.

Be honest in the feedback to the Business Dev.

You've had a one-to-one with the developer, but it appears that he thinks he's working well. However, he's clearly not meeting your expectations as well as the other team members are.

You've done what you can to help him, but it's not worked out. So discuss this with the Business Dev and see what resolution you can come up with. This may result in recruiting someone new or a PIP.

Answer 2

If you want to be lead then you take the responsibility that comes with it. Protect your team, but be honest about it. In the long run this is best for your career.

So factual and professional is the best approach.

Answer 3

Your company is not paying you to be a pal. Implicit in Joe Strazzere's comment is that being "both" a pal and a Team Lead is not an option in this case.

You should be honest, since you should generally be honest. But really there are two perspectives that you don't seem to be considering that, for me at least, would by themselves be completely decisive. Particularly the first.

First, how does this look to others? In fact, how would an analogous situation look to you. Let's say your boss has another Team Lead who he's "pals" with but who significantly under-performs. The boss makes up for this under-performance by helping the "pal" out, lightening their load, and generally being more lax. How would you feel about this situation? Maybe you think it's no big deal, but will you still think that way if the boss complains about under-performance on your part or states that you need to work over-time to meet department goals? Maybe such things would still not bother you, but flagrant double standards bother many people. Certainly, it is demoralizing to others.¹

Next, is lying about or generally attempting to keep your friend in the same role actually in your friend's interest? If this role is a bad fit, it may be better for them to start redirecting their energy into a more productive route. Even if this is beneficial to them in the short-term, what happens when you (or they!) move on to a different job? Suddenly, they find out what they thought was adequate performance isn't, and now they're out of a job and maybe can't get a comparable one. Perhaps they've already adjusted their standard of living to the level of income the role they are not qualified for brings in. In this case, they may have spent months or years failing to build a stable base for their career.

And an extra third perspective, hearkening back to my first sentence: unless you treat any over-and-above effort you spend on your friend as not "billable" (i.e. you work extra hours to make up for that time), your company is now paying the cost for two developers but getting less than the output of two developers. And you want to actively deceive them about this. This is unethical. If you want to give extra help to your friend, do it outside of work.

To explicitly answer the title question: you should endeavor to treat this developer during work the same as you would if you did not have a better than usual relationship with them. In particular, you should endeavor to treat this developer like you would any of the other developers. This likely will include some degree of mentorship but certainly doesn't include doing their work for them and lying about their performance. Feel free to pour as much time as you want into helping this developer outside of work. Personally, I think you should give this developer as clear and honest of an appraisal of their skills and progress as you can if you are going to mentor them. I, personally, would tell them outright that, if asked by management, this is the appraisal I would give.

You don't have to work together to be friends. (So the implicit message I read into Joe Strazzere's comment is wrong; you can be a pal and a Team Lead if you decouple work and friendship. Of course, if your friend views the friendship as contingent on you providing extra help and behaving unethically then maybe you should reevaluate whether you want this "friendship".)

¹ In the US military, it's not only illegal to show favoritism to subordinates, it's illegal to even create the appearance of doing so, even if no actual favoritism occurs.

Answer 4

I don't understand your problem: you are working in a programming environment, where regular reviews are done. In top of that there are other tasks to be performed, like planning, testing, documentation, ...

If the guy is not sufficient at programming, then it should be very interesting for him to do some reviews of his collegues: like this he learns what good code looks like, which might be a serious benefit.

About those other tasks: when I started programming, I was also not very good at it, which was (amongst others) due to a personality issue: when I needed to focus for a long time on one subject, I got bored, and as a result my performance dropped. My boss gave me some other tasks (which were boring for him but not for me) like testing, documentation, quality assurance (writing and setting up procedures), ..., and as a result my mind was refreshed regularly, which boosted my motivation and finally my whole performance.

Some more thoughts after the first comments:

• Are you working in a country where losing your job is a big deal?
• Does your programmer has potential or not?

If you live in a country where losing your job means having enormous troubles finding a new one, then it's ok to be reluctant telling the guy is bad. This also applies if he has troubles finding a job, even in a more flexible country. In other case, if finding a new job is not a big burden, there is no reason not saying that the guy is doing a bad job.
In top of that, there is the question whether or not the guy has potential: again looking at my own experience, I started off quite badly, and after six months my boss wanted to fire me (so did the two key collegues of my department). However there was one collegue who stated "You have been training this guy for half a year now, and you think he's bad, which is right, but I see motivation and an increasing progress over the last two-three months, which makes me believe he has potential. Let him stay for another half year and by that time, if the performance still isn't good, then you can decide to fire him.". As a result, my boss kept me, half a year later my performance had increased drastically and indeed it was proven to be a good idea to keep me.

Answer 5

I'll say I was probably in that employee's shoes at one point. Let me try and answer what they may be experiencing from my experience.

I was hired into a job after school, and for my entire time there, I knew I was missing something. I first off wasn't even sure I'd get the job, because as a junior developer, I was doubting my skills to work for some company who was prolific in what they did that was a completely new area for its industry.

Fast forward about 3 months into my job, I wasn't sure I could hold my head above water well still. I too took more than what was estimated to complete some "simple" tasks. I felt very much aware that I was on borrowed time, and on top of trying to meet deadlines, learn some large architecture and code base, and ultimately hit the ground running, I flailed a lot. Overall, I suspect your developer knows they are struggling.

They probably feel overwhelmed with their tasks, when they also have this mental game going on about "is this the day?" and while that's not the attitude you should have, it was something I learned not to carry going forward. I should have reached out to my supervisors and communicated how I felt. I had still not understood the entire system and what was expected of me. I had to do a lot of little things, which sort of overwhelmed me because I never felt I stuck onto something long enough to learn it well enough. I never communicated the struggles I had in a reasonable time, which ultimately I learned not to do going forward. I just felt I was unable to perform with the heavy doubt in my head and anxiety I made growing within me.

After I was let go a few months later, I learned a lot from that job to not repeat. While I was there, I struggled to maintain some key things.

1. Ask for help sooner.

2. Handle stress and doubt better

3. Find out where I was standing to communicate and establish between both parties my current standing with the team so I could correct issues earlier

Fast forward now, I have a new job where I feel none of those problems, and can say confidently I would be able to do the things I didn't think I could before knowing what I know now. I had to learn though, and I know that experience was invaluable, even if it did hurt to be let go.

So I say it should be considered as a leader, if this is right for your team? Sometimes you have to make the choice to let go, and people do need to learn from failure. If you don't you'll hurt your company's progress, but if you can talk with your team on conversing with this individual to assess from them what they think or feel at the moment, you could potentially learn that their slow and ineptness may be caused by some of the other factors I experienced.

A job is a job, in the end. We can love who we work with, enjoy what we do, but we all have a goal to complete and sometimes things don't work out as planned. Hopefully if this individual is let go, they learn from it, but if your team feels they can make this work, hopefully you'll all learn something that will help out the next time you come across this situation and save yourself some time and money in the process.

Answer 6

Different answer: do you need everyone on your team to be a superstar? Maybe he's useful even if he's slow, to do the simple things while the others in the team do the complex parts.

Of course, that depends on how much he's paid as well. And it's something you should talk with your manager also.

Answer 7

You're Fired!

Either you say this to your friend, or senior management will say it to you. Get to work with your H.R. department on how to construct the necessary paper trail for "firing for cause".

You have already cheated your employer out of severance due by failing to make this call within the probationary period of his hiring. Now you continue to strain relationships with the rest of your team, by requiring them to do unpaid extra work to cover the fawning sycophant's incompetence, while you continue to cheat your employer by the amount of your friend's wages.

So: Grow some cajones; become a leader; and do what you know is right before it is done to you. You do no-one any favours by delaying the inevitable.

Answer 8

Are you sure of your position? Is it your role to deal with personnel issues? Or is there a line manager to whom the developer is responsible.

I've been where you are and I think, in my case at least, the technical team lead is responsible for delivering the technical solution, not for the long term development of personnel. If I'm right, and I may not be, then your responsibility is to use the resources you have been given to achieve your technical goals.

You should steer clear of judging your team simply because you may well not be aware of issues that affect their performance. It is the line managers responsibility to balance the performance with the personal problems, and also for the allocation of support and training. And if you continue to judge you may well offend the developer and the line manager by going beyond your remit.

Its worth remembering, as a tech lead, you will most of the times only ever get average developers. To expect more is to be deluded. For every great developer you will have a less than average developer. All you can do is find a task where the less than able be the best that they can be.