How to deal with a difficult junior programmer?

Question

I am the technical lead of my team and have joined that team a couple of months ago. Most members were there before I was. It took me a couple of weeks to earn the trust of my team but I was helped by the management and even upper management, and I now feel like I have achieved that. I, however, have issues in dealing with the most junior member of the team.

Whenever they ask me for help, I immediately make myself available (or make sure I become available ASAP if otherwise engaged with a discussion with someone else) and do my best to help. Very often, it's about small problems but every single time I face an intense resistance in whatever I suggest. Here is an example of what I mean:

Junior: Hey can you help, I can't synchronize the sources.
Me: Sure. What is the error you are getting?
Junior: Well, I'm trying to download the source from here to do this and that, and next I want to do this.
Me: Yes, makes sense. What is the error?
Junior: pissed for some reason, they shows me the error...
Me: Oh okay, yeah... this program can't deal with the passphrase on your private key. It's annoying and a security problem, but you'll have to remove it. Is there a particular reason why you generated a private key with a passphrase?
Junior: You can't have a key without a passphrase.
Me: Sure you can. I don't have a passphrase on my private key.
Junior: No. You can't have a private key without a passphrase. It's not possible.
Me: Well... You can. Let me show you.
Junior: No I don't want to regenerate a private key.
Me: You don't have to. You can just remove the passphrase and keep the private key you already have.
Junior: No. I'll find another solution.

Obviously, you can tell they weren't satisfied with my solution and while I indeed admit that it's a security problem when you have to get rid of your passphrase, it's something everybody did on the team, and it's just one of those corporate quirks you have to live with in that particular case.

I wouldn't mind if somebody found a solution actually, quite the opposite. But the problem is they has now been blocked for days and is still refusing the known solution - or workaround, depending on you see it. As a result, it's pretty much impossible to put them on any critical task, because there is no telling how long they are going to get stuck in such already solved-problems. This is all the more frustrating, because I actually think they are quite skilled for a junior developer and has shown that in many tasks.

Things are like that every time and only get worse when it's about a code review: no matter how diplomatically I type my comments ("I'm not sure to understand why we need ...", "I would avoid ... because of. What do you think?", ...), they are systematically received with refusal and no explanation. I am actually in a position where I could force them to do things my way or refuse a commit that doesn't do things my way, but I've never wanted to do this. I believe in convincing people with facts and numbers, not with titles and responsibilities.

I am at loss figuring out what to do here. I am usually pretty good with people and in 10 years I've never had a case like this. I went to our manager (we share a manager) about it, and he confessed that the other day they told him something like: "I'm very good at psychology and I think this person (me) has a narcissistic behavior and will ultimately destroy the team".

I have all the support of my manager but I can't say that didn't hurt and frankly, I don't understand any of it. I never once imposed anything and if anything, I am very open to new ways, discussion debate, and never once hesitated to say "sorry" or "I was wrong, my bad". I never done anything wrong - that I know about - to that person.

How can I deal with this situation? I can't refuse interactions with them (because I would be accused of favoritism with the other members) and every time they still ask for help, they react badly. It feels like I can't win.

Answer 1

You are the technical lead. You have a subordinate that is not only stuck on a problem for a long time without delivering, but actively refuses to accept help.

You need a one-to-one where you explain the problem, that she is not delivering anything, and that she was given help that would have solved the problem, but refused to accept it, and ask her what she intends to do to improve the situation. It seems that right now she doesn't feel any need to improve, so that need to improve needs to be impressed on her.

And should she not improve, then you can ask her where that leaves you. Whether she thinks that you should put up with an unproductive team member forever, or whether she thinks that you ought to find a replacement. Either this helps, or you do need to look for a replacement. Your manager will know how to do this without problems (collect the evidence etc. etc. )

PS. If you have an employee who is afraid of any kind of authority, that is not your problem, that is the employee's problem. If she feels cornered and acts harshly as a result, you decide if that behaviour is compatible with being an employee of the company. A one-to-one is part of the job, if she refuses to take part (by leaving the room) she is refusing to do her job. I think your team probably knows very well who is pulling their weight and who isn't, so morale isn't in danger.

Answer 2

As a tech lead, you need to be willing to exercise your power. I have insane respect for you that you are averse to doing so (people can be bad with power). But the reason you have this power is as a last resort.

If she is affecting an actual customer product, you must force her compliance

At the end of the day, she won't be responsible for the product. You will. Your manager will. etc. The executives aren't going to be happy if your excuse is "our junior dev slowed us down".

Here are some things to do, in order of severity, if she refuses to comply:

1. Answer her questions. Nothing more

You seem to be doing this. If she asks a question, it's probably your responsibility to give an answer or connect her with someone who can help. That's the job of a tech lead.

However, if she rejects it or doesn't follow through, you probably shouldn't be wasting your time convincing her otherwise. Especially given her personality.

You might just have to let her sink or swim on her own, with the helpful advice you've laid out. "You can lead a horse to water but you can't make it drink".

2. If she is constantly blocked, plan around it

Match her workload to her productivity. If she's blocked on her own accord, she's going to have low productivity, and perhaps low reliability. Don't let critical workloads be dependent on people like that.

Yes, this may seem unfair, especially if she is a more-than-capable programmer. But at the end of the day, your productivity is the measurement of your job, not your intelligence.

3. Have a sit-down

Get yourself, her, and your manager in a room together. Explain the situation of her low productivity.

Let it be known it's because she's frequently blocked. Your manager already knows what's going on. This meeting will show her how serious this is and that she may need to suck it up for her career.

4. Request a change

Put in a formal request to the managers to transfer the team member out if she's causing the team to have trouble producing.

The managers may find her a better fit. More likely, they will find a replacement. The fact that you are trying to get her off the team is a big signal.

Be careful going about option 4. Make it overly-formal and evidence-backed, so you don't look like you're trying to just get rid of someone.

Answer 3

This girl might be on the autism spectrum. It often goes undetected in women.

It sounds like you're adding in a lot of "maybe you should"s and "Here's how I do it"s. These social cues are great for dealing with normal people, but to her, these are flags that say "you can ignore this if you want to".

Before you get the ball rolling on replacing her, try being much more direct - almost to the point where other people would consider you an ass hole. Next time she comes to you for help, tell her "Do it this way by the end of the day" and see what happens.

Answer 4

Although this question already has a verified answer which I agree with wholeheartedly (a 1 to 1 of the nature described in gnasher's answer is definitely the best way to broach this problem directly), as a junior dev in a similar, albeit not identical, situation, I hope I can contribute an insight as to what may be the root of this.

I've worked on a development team for around 3 and a half years now and in the capacity as a trainee dev for just over a year. I've received almost exclusively positive feedback for my work and personal development throughout this time and have received similar comments about being skilled for my level of seniority. However, I also find myself blocked for significantly longer than I should be on often fairly trivial (or at least known) issues that delay my progress for X number of days (no exaggeration). I can't comment for the junior dev in the OP's situation, but this is something I'm acutely aware of and brings me a lot of stress and self doubt.

In my case, I've been provided with solutions in the past that clearly would have solved the problem, but that I have held off from implementing, and used the suggestion as inspiration to try and find a more optimal solution (often to no avail). In every case I can think of where I would do something like this, it's when the solution provided is pragmatic rather than 'by the book' and gives me a bad gut feel for the outcome (in terms of adding to technical debt, adding unnecessary complexity or presenting a potential security flaw usually). As a junior dev still trying to grasp the balance between best practices and pragmatism, it's often difficult to understand why we would do something that differs from best practice, and although we will generally get a feel for when something feels right or wrong, our intuition is not yet fully developed. For me, a lot of whether or not I can trust this solution is also based on how much I can understand and trust the thought processes (i.e. the route) to the solution.

As such, I would suggest trying to identify when situations that are converse to your language's coding standards occur and explaining why it is pragmatic to do this, and what steps you have implemented to mitigate any issues caused by this deviation from the 'norm'.

In this case, at this point in the conversation:

Junior: You can't have a key without a passphrase.
Me: Sure you can. I don't have a passphrase on my private key.
Junior: No. You can't have a private key without a passphrase. It's not possible.
Me: Well... You can. Let me show you.

Instead of:

Me: Well... You can. Let me show you.

An alternative could be:

Me: Well... You can, although it would usually be discouraged for causing a security risk. In this case the whole team has adopted it this way to workaround [abc issue] which caused [xyz slowdown] and was considered reasonable because of [the golden justification].

This explains the full context of the issue, assures the junior dev that the solution is in place for practical reasons and confirms that you are aware of the best practice issue they may be contending with but that this seemingly oddball solution has been put in place for a viable reason. It also provides an opportunity for the junior developer to ask their own questions to expand on their understanding on the topic area and clarify specifics that may have led them to be blocked in the first place.

It should be noted that my situation does differ in a fairly crucial aspect from the OP's in that at no stage do I take review comments or criticism about work personally or refuse to implement changes. I certainly wouldn't ever discuss my colleagues in such a disparaging light, especially to their direct manager, this would incredibly unprofessional and grounds for immediate disciplinary action in some organisations. Given the context provided in the question and assuming (rather generously) that the junior developer's behaviour is linked to this mentality around questioning of the solution against best practice for this behaviour, I can only suggest that this may be down to a lack of confidence in their sources of authority. This assumption is a pretty massive jump, but if it does end up being the case, then continuing to elaborate on the steps leading to and 'why' of the solution will start to rebuild that confidence, even if it takes a fairly long period of time to do so.

Answer 5

You're in charge; don't tolerate insubordination

I appreciate your desire to be nice (keep it up!), and you can and should exercise authority in a respectful way, but at the end of the day as team lead you have the authority to tell team members what to do. This should be used as a last resort for a number of reasons (it's more respectful to get people's input, people respond better to it, and often their input is very valuable--you may learn that you were wrong), but at the end of the day the person in charge gets the final word. That's how leadership works.

As team lead, you get the final word. But currently you're inadvertently giving it to your insubordinate team member. Next time you're giving an explanation to the team member of how something needs to be done, and the team member refuses to accept your reasoning (assuming of course that you don't change your position during the discussion, which you should always allow for), then don't leave it up to the team member to choose to come around to your point of view or reject it--tell them to do it your way. This is not an abuse of power--it's fulfilling your duty as team lead.

If they refuse, then you need to document the incident (and all such incidents) and take this case of insubordination to your boss. Insubordination is a serious offense (often a firing offense), and it's serious because the number one requirement for any employee is submission (i.e. voluntary subordination) to authority. An employee who will not submit to authority, no matter how talented they are, is too great a risk to the company because they are unmanageable. Find out how your boss wants to proceed.

Talk to your boss now

The fact that your team member has already slandered you significantly to your boss is a huge, giant, unignorable red flag. Your boss brought it up to you, but if you haven't discussed what it means with respect to your authority, you should do so. This tells me this employee is pathologically insubordinate. That doesn't mean it's not solvable necessarily, but that this is a big problem that should not be ignored; it needs to be addressed immediately, and your boss needs to help you come up with a solution. HR should probably be involved (I'm not suggesting you go to HR on your own, just that you and your boss should probably involve HR) to ensure that you follow the correct process for dealing with this employee whatever you decide.

A word of clarification: submission to authority doesn't mean the employee should blindly accept direction without sharing their point of view or concerns; but it does mean that at the end of the day if the leader is not asking the employee to violate moral, ethical, or legal norms, then the employee should follow the leader's direction even if they don't fully agree with it or think that it will work. Leadership has a right to take risks (within moral, ethical, and legal bounds) and own any failures.

If the employee does refuse on moral, ethical, or legal grounds, they have the responsibility to fully lay out the reason for their refusal. Simply saying "no" without explanation is insubordination. So in this case even if the team member believes it to be unethical/immoral to violate security best practices, that team member has the responsibility to say so; the fact that they simply said "no" is inappropriate and is insubordination (in addition of course to their slander of you to your boss as was mentioned earlier).

Answer 6

I am the technical lead of my team and have joined that team a couple of months ago.

(to be clear here, I don't agree that using an key without a pass phrase is an increase security risk, if you limit the use of the key to a specific purpose. It's a delegated authentication and assuming that the access to the accounts themselves is well protected, not necessarily a issue)

Back to the question: a couple of months? I am a technical lead, with me she would get time until the end of the working day to fix it, escalate it, or leave.