Sfrgttk

So here's the part that seems sketchy to me: You've asked your employee, John, to do unpaid overtime work on the weekend.

• The reason it's "work" is because learning Angular is not something John would like to do in his free time, hence why he hasn't done it already (and continues to not do it), and it provides no value to John personally except inasmuch as it provides value to the company. Performing a task that is not for one's own benefit and is instead for the sole benefit of one's employer, is called "work".




• As for "overtime", that much should be clear; John is not normally working on the weekends, therefore you have asked him to do work outside of regular hours. That's called "overtime".




• As for "unpaid", presumably you have not offered John any sort of compensation for doing this work on the weekend, and presumably you do not have the authority to do so. As a result, John is not going to be compensated for putting in these efforts on the weekend. That's called "unpaid".

Now that we've got this straight, as a team leader, and particularly as a new team leader, you should not have your first impression with your new team be "please spend your weekend doing unpaid overtime work". That's not going to work for you in the long run. Don't do that.

Coming at this from John's perspective, I could equally see a question (and have seen many on Workplace SE in the past!) that goes something like this:

I recently graduated from University, and I applied to and got a job at a company that was looking for a backend Java developer. Upon joining the company, I was immediately placed into a frontend development team using Angular. I have no experience with Angular, and the interviewer and hiring manager were both aware of this throughout the interview process. Furthermore, due to these circumstances, my boss has required me to work unpaid overtime on weekends to catch up on my lack of knowledge. What should I do?

To which, and because I have seen these sorts of questions in the past, the overwhelming majority response would be "Unpaid overtime is not cool, your company does not respect you, they blindsided you with a team that doesn't match your skillset, find another job". And that's what John is going to do.

If you want to help John rather than frustrate him and make him leave, here's what you can do:

1) Do not ask John (or anyone else!) to work unpaid overtime. That's not cool.

2) If John needs to learn Angular, allow him to do so during work hours. Prepare some ramp-up tasks for him (small tasks to get him used to the framework and used to frontend development) so he can get his feet wet slowly and ramp up his comfort level.

3) Provide John with the mentorship he needs.

Failing the above, ask your chain of command to transfer John to a team which actually uses the skillset he was interviewed for and hired with, and don't blindside him by trying to change a capable backend developer into a horrible frontend developer.

If I was a CTO, and a manager came to me and said,

We aren't performing because one of my team members is bad at her job

My response would be,

Why are you telling me this? You're the team lead, do something about it. What's your plan?

In other words - going to your CTO and explain the delay by pointing out performance issues on your team isn't the solution - it's not going to suddenly change anything or solve the problem. You need to come up with an action plan, not just tell someone else that the person is underperforming. Yes, you may want to communicate the fact that she is a poor performer, but the communication is just part of the process, it's not the thing that will make this all go away.

It sounds like you've done a half-hearted job of this already by telling her she needs to learn about these subjects. You may want to reflect on some other options:

• Expecting an employee to learn on their own time isn't always fruitful, as you've seen. Do you have an opportunity to incorporate the training into her working time? By having someone mentor or train her? Or allowing "development time" where she can focus on learning?


• Expecting an employee to be able to do good work in a technology they're not familiar with isn't always fruitful either. Some developers can easily pick up new languages or platforms, others struggle and are better being treated as an "expert" in one specific environment. If that's the case with this woman, you need to decide if your company needs an expert in Java, or if you need someone who is flexible. It's not inherently a problem of her being a bad developer, it may just be that she's not the type you need.


• Make sure you understand your employer's approach to performance management. If the employee isn't able to perform the job as it is outlined in the job description, you may need to start taking more formal steps. The key when this happens is following policy (ie does your HR department have a formal performance improvement process?) and documenting every little detail, so you have good backup if you get to the point of deciding to let her go because she's not a good fit.

One thing that's hard for some newly promoted leaders to grasp is that your job is not to be an expert at the tasks your team does. In many environments, your job is as much about managing the people as it is about managing the work. This is a people problem. Yes, it may be her poor skills that are causing the work to be delayed, but from the employer's perspective, that's as much your problem as it is hers.

But he doesn't even know the basics of HTML and CSS. I told him to study these subjects at home from Codeacademy in the weekend/holidays.

Huge red flag.

You (or your company, but since your the lead, it's your responsibility) put him on a job needing skills he does not have. You have to train him during work hours if training is needed. If he lied about his skills then fire him, but if he was clear that he knew only java then you are wrong.

The solution is quite simple : allow him to study these subjects at work, and do nothing else work related during a well-thought time box (2 or 3 days for a Software Engineer, maybe more for less graduated developers).

I won't reiterate dwizum's excellent answer, but I have a few things to add:

His main problem is that he doesn't do the work in a logical way but always try some random permutations and combinations in order to make his flukes as a successful attempt to do the work.

Have you tried showing him more effective problem solving strategies? (Yes, ideally a graduate would know how to "work logically", but problem solving strategies are usually not part of the formal curriculum, and sometimes not taught as well as they should).

I even told him to google about a concept which he doesn't know but he isn't good at even searching on google

Have you tried showing him how to google effectively?

Also note that it will be challenging for a Java developer to google angular problems, since the programming language, build tools, and runtime environment are totally different. Understanding a random blog post by a JavaScript developer is challenging if you don't know know web technologies.

Check your expectations

I have spent the last couple years coaching experienced Java teams in their first angular projects. In my experience, only about 20% of the developers were able to make this switch without help. And yes, even though everyone attended a professional course about angular, and had access to experienced help, progress on the first angular project was slowed enough to make management nervous.

Summary

Yes, really good developers can pick up a new language without any help, but most developers will need more help than "you need to learn the basics".

As a team lead a certain amount of managing the performance of the rest of the team is to be expected.

It sounds as though so far you've done a fairly minimal amount of that - mainly telling them to study at home or google it. And so far that hasn't been particularly successful, probably because they are pretty unhelpful approaches to helping a new entry level team member get started.

I am thinking that the only solution I'm left with is to tell the CTO about that girl and her habits of doing work with guesstimates so that he can decide whether she is ready to work or not.

Ultimately it might come to that - but if I were in your CTO's place I'd be looking for you to take a more proactive role in trying to resolve the issue before you brought it to me.

Take the struggling team member aside and have a conversation with them, see if you can a) get to the root of the problem and b) work towards improving it.

You don't need to go in all big and shouty and aggressive - a good team lead should be facilitating the work not ruling with an iron fist.

It seems like you're struggling with some of the elements of what we are working on at the moment so how can I help? Can you tell me why you are struggling? Is there anything in particular you feel you need help on?

Hopefully you can then work with the team member to improve things, but ultimately it might just not work out. Then you can consider talking to the CTO and saying something like:

[Team member] is really struggling to grasp some key elements of the work. I've spoken with them and we've done X, Y and Z to try and improve the situation but it's not really helped and I'm concerned that it's effecting out ability to deliver our team's work.

The other commentators are right - it is your responsibility to make sure that this developer is able to develop in Angular (because they were assigned this task knowing that their background is in Java).

Even I have to solve 90-95% of his tasks by myself and then he learns

DO NOT solve this person's assigned tasks for them - it is hindering their learning process. If they cannot handle the workload and you are ultimately completing tasks for them, BEFORE bringing it up with your CTO, I'd suggest you:

1. give them a basic tutorial on Angular (maybe focus in on the things you'll be using)


2. Reduce the amount of tasks assigned to them (whatever workload they currently have sounds like too much at this time)


3. Do not solve their tasks for them, give them feedback so that they can go back and fix the mistakes/do the work (they will understand their code's flow better than you)


4. introduce dual coding/shadowing/code review among your developers so they learn from each other (less interference on your part)

As some one who is in a similar position, these steps (especially 3 & 4) have been helpful in getting that employee to be stronger in an area they were not comfortable in at first. Instead of shifting the blame onto the "under performing" employee, you should ask why they were assigned to this project given their background, or, if at any point they were aware that their job required them to learn a completely new environment.

You need to do your job.

On the team side, decide whether it is feasible to mentor the underperformer or not. If you think they're willing to learn and capable of being productive and the long-term performance of your team is more important than the short-term costs of a mentoring, then decide to mentor them and inform the team. Assign them tasks that are realistic given their skill level and re-evaluate periodically to see if mentoring is working.

On the CTO side, you need to realistically apprise your CTO of your team's capabilities. If he tries to tell you the task is easy or anyone can learn, respond as follows:

1. You are managing the team appropriately given the resources available. If he has specific advice for ways you could manage the team appropriately, you'd be happy to listen.




2. The team is performing the way it is. It's not getting work done faster than it is. There's no magic whip you can crack. Your employees have the productivity they have and you can't magically make them more productive.




3. Explain your advice about the underperforming team member. Either explain that you've decided it makes the most sense to commit to mentoring them even though that has a short-term cost or advocate that they be fired. If you think replacing them would help, explain that.

Ultimately, you have to tell the CTO that you believe that you are leading the team appropriately but that the team's performance is not sufficient to accomplish the tasks requested in the time desired. Offer helpful options such as hiring more people, reducing the feature set, and so on. Explain to him that asking you to produce a better result will not change your assessment of what your team is realistically capable of achieving.

Whatever you do, do not agree to his claims that the team can produce more and then repeat the cycle of delivering less than the CTO expects followed by ritualistically making unrealistic promises to do better in the future.