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

Question

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.

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.

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.

I've been in this situation before and can certainly empathize. What I did was to pare off a small, self-contained task that should take me or another senior dev no more than 2 days or so. For this task, I would create scads of documentation identifying how the solution should be implemented, any database changes, etc.. I'd then sit down with the developer, give them a high-level walkthrough of the task and assign it to them with a deadline of 1 week. At the end of the week, you have something tangible that you can compare their work to: Did they meet spec? How done are they? How many bugs did QA find? Did they break the build or break process in any way?

Once that is done, assuming they've failed, you have a direct and pointed meeting with them explaining how they're not fulfilling their duties. Do the same things one or two more times and, as long as your documenting and communicating up the chain, you should be able to push them out. It may be harsh, but it sounds like you need people to step up and you just don't have the right people to do it.

Also, make sure you get to participate in the interviewing of new candidates.

My advice is this:

If you are a manager, then you must have the rights that go with your responsibility. These rights include discipline of those under you. If upper management refuses to grant you those rights, refuse to assume that responsibility.

You don't have to be that stark to your supervisors, necessarily, but that is the essense of what must happen.

My advice would be implementing a bug tracker and assign tasks. This will show the productivity of anyone of the team. The first time we used it, we achieve to organize the team and measure the time we spend working on tasks. One of the things I liked was the fact that when someone assigned a task it sent an email to the worker and a copy to someone else to check the task.

By the way we used BugTracker.Net.

I wonder how did these people get into the company in the first place:

These developers not only lack skills with programming concepts, but generally ability to formulate a solution to a problem in code.

Simple things like writing loops are tough for them...

You company needs, no doubt, invest more time and effort into the recruitment of workforce, as the the old saying has it: haste makes waste.

Now, once you're in that situation as you describe, finish your report, (as others have hinted) make it concise and underline how much money this costs the company, submit and wait for the best (as you said you "have no recourse in actually disciplining an individual.").