Stack OverflowMaking the most of below-average team members
[+35] [18] Ed Guiness
[2008-09-21 09:11:59]
[ project-management team team-building ]

In an ideal world every software development team would be populated with PhD-level team members, all highly motivated and working in harmony.

But most businesses are not as well-funded and focused as, say, Google or Microsoft, and quite often a legacy of poor hiring practices means that a team of reasonable size (say 10 or more) will probably contain a few members that are distinctly average or below average.

I expect some will say "just fire them", but it's not usually that simple for reasons that are interesting but not immediately relevant to this question (mostly political).

Assuming that the team is bound to contain at least one or two of these below-average developers, what would you suggest is the best way to make the most of the situation?

EDIT: "50% of all programmers are below average"... not true! You could have 9 stars in a team and 1 donkey, but only the donkey would be below average.

EDIT: @Christophe Herreman makes an excellent distinction between below-average team members with potential and those without.

(1) that's why its 50% of ALL programmers. ;-) - Cheekysoft
(1) Maybe he meant 50% below the median. - paxdiablo
.......... :-) - paxdiablo
Think about this - if you have a population of 100 programmers and 99 of them rate 100/100 but one rates 1/100, what is the median and average? - Ed Guiness
hey kids, it was just a gag! but if we're going to be pedants: when i went to school.. interface average; class mean implements average; class median implements average; class mode implements average; - Cheekysoft
well, if you assume a normal distribution... ducks :-) - warren_s
(7) "In an ideal world every software development team would be populated with PhD-level team members, all highly motivated and working in harmony." - This is one funny statement. I see you are not at all familiar with the ideal world. ;) - Till
@Till How can one be familiar with a world that does not exist? :) - Ed Guiness
(4) A world of nothing but PhDs would be a nightmare. We'd all be too busy being enormous brains that we'd never get anything done. ;) - Chris Charabaruk
@Chris, yeah that's right. Just like Google. Oh, wait... - Ed Guiness
Close discussion question, or at least go to community wiki. This is not only a "discussion question", but it's only vaguely related to programming, maybe a management Q and A site would be appropriate. - Mark Rogers
(1) @edg Google isn't just a bunch of PhDs, sorry. They called me a couple years back and asked if I wanted to interview with them. If only PhDs needed to apply, they wouldn't have pursued a college dropout like me. (I got weeded out on the third interview, but they never asked about my education, in any case.) - Dave Sherohman
[+73] [2008-09-21 09:30:26] Christophe Herreman [ACCEPTED]

I think we should make a distinction between those who are below-average because they are still in the process of learning a new technology but are driven and the ones that are just not interested or even not smart enough to do this kind of job or work with a certain technology.

In the first case, you can quickly get a person up to speed by doing pair-programming, having code reviews, or sending them on a course. In the second case (I've been there), it is really hard to get them to be more productive or deliver higher quality code. My experience is that in the end, such a person has a negative impact on the overall functioning of the team and it is better to deal with that asap.

You should try to get them to feel responsible for the things they do. You could for instance set up a Continuous Integration system that notifies them (and the rest of the team) when they checked in untested code or if a code change breaks the build. If they don't feel the heat then, or still don't show any interest, I'm afraid the only thing left is to put them out of the team.

Hire for attitude, train for skills.

Excellent distinction, I will clarify the question. - Ed Guiness
Totally agree. The first thing to do with someone who is not performing adequately is to coach them in their role, or offer training to help them improve. - apathetic
Excellent answer. - Till
(11) Up vote just for "Hire for attitude, train for skills". - Student for Life
@Davide same here - Zeus
(2) I've seen hire for attitude, train for skills fall flat on it's face. The employee was certainly motivated but there was no one with time to train that person. Train for skills is not very realistic for the tight situations described in the question. - Mark Rogers
@m4bwav, in that situation someone with as much skill but a bad attitude will do even more harm. And as with all best-practices, methodologies, advise, ... use your common sense and dont follow any of it blindly - Emile Vrijdags
Upvoted for hire for attitude, train for skills. - Andy Webb
[+23] [2008-09-21 13:04:06] Hanno Fietz

I'll try to summarize the good answers here in hope of a good & comprehensive answer, see if it works:

1. Define "performance" well

First, be sure about your definition of "below average" or, to put it less politely but more honestly, "bad performance". There's been plenty [1] of [2] articles [3] discussing how most performance metrics are of little use in our trade (and in knowledge-based organizations in general).

Also remember that it's the performance of the whole team that counts and if you have someone who doesn't get much code done but is a great guy and keeps morale high and everybody loves him, he is actually being productive. These things are practically impossible to measure and you need a very reliable "gut feeling" and a lot of very open and direct contact with your whole team.

2. Find the real reason for low performance

Once you really have established that members of your team have a negative impact on productivity, it's important to find out why. Do they stay behind expectations because they (a) aren't smart enough, (b) are not yet experienced enough or (c) there are cultural or political issues in your team that get in the way or mess up motivation.

(b) is easy to fix, just arrange for proper mentoring and they'll be up to speed soon. (c) is harder but is also a very serious problem that management alone is responsible for and which should be addressed. (a) really means the tasks they are doing are too hard (yet). Find something easier to do and give them opportunity to expand their capabilities.

3. Almost always, avoid firing like the plague

Firing people in teams of 10 is very, very expensive and might well have bad unexpected side effects, such as dragging down the morale of others. Although keeping bad performers on board although "everybody" knows they aren't contributing can also bring people's morale down, as Jeff Allen [4] rightly points out in the comments below:

Firing boat anchors is a critical part of respecting and nurturing your best performers. If everyone knows someone is not cutting it, seeing them cut loose can make the team fly.

I think, firing people is on the management scale very similar to rewriting code from scratch, it's very tempting (in the sense that it seems straightforward and liberating), but you just shouldn't do it [5]. And then, sometimes, it still helps, which led me to add:

4. It is also important to fix your recruiting process

I basically copied FogCreek's recruiting strategy (apart from the limo at the airport, so far) for my own two companies and have been told by colleagues and friends also working in software development that

"you'll never get enough developers if you require them to in-place-reverse a string in C, on paper, during the interview - I don't know, if I could ... - I mean, who even still uses C, these days"

Which seems right, I never have enough developers. But I'm happy with those that I have, and I hope I'll always have to worry about getting more instead of getting rid of team members.


firing people is tempting? that is not something i ever felt as a manager... - Stu Thompson
Well, by tempting I mean "may look like a straightforward solution", very much like the rewrite, where it is also never true. - Hanno Fietz
Firing boat anchors is a critical part of respecting and nurturing your best performers. If everyone knows someone is not cutting it, seeing them cut loose can make the team fly. - Jeff Allen
Enthusiasm at seeing the team improved or simply fear that they might be next? (I tend to suspect the latter is more likely.) - Dave Sherohman
[+15] [2008-09-21 09:23:01] paxdiablo

I've had PhDs working in some teams and they were useless :-)

However, if you can control the workflow, just make sure each team member gets work suited to their level of competence. That's not hard; it's what team leadership is all about.

Of course, if one of my "minions" suggested that someone on the team was below par, I'd quickly make sure they could show

  1. it was true; and
  2. that they were adequate themselves.

Technical skill is important but it's not the only consideration in running a team.

I've had PhDs in my team too, and they too "weren't the best". - gbjbaanb
"it's what team leadership is all about." You're spot-on ! Mediocre leaders blame their teams, good leaders make do with what they have. - rlerallut
[+14] [2008-09-21 09:52:17] Stu Thompson

In the past, when I made such decisions, before seriously considering firing (which can be a highly destructive experience for the entire team) I would do three things:

  1. Have a friendly, honest, non-threatening chat about the discrepancy between my expectations and their performance. "Constructive solutions" and all that warm fuzzy stuff was the goal
  2. I kept them on more modest projects and tasks, and bumped up the oversight.
  3. Chat with the star performer(s) on the team about the situation. They are sure to know about their colleagues performance, before even I did. My concern was both diffusing any resentment and getting ideas for making the situation tolerable.

Not that this always worked. Sometimes ya just gotta 'go nuclear'.

firing can indeed be a destructive experience, but keeping someone that should be fired is not good for morale either (and budget)... - Xavier Nodet
and hence why my last sentence says "sometimes ya just gotta 'go nuclear'" - Stu Thompson
[+14] [2008-09-21 09:58:22] Umer Azaz

I think having a team consisting of below average or average developers/members is a normal scenario. It is a job the team lead/project manager to get the best out of everyone. Usually every body have some positives and negatives, a bad developer may be bad @ code but can have some other skills like documentation, testing, some other area of interest other than core development which may be useful for the project, etc. Sometimes having a chat with a team member about some lack or failure can make things lot better and produce positive results. Mentoring is also a good way to communicate best practices and overcoming shortfalls. Beside these, periodic code reviews and performance evaluations are a must to keep team running smoothly and mitigate any future concerns.

I agree that this is the normal scenario. Thanks for your comments. - Ed Guiness
also, it can be becuase the "top" coders won't let anyone else play, check your team for destructive and selfish tendencies that are self-reinforcing. Morale makes up a good part of programmer productivity. - gbjbaanb
Absolutely right. Someone who is not in the top 50% in coding might be among the top 1% in testing... If your goal is excellent code, a good tester is often a GREATER asset to the team than another good programmer. - Chip Uni
[+11] [2008-09-22 21:34:50] HLGEM

In general I've noticed several reasons for less-than-stellar performance and each needs to be handled differently.

First and easiest is the person who is still on a major learning curve. In this case, give him or her tasks with a little stretch to the current skill set but not so much that they can't succeed if they try. Provide them with training courses if you can and by all means pair them up with more-experienced programmers if you can. Pick out some things these people need to learn how to do and have them present training to the group on those topics. Make sure they participate in code reviews of more experienced programmers, so they can see how others handle the kind of problems they might see. Tell them clearly where you see that they are and where you want them to be.

Next is the person with the actual skills but who has decided to be an attitude problem. With these folks, clearly tell them what you expect and then expect it. Sometimes these are lazy people who have learned that if they cop an attitude, they will be expected to do less. Don't let them get away with it. Don't fix their mistakes either, send them back every time. Document it when the person doesn't follow directions and when you feel you have given them enough chances, let them go. If it is sudden change of attitude, try to find out why it happened, but my experience is that most of the time, this is a chronic problem and it is best to get them out of your team if you can. When I worked for the government, I worked with several of these people and they hated working for me because I wouldn't let them get away with anything. Even if you can't fire them, this approach often leads to them searching elsewhere for employment where they don't have to work so hard.

Next is the person who is a temporary problem due to some life issues (Grief, divorce, etc. come to mind). See if you can get them some help to deal with their personal problems if they are affecting the job. Make sure you tell that person that there is a problem and that it needs to be fixed. Sometimes all they need is a reminder to leave their personal problems at home. However for grief (especially if it was a spouse or child or other person they lived with), cut the person some slack (assign easier tasks for a little bit or estimate that tasks will take longer than they used to), performance will get back up to snuff as soon as the person can think clearly again.

Finally there is the person who just isn't suited to programming. No matter how hard this person tries to learn, he or she doesn't seem to manage it. Try to steer these people into another career field. This is another group where after giving sufficient chances to learn, you may just have to let them go. It seems cruel to do so (especially if the person has a good attitude and is trying), but getting them out of a field they will never succeed in may be the kindest thing you can do for them.

If I was having a personal problem and you told me to "leave my personal problems at home" I would not see that as a constructive step and I would lose any respect for you as a manager of people. "The beatings will continue until morale improves". - Stevo
Stevo, you will note I said sometimes you have to do this, not that it was my first choice. Some people won't tell you what the problem is or seek help for it. But the work is still affected and they have to be told that bad work is not acceptable. Others don't realize their work has been affected. - HLGEM
[+8] [2008-09-21 09:14:58] Cheekysoft

Remember, 50% of all programmers are below average :-)

I'll get my coat.

Despite the rebuttal in the original question, this is true. My stats get hazy after that, but it feels as if 50% of teams have more below average members than above average members. - slim
(1) Wouldn't 50% are at or below average be a truer statement? - StingyJack
I would say more than 50% are below average. Programmer quality is probably a positively-skewed distribution, meaning that the median is less than the mean. In other words, there are a few really good programmers that affect the average disproportionately, and then masses of bad ones. - dsimcha
I do not agree. I think a sizeable majority of programmers are above average. Programming takes a certain amount of smarts. Most folks near or below average probably would not even be interested in programming because of the difficulty. I think that goes for all technical fields. - PaulG
[+3] [2008-09-21 10:28:28] tardate

Personally I focus on two things:

First: capabilities

I believe the first question to ask, in fact the first obligation of the "manager" is to determine what skills or capabilities your team members bring to the table. Find out what the below-par members can/want to do and try to design the work around them. If you try hard enough, there is usually is some solution that is good for both the team and the individual.

Second: potentials

Everyone is on a learning curve. The 'perfect team' where everyone is at the top of their game, is probably the team that is heading over the top of the hill and on the path to dissolution. If you have longer term ambitions for your group, then you need to be focused on the learning and growth plans - for all team members. All that matters is that the members have potential - if not, for the good of all you should be looking to exit the individual soon.

[+2] [2008-09-21 09:24:09] user11318

Why are these members below average?

If they are below average because they are inexperienced, then try to arrange a mentoring experience for them. If they are below average because they are incompetent, the best option really is to fire them. Bad programmers frequently contribute negative productivity. You can't trust anything they do, and fixing their mistakes takes more work from others than you can get in useful work out of them.

If firing is not a politically acceptible option, then the first thing to try is to hope you can improve them. Make them read books, get mentored, etc. If that isn't working out, then do your best to find them something useless to do where they don't take up too much time and don't do harm. For instance locate a repetitive task that is within their abilities. (eg Running integration tests.) Or a task you can ignore. (eg Writing documentation for internal use, that you're sure nobody else will actually look at. Just be sure to have someone else write documentation for anything that is important.)

[+1] [2008-09-21 09:18:26] Evil Activity

Depending on the persons that you have to work with, you might want to consider a good system for code-reviewing, where the code that they wrote will be reviewed by a more skilled person. This is a good practice for any team though, so doesn't go for just this case.

Another good way to deal with this is Pair Programming [1], where "One types in code while the other reviews each line of code as it's typed in. The person typing is called the driver. The person reviewing the code is called the observer[1] or navigator. The two programmers switch roles frequently."

The website of Joel on Software had some article on it, discussing some of the positive and negative experiences with Pair Programming [2].


[+1] [2010-01-11 17:38:02] JB King

There can be a great deal of diversity to the work of a developer that I think shouldn't be lost here. Here are some of the roles I've had to play over the years:

  1. Troubleshooting issues - Debugging problems to figure out why is something not working as expected. This doesn't require writing a lot of code usually, but there is a lot of investigative skills used here.

  2. Solution design and planning - How to build big systems and structure projects can require a slightly different set of skills. While this is the next step after figuring out why something doesn't work, it requires some creativity and other skills.

  3. Analysis of solutions - There is usually more than one way to do something and understanding the trade-offs for each isn't quite the same as merely pinpointing the issue. Also, interpreting designs can be important here as well.

  4. Implementing a design - This is the actual writing of code, yes. Of course this should be in here somewhere.

  5. Presentation skills - Sometimes one has to show to an end-user or tester that something was done or explain how a feature is to be used and this has its own separate skillset to bring in at times.

Most people will be good at some of the above, so it can be worthwhile having those strengths utilized as much as possible. Optimizing this isn't easy and is likely rare done.

Why does the worst team member's performance have to be considered bad? In a relative sense, yes there is someone that would be at the bottom usually. However, if that person's work is good and the employer is happy with the result, isn't that what counts at the end of the day?

[0] [2008-12-15 19:14:35] edebill

Some below-average team members actually suck productivity out of their team-mates. Those developers can't even be safely assigned to minor tasks, because while they're getting a small thing done they'll keep people from doing the large things.

That calls for intensive counseling, and possibly firing if they can't improve.

If they're just slow workers, then the main problem is that they need greater supervision to get their work done, so they put a larger burden on the team's leadership. If you've got that bandwidth, you can just be careful how you schedule them and give them that extra supervision they need. The ones who are motivated and capable will quickly outgrow that need, so it's not a big deal.

We all want to work with the great people who make everyone around them more effective. The flip side is that we all need to avoid working with the people that make everyone less effective.

[0] [2009-02-11 17:09:31] Stephan Eggermont

In an ideal development world the development team will not always work in harmony and be fully motivated. In order to handle the changing context in which the development has to take place, you need people in the team with different value systems and preferences.

It is unlikely that they will all be equally productive at the same time, but that is the overhead you need to accept and welcome in order to be able to better adapt to changes in the environment.

Take a look at Kolb's learning styles,

and Myers-Briggs Type Indicator

Take a look at Gerald M. Weinbergs books on Quality Software Management to see the relationship with conflict, blaming and change.

You might want to take a deeper look at what the different MBTIs value to see why that isn't the case. - Stephan Eggermont
[0] [2009-06-30 10:01:45] Gerhard

Not being a great programmer and needing constant attention is not always the same thing.

If a guy is not the best programmer he can still be useful working on the less critical components with a more experienced guy to help.

A programmer that sucks up other peoples effort on the projects might need to go.

This can also depend on the size of the project. In a team of 30 programmers a few bad apples is not a big problem because you can use a strong core team for the most important aspects. For a small team of 2 to 5 people a bad programmer can suck all of the energy out of the project.

[-1] [2008-12-13 23:52:32] louism

i wont re-iterate what other people have said, no need. i will just add a few more tips to the buffet:

  • for starters, how did this guy even get into the organisation? were you doing programmer tests before hiring? (see:

  • try 'goal settings' (from a book called The One Minute Manager). i have a white paper on how i use them:

  • understand there is a difference between 'teaching' and 'coaching'. you arent so much trying to solve a person’s problems as 'build them up' (through encouragement, a documented concrete plan for development based on facts/measureable results). Manager Tools has a podcast on this:

  • consider reducing the team-member's salary (e.g. by 10-20%). why? this will placate senior managements concerns that the person is a non-cost effective resource (i.e. "why are we paying for someone who cant do the job?"). the under-achiever may not be happy with his and leave (problem solved), if they do stay and tolerate it - its a good demonstration of a willingness to learn.

  • be careful not to remove 'catalysts' - this is someone who doesnt do much work himself, but helps others do theirs better (the whole is greater than the sum of its parts).

  • RE: dont fire - i 100% agree. firing someone for underperformance is a last resort. this is different from 'encouraging them to leave' though. imagine what the other team members will think if one of their own is fired? they could even start looking for jobs elsewhere because they see its an insecure environment, and you could potentially start losing the good programmers. on the other hand, if he leaves for a job elsewhere, well then, he is just moving onto greener pastures.

[-1] [2008-09-21 09:21:31] Richard
  1. Unified Process
  2. Daily Scrums
  3. Regular team code/design reviews.

[-2] [2008-09-21 09:35:53] Slace

I find having a very strict set of rules help to reduce the problems low-skilled team members.

We do this by having: 1) a strict design pattern (eg: MVP) 2) strict check in policies (code analysis, code tracking, etc) 3) frequent scrums 4) extensive documentation

I recently headed up a large dev team which had 1 developer in it I had previously worked with who was definately below average, but by having the above in place his impact on the project was actually positive. His work wasn't the best, but it was not as bad as the previous outings from him.

Although I think you could have a valid point, I hope this answer filters to the bottom because of your "strict rules" suggestion, which I dislike personally and also think is more often than not counter-productive and bad for morale. - Ed Guiness
I would agree with edg's comment. Having strict rules/process will help the poorer performing team members. However, it will restrict the better programmers and introduce a large overhead which may harm the team's performance overall. - David Dibben
I don't think those "strict" rules are that strict. And if your "better" programmers feel constrained by these rules, then perhaps it's time you re-evaled their actual performance ? Really good team members drive the whole team forward. - rlerallut
[-14] [2008-09-21 11:38:10] Maxim

Just fire them.

explain why. your answer comes off as flippant and uniformed. an explanation would change that. - Stu Thompson
Don't fire me, pleaaaaase :(( - mannicken
A good manager can figure out the skills that a person has that will be most helpful, and in that case you may have got something for a very good deal. Being in a habit of just firing people might not always work out for the best, for instance it'll take a few months to figure out that someone just sucks every time, and that can be wasteful. - gtrak