I manage a small team of developers on an application which is in the mid-point of its lifecycle, within a big firm. This unfortunately means there is commonly a 30/70 split of Programming tasks to "other technical work". This work includes:

  • Working with DBA / Unix / Network / Loadbalancer teams on various tasks
  • Placing and managing orders for hardware or infrastructure in different regions
  • Running tests that have not yet been migrated to CI
  • Analysis
  • Support / Investigation

Its fair to say that the Developers would all prefer to be coding, rather than doing these more mundane tasks, so I try to hand out the fun programming jobs evenly amongst the team.

Most of the team was hired because, though they may not have the elite programming skills to write their own compiler / game engine / high-frequency trading system etc., they are good communicators who "can get stuff done", work with other teams, and somewhat navigate the complex bureaucracy here. They are good developers, but they are also good all-round technical staff.

However, one member of the team probably has above-average coding skills, but below-average communication skills. Traditionally, the previous Development Manager tended to give him the Programming tasks and not the more mundane tasks listed above. However, I don't feel that this is fair to the rest of the team, who have shown an aptitude for developing a well-rounded skillset that is commonly required in a big-business IT department.

What should I do in this situation? If I continue to give him more programming work, I know that it will be done faster (and conversely, I would expect him to complete the other work slower). But it goes against my principles, and promotes the idea that you can carve out a "comfortable niche" for yourself simply by being bad at the tasks you don't like.

I want to clarify that I'm not trying to address this issue due to a grudge, or that I have a "chip on my shoulder" as was mentioned. I'm looking for advice on how to keep a well-rounded team, which is happy and motivated. By observing the variety of answers to this question, it seems like there are a lot of different opinions on how to achieve this.

  • 15
    Do you know everyone on your staff prefers programming over the other tasks? I know at a company I used to work for we had some that preferred debugging existing apps while others preferred writing new code. Then some preferred working on our web apps while others preferred working on our legacy system.
    – programmer
    Commented Jun 11, 2012 at 13:43
  • 12
    How has he show poor communication skills? By not fitting into your mould?
    – James
    Commented Jun 11, 2012 at 14:58
  • 6
    @EvanPlaice Again, what's with the the "personal problem" attack? I have said in the question "Its fair to say that the Developers would all prefer to be coding". Perhaps this sentence wasn't clear enough and introduced doubt so let me clarify - I've spoken to the devs individually, and they have told me they enjoy working on programming tasks more than the other tasks. If this weren't the case, I honestly wouldn't need to ask this question.
    – djcredo
    Commented Jun 12, 2012 at 6:41
  • 2
    @djcredo I didn't mean it as an attack. I'm saying, I think you're asking the wrong question. Seeking to make things more equal according to your personal standards of an 'ideal' team is superimposing your will on the team. People, especially talented (read strong willed) programmers don't like being toyed with. If, as you say, you're working with skilled/talented people then the top-down approach may backfire. Instead of deciding for the team why not ask them directly what needs to change to better enable communication among the team. Commented Jun 12, 2012 at 19:42
  • 6
    Why is "carving out a niche for yourself" a bad thing? Do you want the best neurosurgeon you can get to take out your brain tumour and the best cardiologist you can find to fix your enlarged aorta, or do you want the same guy who's okay in both fields but not excellent in either to do both things for you?
    – GordonM
    Commented Aug 25, 2012 at 22:01

18 Answers 18


It sounds like you are placing too much effort on having well rounded individuals and not enough effort on having a well rounded team.

There is nothing wrong with being good at something--in fact, that is probably why he was hired! You should be thankful to have someone who is good at programming to begin with.

You stated:

... it goes against my principles, and promotes the idea that you can carve out a "comfortable niche" for yourself simply by being bad at the tasks you don't like.

If he was a mediocre programmer, then I'd agree. But you didn't say that. You said he was a good programmer. He's not being bad at the other tasks to get out of them--he's merely focused his efforts on becoming a better programmer. There is nothing wrong with that.

As a manager, it is not your job to make sure that everyone is "well rounded". It is your job to make sure that s*** gets done. And you're not doing that. In fact, you're making decisions that are stopping things from getting done.

Whatever problem you have, you need to get over it--you are making your team less productive.

  • 23
    So if the lone ranger programmer gets hit by a bus you better make darn sure his communication skills were good enough to document what the heck he was doing and where at in his project he was.
    – programmer
    Commented Jun 11, 2012 at 14:02
  • 8
    @JasonHolland, there's a difference between "Good" and "Good Enough." As long as he's good enough, there's no reason to push the issue. The op is seriously considering hurting the productivity of his team because he doesn't think its "fair." (Remind me again, who said the world was fair?)
    – riwalk
    Commented Jun 11, 2012 at 14:09
  • 14
    @JasonHolland, the op also said, "If I continue to give him more programming work, I know that it will be done faster..." That tells me that that guy needs to be programming. The op has a chip on his shoulder, and that's the real problem here.
    – riwalk
    Commented Jun 11, 2012 at 14:32
  • 11
    No chip on my shoulder - I'm simply asking for some management advice in an area I'm currently weak in. I guess I'm trying to strive for fairness to promote team morale in the long run, even if this means sacrificing some of the short-term delivery potential. You make an excellent point that investing towards being an excellent programmer, he should be rewarded for his efforts, so I've accepted this answer.
    – djcredo
    Commented Jun 11, 2012 at 14:48
  • 11
    @Stargazer712, "The op has a chip on his shoulder, and that's the real problem here." That may be true but look at it from the perspective of the "average" programmers that are being railroaded into non-programming tasks because of one guy that has "above-average" programming skills. I would argue that this manager is not doing his job of professional development for the others. Maybe the "above-average" is more skilled because he does more programming? Maybe the other "average" programmers would become "above-average" if given more programming work, future projects would get done even faster.
    – programmer
    Commented Jun 11, 2012 at 14:55

You are catching some heat here in the other answers for your decision to "do something" about this guy, but I fully get what you are saying. If the other team members "would all prefer to be coding, rather than doing these more mundane tasks" then they are going to be annoyed that you are rewarding the bad performance of the poor communicator by giving him just the tasks that everyone wants.

Imagine you are one of the "good communicators" on the team who's skills are comparable to the dev in question. You handle calls, work with other non-IT staff who barely know a mouse from a keyboard, write up plans for user sign-off, and more, all because your boss says to do it. The grumpy dev, in the meantime, because he has "poor communication skills", gets to sit back in his cube all day ignoring the users working on the "fun" stuff only.

Now you said that the grumpy dev has "above average" skills, but you didn't say he was the best. This means that maybe 1/3rd of your team, those good communicator devs who are the grumpy dev's skill level or above, are all feeling pissed off.

Is it worth loosing some productivity from your BEST PERFORMING STAFF because they are annoyed with the grumpy-dev? You'll have to decide.

Unless you want to fire the guy, I suggest you take one of these approaches:

1) Mentor him to be a better communicator. Only you can tell if this is feasible. You might find just holding his hand a little more might help. Some people are just terrified of formal business interactions and express it by being pissed off when asked to do it.

2) Incentivize the "good communication", either with money or other benefits. Make it clear that you actually value good communicators and then your devs won't be so annoyed, but the reward has to be real & meaningful. "Lunch with the district manager" won't cut it. Neither will an "star player/kudos/attaboy" award that's just a piece of paper. Its gotta be extra money, extra leave, some flex time, some serious recognition with higher-ups who control pay raises, etc.

  • 11
    He actually mentioned that the poor communicator was a better performer. Why would you advocate Rewarding this guy's good performance with a less well suited job? I'm a huge advocate of the concept that everyone has their strengths and should play to them. If I'm soft in one area, I'd hope the manager would have the ability to round out the team with someone who was strong in that area, and then NOT have us switch jobs!
    – Bill K
    Commented Jun 11, 2012 at 18:49
  • 3
    @BillK, "However, one member of the team probably has above-average coding skills". He didn't say he was the 'best'. I took a stab and said that he's better than 2/3rds of the other devs. That leaves 1/3rd of the devs who are as-good or better than this guy, who have to do extra work that isn't as fun as what he gets to do all the time ("all prefer to be coding"). How would you like it if one of your coworkers said "I don't like running Unit Tests so you have to run all mine for me"? You'd get annoyed pretty quick. This guy's bad attitude is getting him a reward (less non-coding tasks).
    – GHP
    Commented Jun 11, 2012 at 20:31

First of all, putting blame on your team members... denotes poor managerial skills.

I mean, if he really has poor communication skills, I'm very sorry for his social life, but really, at work this isn't as much his problem as it is yours. And let's face it, he could actually just be bored by your dull working setting, or having private problems influencing his performance, or being secretly plotting to kill you all.

Communication takes at least two, and after all, the one with poor people skills could be you. Nevermind the rest of the team members getting along pretty well, they could all be compensating (even unknowingly) for some communication deficiency you have and blissfully ignore.

And anyway, don't go around asking the internet about people that's sitting three desks from you, go to the chap and ask him if there really is anything wrong and if it can be worked out. (or something dull that can be optimized or improved)

Maybe he just hates his desk position (is he facing the lavatories?) and this sets him in a bad mood.

Hint: listen to the answer, like he's a sentient human being, not a human resource.

(e.g.: try explaining him in detail the need of certain practices and the meaning of certain decisions, some people dig details, as they give them a sense of having a captain that isn't driving the ship into the cliffs)

  • 11
    -1: He's not blaming anybody. He's identified that one guy is poorer at communicating, and consequently he managed to dodge some of the more boring jobs that other have to do. I'm not sure how you conclude that this denotes poor management, or the OP struggles to communicate... That said, I totally agree that speaking to the guy in question should form part of any solution.
    – cjmUK
    Commented Jun 11, 2012 at 15:05
  • 1
    @cjmUK What this answerer is pointing out is that lacking all of the information it's hard to make a determination. As an example, my wife used to work for someone who thought my wife was horrible, now my wife works with people and is considered a high performer. So is my wife the problem, or was the coworker the problem?
    – Paul
    Commented Jun 11, 2012 at 16:52
  • 4
    -1 I think it's unecessary to say I have poor management skills because I'm blaming people. He's a nice guy and perhaps there is a good reason why he is less communicative. My actions in dealing with this matter are two-fold - a) attempting to remedy the situation with him, and b) deciding how to allocate work based on the team's past performance. I'm "asking the internet" for help with option b)
    – djcredo
    Commented Jun 11, 2012 at 18:24

People are different. As a manager, you need to treat people differently (but fairly!) to get the most out of your team.

That said, it's probably good for the developer with poor soft skills to work on them. I would figure out what non-coding thing the developer enjoys (or would like to do) that involves more of those soft skills. Get them engaged on that task, and ideally they'll improve the soft skills as a side effect.

People often aren't bad at something to get out of work; they're bad at it because they don't enjoy it or have an aptitude for it. You can't help the latter, so work on the former.


30/70 split may be where all your problems begin. I've never seen developers happy with split like that.

I've seen developers being comfortable with 10, 15% other work (and been happy myself because it's fun when the dose is right) but 30% is too much. I'd rather think other team members prefer not to speak their mind than there is only one who dislikes "30% other work".

I also think it is important to adjust your "productivity math" to more realistic figures. It will never add up to 100% because of inevitable losses at "context switches".

  • 30+70, summing up to 100% productivity when switching between programming and other work, will never happen in real life; it is more likely about 20+50 or even 20+40. Context switches are especially painful for software developers - if you're interested, check this article for a nice explanation of why is that: DON'T WAKE UP THE PROGRAMMER!
    Programmers who value their productivity would naturally be unhappy about losses like that.

As for running tests part of job, did you consider passing it to testers? The fact that programmers can do it (I think any experienced programmer should be capable of that) does not mean they should. Testers can do it too, and they do it better, and they won't suffer productivity losses at "context switches".

Another point that makes me wonder how you utilize QA resources is your mentioning of Support / Investigation. Professional testers I used to work with tend to have "first say" in stuff like that.

  • As an ex-tester myself, I understand them pretty well - production issues have been to me (as a tester) an invaluable source of data to learn about testing coverage ("have this issue been properly covered by my tests?") and for defects prioritization ("okay it's been covered by tests and reported before release, but did I set the appropriate priority / severity back then?").

It's quite easy for a good tester to find out when to pass the support issue investigation to developers, and this does not happen very often. Reasons to overload developers with this simply escape my mind. As I already wrote, they sure can do that (I'd generally expect senior developer to know how to do anything QA does) but that does not mean they should.


I have 2 things to say on this

  1. Have you recruited a coder or a software developer?
    When you are considering a software developer all the things you have mentioned are part and parcel of software development.You just cannot ignore any these unless you have recruited for just a specific task. IMO 50% of total software development is coding rest all is design,analysis,testing,documentation,etc.

  2. No one is born perfect.
    It just cant be that you can find a person who is good in everything. You have to make them struggle and make them learn things.

As manager you have to get the best out of them I agree but in long term running you might face problems.Assign them light tasks so that they tend to get a grip of it. Get out them the feeling that I am not good at this/ I cannot afford to do this. Most of all treat everyone equally that will get the most efficient output from your team.

  • Yeah, "coder" vs "software dev" is a great way to frame it. Of course we all just want to write fun code. But doing all the other stuff that goes with it is actually why most of us get paid. I can off-shore coders instantly. Off-shoring the software devs who understand the existing business domain is much, much harder.
    – GHP
    Commented Jun 12, 2012 at 12:43

If everyone on your staff has the same title/job description and the job description includes everything you listed then this programmer needs to have these other skills sharpened by getting assigned more of these other non-programmer tasks. Likewise your other staff will not have their programming skills sharpened if they continually have to work on non-programming tasks (use it or lose it).

But I still think that your main priority should probably be meeting your deadlines (which you might still be able to do while distributing the work evenly).

EDIT: If you have a small team it probably makes sense to have all the members be able to wear multiple hats. If you have a team that is large enough, it probably makes sense to have groups that specialize in different areas. From your post it looks like you don't have a large enough team to have groups of specialists.


It's not clear from your original post what exactly is lacking about this dev's communication skills. A lack of interest in going to meetings or doing planning/coordination type work (for example) doesn't necessarily indicate poor communication skills. Maybe the dev simply feels that this type of work is manager work and cuts into his productivity as a dev? Or maybe he feels that there is too much organizational overhead and this is a form of protest against what he feels is just overall wasted time? After all, the opposite problem where people talk all day and never get anything done is also pretty common in the office.

It's important that you speak with this dev in a non-confrontational way and try to figure out why he avoids the non-programming tasks. It's probably not a single reason, he may have as many different reasons as there are different types of tasks. Make sure he understands that the purpose of the conversation is so that you can learn how to effectively improve team productivity and job satisfaction for all team members (you're not out to get him). This is a time for you to listen, and not to argue or try to address his concerns with knee-jerk reactions. You should probably also meet with the other team members, maybe they are totally fine with letting this guy do the heavy dev work while they focus on the chattier side of the profession.

After this meeting, spend some time thinking about the conversations you had and try to consider this employee's perspective with an open mind. Maybe your initial feelings were correct and he is lacking some important skills which you should push him to develop. Or maybe he made some valid challenges to your assumptions. Maybe you can work with other teams to formalize some processes and reduce the need for redundant communication. Maybe other teams aren't pulling their weight and you need to have a friendly chat with their management. There are many possibilities you may not be considering.

Finally, and most importantly, have follow-up conversation with individuals, or a team meeting if it is appropriate. If you've identified real organizational problems which are within your power to affect, tell your employees about the actions you are going to take to improve their work situation. If you still believe that the individual employee is in the wrong, sit down with him and explain what changes you need from him and why. Devs do tend to respond well to logical/practical explanations. "It's not fair to your peers to give you all the fun work. We'd like for all of you to be pure devs but that's not the reality of the situation so we need to share the burden of the crappy work."

Of course, if this guy is just a grumpy jerk, refuses to tell you why he is unhappy, will not respond to reason, and is not well respected by his peers...well...it's time for the Performance Improvement Plan.


Although you are trying to manage a team and want to keep everyone motivated (having a sense of fairness helps), but are you sacrificing the project by not having your best programmer programming? I mean, this is the point isn't it.

Aren't you afraid of underutilizing and/or risk losing your best developer? Your job is to try and relieve these types of duties from everyone.

Being treated equally doesn't mean you treat everyone the same. If the others want to slack off the non-programming duties in order to be assigned more programming tasks, aren't they running the risk of being good at neither?

EDIT: Other than your personal feelings, you haven't identified a problem. At some point the lack of communication hinders a programmer. Others will show resentment and their work may suffer. So far, you seem to be the only one having a problem. Unless there is something else you're not sharing?

EDIT 2 Eventually, everyone is going to ask for a special favor. This person does less communicating and more coding (which he should by all accounts). Someone else wants to come in a little later. Another will need to skip a meeting to fulfill a deadline. A graphics person gets a bigger monitor. When you put too much emphasis on keeping score, you forget what is important.

  • Nobody said he was the best programmer. And even if he was, there is nothing to say that requiring he fulfils a broader role is wrong. I agree that being fair doesn't necessarily mean treating everyone as clones - but there may be a middle way, where people are given tasks that suit and interest them, but where they all muck-in with the less glamorous tasks to some extent.
    – cjmUK
    Commented Jun 11, 2012 at 15:34
  • 1
    @cjmUK - and nobody said the other team members had a problem with this. See Edit 2.
    – JeffO
    Commented Jun 11, 2012 at 19:44
  • 2
    @Jeff O "Its fair to say that the Developers would all prefer to be coding". Sorry, but if the other devs don't have a problem with the guy in question now, they will eventually. djcredo is being proactive in trying to get this under control before it goes that route.
    – GHP
    Commented Jun 12, 2012 at 12:40

I'm a grumpy linux admin who does a lot of scripting, and it has been noticed that I have poor communication skills. I sound a lot like your guy. In fact, that's the only area I get dinged on in performance reviews. Back on the other hand, I'm continuously leading my team in innovation and problem-solving, and have created and led the way to the new platform that we're rolling out and have saved my team a lot of time and my company a lot of money by being allowed to be myself.

My former boss was asked his family/wife AND our company's senior management to leave his position .... simultaneously. He worked tirelessly to balance responsibilities fairly and took on a lot of load himself. During any interaction with anyone outside of the department, if there was a communication misunderstanding that got back to him, he was fast to, ah, punitively correct it. He was poor at "managing upwards," so our team was the last to get resources until it was an emergency, and then the company overpaid vendors with slick sales pitches for untested hardware without consulting the team that would be using those tools. In an effort to create a "well balanced" team, he micromanaged our task lists and tried to balance out tasks so that team members could improve their skill sets in areas where they weren't great, which resulted in a LOT of broken code or poorly architected implementations. While people other than the author were specifically assigned support tasks for that broken code so that they could "learn" -- the poorly architected implementations, code, and tests created a lot of poor goodwill between team members and actually increased occurrences of the "blame game", which is a fast route to a toxic team state.

My current boss is a calm, collected individual who came in from the junior admin role and has worked his way up. He makes good decisions and relies heavily on team members to set their own priorities. He is an excellent communicator and reacts calmly and in concert with his supervisor to any communication problems, ideas or needs expressed by my team. He "works upwards" tirelessly. He's slow to make major architectural changes, and consults thoroughly with the entire team before making changes to our environment and is comfortable with relying on the specialties of our team members.

Under the new manager, our downtime has dropped to almost zero (which has also dropped the percentage of time that we spend on support tasks from about 40% to about 10%), our team's satisfaction has gone through the roof, and we're on track to have moved from a 'break the bank on new hardware every three to five years' to a continuous acquisition plan that should save the company about a cool million a year over five years. That plan was a grassroots program that never would've happened under the previous manager but was actively pushed to senior management by the new manager and depended on finding a LOT of synergies in the team's skill sets. We've been told informally by the CIO that we're now the only team in the company that really "has their shit together" and that he's going to interfere with our working environment as little as possible and shuffle as many resources towards problem areas that we identify as possible. This has held true, and it's driving our support "cost" even lower, although it has disrupted some other teams' workloads -- but it's driven those teams' support "cost" lower as well.

Look, the place for developers to improve their skill sets is in school or on their own time. The place for them to produce things is on your company's time. The best way to produce things is by producing what they know best. When working in areas where one developer is not comfortable, they should pull in a second developer who is specialized and work as a team, or the specialized developer should write the code and produce documentation and diagrams. Route support tasks to the people that wrote the code. Yes, this increases what we call your "bus factor" -- the likelihood of your department hitting a speed bump if the specialist should get hit by a bus. (Or laid off, or switch jobs, or ...) The truth of it is that your productivity loss from that fear is orders of magnitude higher than the actual loss when a "bus event" happens. What generally happens during a "bus event" is that the inheritor of the specialist's work remakes it in his own image so that he can most effectively support it, generally solving a bunch of problems and lowering time spent on support even further, and life goes on.

Assign things to people who can do them best. Make them support and document their work. Foster their creativity and allow them to focus without distractions or micromanagement. Everything else is management-school BS, which it unfortunately sounds like your company is swimming in. That doesn't mean that your team needs to swim in it, too.

From a company's point of view, a good manager promotes the values of the company while executing tasks according to those values. From an IT employee's point of view, a good manager lets the team do what's right to do as quickly and cleanly as possible and acts as a fecal barrier against senior management pushing values that they learned in weekend MBA classes down the throats of the underlings. You're being a company man, and that might not be the best for your team. The ones with "good" communication skills are just too polite to say it.

  • Make sure the employee knows how important communication skills are to his job description. Work with him/her to improve.
  • Don't insist that they be as good as the other team members at such tasks.
  • Assign tasks according to the principles you believe in. Find a balance between efficient assignment of tasks to skills, and fairness/fun.

These are just summary ideas, hopefully someone will steal these points and fold them into one of the other answers. ;-)


Performance is everything. Give him the programming tasks. Do talk this over with the rest of the department. Optionally bring someone in to do com tasks or task someone on com tasks only. Don't think of the programming of having fun. Everything is "fun" from your POV.

If you don't you will create a situation that's extremely hard to manage and less effective than it could be.


What a great question, it is the kind of thing all team lead, supervisor, managers of techies should think about. I like your approach, everyone should get a 'fun' task. Taking it further having a team that can pickup different tasks and is cross trained prevents the Peterbilt Principle from causing havoc 'indesipensible team member leaves team or even takes gasp a vacation'.

Now, as pointed out by lots of posts, work is not fair and shouldn't be. Managers are measured on how much valuable work gets done.

  • Managers match tasks to individuals based on skills.
  • Good managers match tasks based on skills, growth, interest and building productivity of the team.
  • Great managers get their team to do this with a little help and guidance. Ie without the manager spending all day on it.

Talk to your good programmer, ask him if there are things he wants to learn. What other tasks would he accept... even what is least objectionable to him. Can he help other team members with their programming... mentor them. Yes I know communication is a problem, so maybe he should be working on that.

Another way to package this is having a list of tasks and let each staff member pick something. Let your good programmer pick first. If you warn him in advance and show him the list of tasks even better.

If you get resistence, which you almost always do with change, find a selling point, something of value to him, why will he benefit. Lastly you can just tell him to do it for the team.

Also expect mistakes and lower productivity to start, that’s a sign people are learning. This project may suffer, but the next will be better.

In closing, it is your job to make sure stuff gets done, but so is growing your staff and if you can engage them in the process even better. Some might say the best way to ensure stuff gets done is a team that knows what needs to get done and owns the results.

Edit: Oh and keep trying, the advice above comes from years of making mistakes, but I always knew I wanted to help my team grow, and I knew productivity is king, so I kept trying new things when the last attempt failed.


Best answer has already been accepted, but I'm surprised nobody pointed out that "task assignment" isn't the only thing the manager can work with. Having an "above avg programmer" who also has "above avg communication skills" should (all other things being equal) be a higher paid/more senior developer than someone with similar programming skills and weak communication skills. This may help offset any perceived "favoritism" from the team. (In some orgs, having above avg skills in "Requirements Analysis" and below avg skills in other areas may be worth much more to the company due to the type of work being done. As a manager, you need to decide how to handle this.)

One other thing to watch out for: giving the person in question nothing but programming tasks will lead to isolation long term. Be sure to keep giving them some of the other tasks (but ones they can do well, don't set them up for negative feedback!!) so they are both visible to and have visibility with the other departments/teams.

Finally... check in with the other team members if they see any inequality in the team assignments periodically. This may be a big concern to you, but #15 on everyone else's list.

  • 1
    He has, unfortunately, less than average communication skills apparently. Commented Jun 12, 2012 at 15:04

Since by your own evaluation this one programmer is the best on the team, in a way it is "fair" to give that person the desired job (as a result of having demonstrated being best able to do it). After all, there were probably people who would have liked to work at this company but weren't hired at all - but nobody's going to say it isn't "fair" to them that they don't get to do this coding.

I think a fair approach would be to tell another, less skilled member of the team who wants to do more coding: "we're letting (so-and-so) take the lead on this one. Perhaps you can take the lead on the next thing that comes along, if you can demonstrate having learned x and y skills."

  • 2
    "However, one member of the team probably has above-average coding skills". He's not the best. He's above-average. There could be around 1/3rd of the team who's better at coding.
    – GHP
    Commented Jun 12, 2012 at 12:46

Like some of the others who answered, I understand your position, and I would have similar ambitions.

While the is a case to say that it makes sense to give tasks to the people best equipped to carry them out, there is also sense in broadening peoples skills in order to provide a dynamic and flexible team.

If this guy is required to do do non-coding elements in his role, but his communication skills are poorer than are really needed, he needs to improve. On the assumption that you have some kind of development review/appraisal system, this is the time to raise the issue.

The key issues are to map out clearly what you require of him, assess whether he has the skills to comply, and work out a training plan to enable to do so. Training doesn't necessarily need to be formal, but you need to help him gain the skills required.

If he simply can't be bothered, then it would ultimately come to a disciplinary issue. If he doesn't have the ability, despite having tried and having been supported by you, then there may be disciplinary measures available (which I would argue would be harsh and counter-productive) but equally you could just accept that he isn't cut out for certain tasks.

Talking to the guy will be one of your first ports of call. You might find that he lacks confidence or insight. You might also find that he is very responsive and will appreciate the opportunity to improve himself.


You should hire a junior to do all the grunt work, and let everyone know that they need to help him with anything he/she asks for help with.

They will be more inclined to bother the “above-average” coder because of their abilities and the rest of the team gets a new lackey. The junior gets to learn from the ground up and the company ends up with a well rounded employee in the end.

  • 1
    Please consider reworking this answer to flow a little more smoothly to show the relationship of the new programmer, including where we get the money to pay the new grunt (initially, I thought it was by getting rid of the poor communicator). In your answer, is working with the new guy a way for the existing guy to build communication skills? Which guy ends up well rounded? Commented Aug 26, 2012 at 16:09

Expecting that everyone will have the same communication skills is as rational as expecting you'll teach the crippled man to run as fast as the rest of the team.

People are different, they have different skills and different weakness. Firing a great programmer just because he can't catch up with the others in communication skills would be like firing a crippled man because he can't walk as fast as the others. It would be unfair from ethical point of view and it will be against your own economical interests - to get the job done.

You should at first, if you've failed to do that in the past, read about the Asperger syndrome. Poor social skills are the major indicator of that syndrome.

Second, you can hire and fire whoever you want, but if you fail to cope with the strenghts and weaknesses of your employees, you'll end up with a bunch of average programmers, because the best will leave (if not get fired first).

There is a film, Adam, in which the genial programmer is fired just because he have written something he wasn't expected to. His idea could bring a lot of money to the employer, but he couldn't use the chance because he was concentrated on his "principles".

  • 2
    Just to be clear - nobody is being fired here. We all work really well together, and he is an extremely valuable member of the dev team. I'm talking about how to assign future work, and how to improve the performance and morale of the team as a whole.
    – djcredo
    Commented Jun 11, 2012 at 22:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.