55

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?

closed as off-topic by Jenny D, Dukeling, gnat, paparazzo, Jim G. Jan 4 '18 at 22:36

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking for advice on a specific choice, such as what job to take or what skills to learn, are difficult to answer objectively and are rarely useful for anyone else. Instead of asking which decision to make, try asking how to make the decision, or for more specific details about one element of the decision. (More information)" – Jenny D, Dukeling, gnat, paparazzo
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Comments are not for extended discussion; this conversation has been moved to chat. – Jane S Jan 5 '18 at 0:32
70

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.

  • I already spent some time a month ago talking with the developer (one-to-one), he revealed me that he likes to work in that kind of place where "excellence" (at the programming level) is expected despite his profound lack of skills that he seems to say to be aware of. I was not very strict during this interview and bet on his potential improvement the days afterwards. – Mik378 Jan 3 '18 at 8:46
  • 18
    It is probably worth bearing in mind that the business dev will also be aware of this developer's ability. Hiding it, or not mentioning it might ultimately seem strange. – Paddy Jan 3 '18 at 12:55
  • 9
    @Paddy ...and give the (incorrect) impression that OP might not be up to the task of performance evaluation. – xiaomy Jan 3 '18 at 17:40
  • @Mik378 Investments usually take time to pay off, if ever. It's a business decision like any other - maybe he just needs some more time, or a different approach... or maybe he's a waste of your resources. When I was dealing with sub-par developers, I never expected a significant improvement for several months, and being up-to-par in less than a year or two - some people might surprise you (good background certainly helps), but don't go into hiring a clueless guy expecting he'll get better in a month or two, that's doing both of you a huge disservice. Skills aren't that easy to get. – Luaan Jan 4 '18 at 17:27
31

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.

  • 2
    It would be useful if you would also add what the conversation with BDev could look like when talking about the developer. – displayName Jan 3 '18 at 18:32
12

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.1

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".)

1 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.

  • You make a good point. Contractors usually command high prices, the company wouldn't be thrilled that the money they are spending on his contract goes to help cover up for an under-performing developer doing basic task. – Gilles Jan 4 '18 at 1:16
8

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.

  • 4
    I've never said that he does not participate to review with others and I've never said that his assigned tasks are not various and pleasant. – Mik378 Jan 3 '18 at 11:59
  • 3
    So he has different tasks: coding, reviewing, testing, documenting, technical writing, .... As he's not very good at the coding tasks, can you sell to the higher management that he's good at the other ones (and is he good indeed in those other tasks?)? – Dominique Jan 3 '18 at 14:52
  • 3
    If I hire a programmer and assuming I'm paying a programmer salary, I wouldn't keep him on at that pay rate even if I had some lesser tasks for the person to do. It seriously hinders the ability to hire another programmer. – user8365 Jan 3 '18 at 16:12
1

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.

1

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.

    0

    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.

    • 2
      You generally cannot fire (depending on country) so easily, especially if said developer has received official positive feedback about performance beforehand – George Jan 4 '18 at 14:17
    • @George: Good point - I have added a note on working with H.R. to create the necessary paper trail. – Pieter Geerkens Jan 4 '18 at 14:25
    -1

    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 to.

    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.

    • 4
      Although your answer has some great points (last paragraph), it is not an answer to the question but rather an extension. The OP did not ask to fire him or similar, but what he should do when talking to the responsible guy. Yes, the OP is not responsible. But he is working with them. From whom should the Business Dev know if a worker does a good or bad job if not from the OP? How is the Business Dev then supposed to do his job of finding good people? I think you and the OP agree well. But that's not an answer. – Mayou36 Jan 3 '18 at 19:58

    Not the answer you're looking for? Browse other questions tagged or ask your own question.