Things to take Control when Team not doing Well?

Question

I'm working on an ERP Project where two Members(Freshers) in my team are not performing well (for small tasks). Their work is littered with bugs and other issues. As I'm a Team Lead in this Project, I end up having to write their code/tasks. This may be creating a heavy burden for me as I have to speed up things everyday to do my work and then theirs!

What would you do in this situation.

Actually, I'm feeling comfortable in this position as I'm learning many things, but some times I cant tolerate this!

Answer 1

In my Team two Members(Freshers) are not performing well (for small tasks), always bugs, issues etc

Here are my initial questions where I'd start if I had this situation:

• Are they aware that they aren't performing well?
• What kind of feedback is being given to them so that they are aware of the situation?

The first step in this is identifying the problem. Do they have problems because they aren't proficient at the tasks? Do they have problems due to lack of motivation? Identify the root cause though you may be surprised at what happens if they are given an opportunity to do better knowing what the expectations are.

Answer 2

Welcome to the world of team leadership. The first thing you need to do is to accept that as the team lead you can't do as much of the real work that you are used to doing. Now you are responsible for everything instead of just the components assigned to you. Thus, you need to give up assigning yourself as many components as you are used to and assign them to someone else. Then you will have time to go over everyone's work.

Also, you are doing yourself no favors by redoing their work. If you do their work for them then they aren't going to get much better throughout the project and you will have to keep redoing their work for them. Your goal should be to figure out how to get these people to an acceptable level of productivity. If that means having them redo their work 20 times until they understand how to do it correctly then that's what you should have them do. As long as you are clear with your expectations to them. If you try a few times and it isn't sinking in them assign someone else to help them as maybe you aren't communicating your thoughts clearly enough to them. You also need to document what steps you have taken to get these people to perform as you will need this information if it turns out that the 2 are utterly useless and untrainable and you need to get rid of them.

Answer 3

As I'm a Team Lead in this Project, I end up having to write their code/tasks.

This is not the right solution. It keeps the problem from being as visible as it needs to be. Your job is to make sure that the work is getting done, not to do all the work if it needs improvement. As many people have pointed out, the programmers might not know there are issues. If you have always done this for them, maybe they think it is part of the natural flow to have someone higher in hierarchy to review and make changes in their work. You need to talk to them directly about the work they are producing. Explain why you feel their solutions are not acceptable.

Answer 4

Do they know their code has bugs? Are you just sighing and fixing them? Or are you putting the tasks back to them, saying "this doesn't work if you leave the City blank" or "this doesn't check for null" or whatever the bug is. At a minimum you need to do that. If someone (you?) has assigned time-sensitive bugs to staff you can't quite rely on, you may have to compensate by fixing it for them. In that case you should still tell them "this was wrong and this is how I fixed it."

This might just fix it - knowing they have a problem may take care of it. But if not, you can look back a week later and say "I assigned you 23 things and 17 of them came back not quite right." That is the start of a conversation that should lead to improvement. Or you might realize that actually most of their stuff is fine and they just need a quick conversation about input validation or your coding style or some other small corner of the work they do.

Answer 5

Reduce the scope of their work, give them small measurable and acheivable tasks. Invest time 1:1 helping them in a non-confrontational way.

Ensure they understand the fundamental aim of your project and the feature(s) they are working on, ask them to write unit tests (this is a good way of getting to know not only the code but the requirements).

Ask them to get code reviewed by you or other senior colleagues before the check in, and when you find issues try very hard to be constructive and not personal. E.g instead of saying "your code does not work" say "this doesn't actually work in case X" - in other words give specific feedback that they can act on.

They are almost certainly as frustrated and as unhappy as you are and they may also be panicking because they know they have not met expectations. Investing some time now and reducing your expectations in the short term will pay back in the long term.

Ultimately the success of your team is your responsibility, and I'm afraid that you are going to have to work very hard for a short time at least to get them up to speed.

You must also document what you are doing with them and what issues you are having. This is because if they don't improve even with a lot of help you are going to have to take more formal steps with yor boss or the HR department. If it gets that far you need to prove you have been more than fair with these guys.

Answer 6

Some things to ponder. If you do everything for your team, without letting them know what is expected you can unintentionally give them Learned Helplessness.

One thing that has worked for us at my current company is to create a checklist of what it means for a particular task to be done. In our case, it's a broad list of things to think about as well as specific TODOs and stick them up on a whiteboard in the team room (or print it off and stick it in people's cubes if you're in cubeville) where everyone can see it. Ours has items like:

• Remove hard coded strings and make them configurable where appropriate.
• Private / public accessibility.
• Code cleanup (make your names reveal intent, remove repetition, no unused code, no commented out code)
• Test coverage (and tests passing!)
• ALL acceptance criteria for this feature are passing.

Our full list is longer than the bulleted list above and your list of course, will be different. The point is, it's a list of concrete expectations about what they need to consider, and you can point to an item on the list and say, "you haven't done this yet." After some period of pain, the team will learn that quality is everyone's responsibility, not just yours.

Answer 7

It seems that these two "Freshers" (or newbies depending on slang) need a bit of 1 on 1 mentoring. That's what pair programming is about, and is the most effective way of training someone to be an effective programmer. The fresher needs to have their hands on the keyboard, and the senior needs to direct them and help them think through the process a bit.

That senior doesn't have to be you. If there is someone else on the team that has some more experience, pair them up with the freshers (alternating each day or each week) between them. If they listen, follow instructions, and ask good questions, they'll get it.

The pair programming doesn't need to be a permanent solution. Just long enough until their efficiency is good enough.

Answer 8

Take it up with your boss. This will eventually be his problem any way, so the sooner you notify him the better.

Answer 9

Are they fully aware of & comfortable using the tools that more senior team members do? It may be as simple as giving them more training with the debugging tools/procedures that the rest of the team uses. Can someone sit down with them, go through their process, and pinpoint where they're hanging up?