How to demonstrate to management that mediocre developers are hurting team

Question

I am in the precarious position of "managing" a team of developers at a small company. I say "managing" because although I assign work and provide feedback on their performance I have no recourse in actually disciplining an individual.

Some of my team I don't know what to do with, they are unable to work on their own, require massive amounts of hand holding and when left along generally wreak havoc on the project usually to a point of failure. When failure does occur I am left to salvage the project and push it (some times limping) across the finish line.

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 let alone designing and implementing a solution to a problem.

We have tried pair programming, offering to pay for classes, buying books, allocating time during the work day to training and even taking whole days to train the team.

The other senior developer and I do not know what to do, but our productivity is being throttled with having to deal with these individuals day to day. Management is forcing us to give them work and their major complaint is how things aren't getting done quickly enough.

None of our management team works directly with any of the developers other than myself and the other senior developer. Management is non-technical and believes every developer is created equally, and that we obviously need more people on these projects to get them done faster.

I am already preparing a document with sections from "The Mythical Man Month" and "Code Complete" to send to management to hopefully illustrate with statistics that what is really hindering us is having to drag the mediocre folks through the development cycle.

What other resources are out there? Books, articles, general advice anything would be helpful.

Answer 1

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.

Answer 2

Sounds like you are on the right way.

If you show them numbers tough, they will see things clearer - create a coding an assignment and give it to several different programmers to each work on by themselves. Make it testable by yourself.

Keep details of how long each one takes, how many defects the code produces.

Show the numbers to upper management, they should now be convinced.

Answer 3

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.

Answer 4

The Book

Code Complete: A Practical Handbook of Software Construction by Steve McConnell

is a good source that can help to learn best practices.

Requiring each developer to read and learn this with discussions could help a little but the biggest thing is to quantify the results. Take salaries of yourself and the rest of the team then calculate how much extra time you have to spend fixing others mistakes with the added cost of the developers messing up things to begin with.

Then show how a team of better developers can improve ROI.

Answer 5

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.

Answer 6

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.

Answer 7

Keep the report concise. Do not make it wordy. Put it in terms of how much money they're losing on this one.

Answer 8

We have a tool now that measures the complexity of our code modules. It runs on our PL/SQL modules, but I believe that there are tools available on other environments.

There are various sections throughout, but it was quite an eye-opener to management when several of our key modules were marked as 'untestable'.

We combined with an imact analysis tool that help highlight duplicate functionality, and approached packaged this all up as an assessment of 'technical debt'.

As we could present this on a module-by-module basis, it would have been easy to identify the perpetrators (we did, but didn't report it). As it was, the organisation was more geared to improvement going forward than finger-pointing.

(As an aside, all code is now submitted for review, and an accompanying code-analysis must be supplied. Things are definately getting better here.)

Answer 9

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.").

Answer 10

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.

Answer 11

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.

Answer 12

This is simply not possible unless you have good traction with the management. In my experience, if you try to force it, you might get into trouble.

Answer 13

You mentioned that for your team you "provide feedback on their performance".

So:

1. Sit down with your team.
2. Hand them printouts of this page, and tell them you posted it about them.
3. Let them read it.
4. Ask them to help you solve the problem.
5. Listen and write it down.
6. Take that to your management team.

Answer 14

Peopleware is another book that should join your list.

However, when I read it I did not find it practical because no one in the company wanted to try its recommendations.

Answer 15

I read this a while ago about encouraging programmers to want to be the best.

Nerd Herding

Answer 16

Just an idea.

I assume you use the source version control systems like SVN. So make the policy of reviewing commits and rejecting bad ones. Then just show the other managers statistics of rejected commits to prove that mediocre developers are much expensive for the company.

Answer 17

Here's another idea for you: Don't fix what they break. Send it back for rework in an email by telling them what is wrong and how to fix (only in general terms) and cc managment. Make sure to note for managment's understanding exactly how this will impact your final deadline. This creates the documentation of performance problems for you and some of them mayl stop being as bad when they have to fix their own messes.