How to manage a developer who has poor communication skills

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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)

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

• 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. ;-)

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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

Answer 16

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.

Answer 17

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.

Answer 18

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