How to demonstrate to management that mediocre developers are hurting team [closed]

Solution 1:

Funny nobody told you that maybe you lack of management skills.

Once, I ended up working with people not being able to code a loop after a year and a half of training. I trained them, until they were able to use a full feature web framework, and it took only one month.

Maybe you should get a training.

Maybe you should read a report about you.

I am not saying that to attack you. Not at all. I understand the problem very well, as I failed to manage teams as well in the past.

But don't dodge the ball, you are mainly responsible for what's happening in your team, no matter how much good practice literature you have read in your life.

In that case, stop complaining and get to work. Not as a coder, but as a manager.

Finally, I can be wrong. Maybe you've done everything right. In that case, you can, and probably should, resign. Trying to prevent an airplane from crashing with moving your hands is useless, no matter how strong you are. There are plenty of casual teams that will do miracles with your skills to make the best of their's.

Solution 2:

Does the problem stem from lack of skills or ability, attitude problems on the part of the programmers, or from a corporate culture that doesn't promote a good work ethic?

If it's skills, you already know that there are some things you can't teach. If the company is willing (and it seems that it is), and you can show improvement, I would ramp up the training, and see which developers rise to the occasion. Those who don't you will have to let go. I wouldn't hire additional developers until you know that you will be letting go some of your existing ones.

If it's laziness or other attitude problems on the part of the programmers, you will have to convince your management to back you up on disciplinary actions. Document all problems, as Scott Vercuski describes. Gradually cull away those programmers that cannot rise to the occasion. Let the remaining programmers know that they are expected to learn good programming techniques and best practices, and use them.

Have code reviews, if you are not doing that already. There are plenty of resources that explain how to do this properly. They should not be shouting matches, but rather looked upon as strategy sessions to produce desired outcomes. Discuss the code. How can it be improved? Write some new code in the review, if necessary.

If management is the problem, tell them they are the problem, and show them how they can fix it. But you must be eloquent and persuasive. You must be their advocate. Write a paper about the problem. Make a presentation and show it. Appeal to profit motives.

Finally, be the best leader for your people that you can be. Help them. Keep them unblocked so they can do their job. Part of your job is shielding your people from the politics of upper management and maintaining a decent work environment, so that they can focus on doing the best job they can. In other words, make sure that your people can trust you.

Solution 3:

Documentation is your biggest resource ... an old manager of mine told me "If you don't write it down, it didn't happen.". If your developers give you a written estimate of the time needed to complete a task and constantly (and severely) miss those deadlines it should be documented.

Do you have some sort of timekeeping system? or do the developers log their time? If they state that a problem will take them X number of days and after X days it isn't done you can question why it wasn't done.

To reiterate ... documentation is the key, if you all of a sudden terminate someone and you don't have adequate documentation as to a reason you can get into lawsuit territory. The more documentation you have, it should be readily apparent to management that the junior developers aren't pulling their weight and should be replaced.

Best of luck to you, I'm afraid you're on a very rough road though ... I've been there and it is a long drawn out process.