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

It's 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 would give him the programming tasks and not the more mundane tasks listed above. 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.

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.

Answer: Get S*** Done (58 Votes)

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:

"[I]t 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: Respect/Reward Productivity (23 Votes)

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 whose 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 losing 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:

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.

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 a "star player/kudos/attaboy" award that's just a piece of paper. It's gotta be extra money, extra leave, some flex time, some serious recognition with higher-ups who control pay raises, etc.

Answer: Don't Just Type There, Do Something (6 Votes)

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 work setting, or maybe private problems are influencing his performance, or maybe he's 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 sit three desks from you. Go to the chap and ask him if there really is anything wrong and if it can be worked out.

Maybe he just hates his desk position (is he facing the lavatories?).

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

Try explaining him in detail the need for 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: Simply Stated (4 Votes)

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

Think you know how to manage a developer who's got an unbalanced set of skills? Disagree with the opinions expressed above? Bring your expertise to the original post at Stack Exchange, a network of 80+ sites where you can trade expert knowledge on topics like web apps, cycling, scientific skepticism, and (almost) everything in between.

That's a question that does not have a definitive answer or a simple solution.It depends a lot on details and information not provided in the post.

One example is the current "Team Spirit". If those guys come along really well and are more friends than co-workers, they might be fine stepping back in the coding area a bit to not force their colleague into tasks he plainly dislikes, while they find them just "meh".If that's the case that would be the first thing I'd do, as it would be an instant productivity increase.

If it is vice versa and chances are a lot of the team would get grumpy if he'd get the coding stuff because they equally dislike the "mundane" tasks, that would be a silly idea. After a short time you would have one happy developer and the rest would be pissed. A recipe for bad atmosphere and productivity going to hell sooner than later.

Another aspect is the work to be done.Depending on the work to do, it might make sense to carve a specialized niche for someone, where a specialist with 100% of his time gets as much done as 5 or more people with 30% of their time. If this is going to be accepted well as a decision depends on the team again and how you sell it.Here it might also be important to consider future development. If this creates an important, central position that combines crucial knowledge and skills so it would be hard to replace that guy in case of [whatever], there's much to consider.

The next is the guys personality.What exactly are his problems and where are they coming from?Maybe just talking with him about how this is kind of a household chore that gets distributed evenly among everybody could help a lot. Maybe he is just not versed enough in those processes and needs a bit of support to make those tasks feel less, erm, hmm, "threatening" (missing proper word assuming he feels unsafe).If he really has a deficit in his communication skills, you should talk about that with him. If he accepts this as a weak spot and has the incentive to change it, support him.

Managing a team is difficult because there is no big red line you can walk along, like some easy principles you just have to enforce.I'd talk to this guy first and try to get his impression of the situation, what he thinks about his communication skills or why he has more difficulties with that tasks than the others. After that, you have some more information that might be very valuable in deciding what to do.

That would basically be my universal tip about managing teams. Talk with people. So often problems come down to the people deciding missing some simple input they could have got in minutes by just asking some questions.

Just a little anecdote. When I started working as a web-dev I was considered a fairly decent programmer, enough so that people hired me knowing that I had extremely poor social skills (or rather some medicable social and mental problems). One small office I worked at had a no-hold policy, the manager solved the problem by instructing everyone other than me to *not* answer the phone. Initially I was crippled with anxiety but It got me communicating a lot better over time. To the point where I sometimes spoke to the manager socially and went out to lunch with the other employees a few times, it was a really big win for me.

Is this your first management gig? Either make your star programmer the lead dev and get him out of the trenches, or write "improve customer-facing communication skills" into his annual commitments. Then he either improves (with your help) or you let him go.

Your boss doesn't give a damn about your principles, he/she cares about the work getting done. Your job is to see that it gets done efficiently and with high quality; that means assigning tasks to the people best qualified to complete those tasks.

I like Jason Holland's response that the individual in question needs to have the ability to complete all tasks and communication in ANY environment is key, so maybe he needs to work on this and also be assigned "mundane" tasks if his rank/title is equivalent to the other devs. The same could be said for the other devs who are getting mundane tasks; they'll never get better if they aren't challenged.

However, I feel that two considerations must be made:

1) In my experience at various levels of employment, regardless of performance, you only get noticed for going above and beyond and thus, assigned more responsibility, IF and only IF you also ask for it, unless it's a rare situation where a position is in desperate need of being filled.

Maybe these other developers need to be made aware that other tasks are there for them to perform and given the option of requesting them. Those devs that make the effort on their own to take on more work should be given that work and then maybe you can find a better balance.

2) #1 said, I feel that managers and employers often play to their weakest link rather than leveraging the performance of others against those who are more capable. If you have a dev with skills, you may actually have another one in hiding that won't be apparent until you've created a challenge for them (#1).

In the mean time, you may be wasting a resource trying to change your "over-skilled" developer into a mediocre player. If you have a rockstar dev, then USE that to your advantage.

What I would do is promote him and have him help bring the others up to speed, one project at a time. Then you'll have a team of rockstars.

Sounds like it would be better to put some of the developers on another project that actually involves development and hire other people for the maintenance stuff. That way everyone gets to enjoy themselves.

There is such a thing as rounding out your skills and there is not doing what you were hired to do. That may eventually create resentment.

If you stop using all the BS theories of team management, and look at the problem logically, there is only one, simple, answer: use people for what they are good at.

It's your job as a manager to figure out who is good at what. And it's not about doling out the fun tasks or the less fun tasks: no one is good at something they hate, and no two people like the same things, so find the people that *like* communicating, and have them handle that part. If you can't find one, time to recruit one.

Additionally, if you find that a particular individual, even when assigned to the task he is good at, is contributing less overall to the team's work than the others, pay him less or let him go.

He may be a really good coder, but if he can't communicate, his future career prospects are limited as the higher levels of software development require more and more social interaction. Perhaps sit down with him and have a chat about how he sees his development. Perhaps he likes being a code monkey, and does not want to advance (his choice). If that's the way he feels, so be it - further development isn't possible. Your option at this point is to see if he wants to be transferred to another department who may better use his coding skills, or retain him with the caution that perhaps he may inherit other work that others don't want (e.g., dull boilerplate coding). The other unfortunate part is it means he can't progress up the technical ladder much - code monkeys are a dime a dozen and he's at risk of being out shined by a cheap graduate.

Even the one-man gig has lots of social interaction - one has to deal with customers, bugs, etc., and driving away people means the community around your program doesn't develop.

Have a chat with the team and see how they feel - perhaps there's someone else who likes doing the "boring" 70% and wants to do more - they may hand off the coding stuff to your coder while offloading their "boring" work. Perhaps if there's a big job coming down, have them bid on individual bits of the work and dole them out accordingly. Perhaps if it's a new program, have the coder sit down and provide the framework for it, while the others provide the features.

The higher up the management chain you go, the more it becomes about interfacing - having technical skills helps a lot, but having good "people skills" is absolutely essential.

Just a little anecdote. When I started working as a web-dev I was considered a fairly decent programmer, enough so that people hired me knowing that I had extremely poor social skills (or rather some medicable social and mental problems). One small office I worked at had a no-hold policy, the manager solved the problem by instructing everyone other than me to *not* answer the phone. Initially I was crippled with anxiety but It got me communicating a lot better over time. To the point where I sometimes spoke to the manager socially and went out to lunch with the other employees a few times, it was a really big win for me.

You didn't have real, medical anxiety problems then, it was a personality issue. Good for you though, definitely, but a person with diagnosable anxiety disorder would be driven to madness, and possibly to deep depression, by such methods. Not to mention people with Asperger's or other disorders. That manager needs to be more careful with people's medical issues.

Just a little anecdote. When I started working as a web-dev I was considered a fairly decent programmer, enough so that people hired me knowing that I had extremely poor social skills (or rather some medicable social and mental problems). One small office I worked at had a no-hold policy, the manager solved the problem by instructing everyone other than me to *not* answer the phone. Initially I was crippled with anxiety but It got me communicating a lot better over time. To the point where I sometimes spoke to the manager socially and went out to lunch with the other employees a few times, it was a really big win for me.

I can relate to this situation in a very personal way, from the perspective of someone who works in IT and has had bouts with social anxiety on and off in the past. It is not uncommon for employees such as these to try and make up for their "unspoken" setbacks by burying themselves in their work and becoming better and more productive than everybody else in the team. I speak from my very own personal experience. think it is important to help foster good communication skills with the otherwise productive developer, not just for the good of the team but for the personal well being of the employee as well. This will have a major positive effect in his/her personal life which will in turn affect his/her professional life in a positive manner.

I disagree with the notion that the manager must just aim at "getting s*** done". This approach might make sense during ad-hoc, crunchtime situations , but it is not a sound approach for overall team building. An employee's personal life, particularly social, will have an impact on the team. Providing help and support to this employee, whether in the form of training, therapy, etc, is what I would do personally. Letting him/her dictate the pace. You'd be amazed at the results...

Why did you hire software developers and then give them to work on all that other shit that is not code?

Are you so fucking retarded that you cannot hire proper people with proper skills for those other tasks and let people who know how to code to do at least 80% of that?

I know that some administrative work is necessary but with only 30% of coding and 70% of all other tasks you are making them all miserable, and the more someone knows and likes coding the more miserable they will be in that setup.

Next thing you know today's "managers" will start hiring developers to work in construction and code some snippets during lunch break. What a load of bullshit.

Why did you hire software developers and then give them to work on all that other shit that is not code?

Are you so fucking retarded that you cannot hire proper people with proper skills for those other tasks and let people who know how to code to do at least 80% of that?

This is what happens on every single project I've ever worked on.

A team is put together, and in the early days, there is a lot of whiteboarding, prototyping, documentation and consulting with stakeholders. Then it's all development-mode. Months of coding with little outside communication. Once that's done, it becomes a mix of meeting the stakeholders, evaluating performance and fine-tuning the code. If you're lucky at this point, you get to focus on the code and not mess about with meeting users, if you're unlucky, you're the one evaluating the user feedback.

Then, it's deployment time. Most of the team spends the majority of their time on non-coding tasks - it's all about deployment, testing, fielding support calls, preparing user documentation, etc.

That's the way it works on typical projects within corporations anyway.

If you work for a software development company, dealing with a huge, mature codebase, you can get away with just programming all day. However, most programming jobs aren't like that, they're project-driven. Often, the majority of the project time is spent on phases other than coding.

Unless you end up working as a coder for a large software developer, or end up being a "gun for hire" contract programmer, with all the job instability that entails, chances are you're going to have to do a lot more than just coding, whether you like it or not.

However, one member of the team probably has above-average coding skills, but below-average communication skills. Traditionally, the previous Development Manager would give him the programming tasks and not the more mundane tasks listed above.

I could only think of one possibility of why the previous manager would only assigned him the programming tasks. Was it because English wasn't his native language? And for that reason that's why the previous manager would only handed him programming tasks instead of having him doing documentations and tasks that required more extensive English writing skill?

That could be one the only reasons I could think of. I am for one. English is not my strong language. I could do programming and manual IT works, but if you want me to write some a** documentations that read like from a native English person I'll be damn.

And because you haven't specified in your post in what area of communication skill he lacks of, and that tells me you too, yourself sir is lack of some sort of communication skill. And that's not being detail to the problem. That's exactly it's missing in your post, details, and why, how, in what area he needs improvements?

I met an Asian guy years ago. I could hardly understood him but he has above-average coding skill. He's good. He's done the assignment in 1/2 of the time that required him to be completed. Six months of assignment he finished in 3 months. And because he's contracted to do the job. Once he's done the project, he's gone. He lost 3 months pay when he could stick around for another 3 months. I once said to him you're missing 3 months pay. but he said he could finished it in 1 and 1/2 month, 3 months was already taken too long. What more could I say?

I don't know what you're expecting from this person. Do you want to talk about the Universe when you and him sit together in a coffee break and have a good chat on Black holes and Solar flares? But he couldn't understood a word you said about physics and chemistry also?

I remember this line from a war movie. An American guy from a submarine, who yelled out to a crew of Italiano,

The question fails to mention whether the programmer is uncommunicative because he is a grumpy asshole or because he is a nerd. If he is the latter, continue giving him programming work because he cannot change. If he is an asshole, have the other members of the team tease the shit out if him until he straightens out or storms off in a huff.

It's a double edged-sword to want to run a team of well-rounded individuals. If they communicate well and work well together the sounding-board effect can improve overall productivity and quality of the team, however not all people are designed for all tasks.

If you have a lot of coders who are being forced to do administrative work against there will, perhaps it's time to hire a single competent network and security admin to work with the team. Preferably someone who understand code and coding practices even if they aren't a "coder". You will find this person is happy to be involved in the dev process, but is much more at home with the other tasks, and similarly to how Coder-A gets coding problems solved more quickly, you will find a competent Network guy to get all those other tasks done more quickly.

This brings a balance and well-roundedness to the team as a whole, even if the individuals are not all jacks-of-all-trades. Sometimes a few specialists in the mix and a couple of outside thinkers are just as, or more effective.

This problem is not exclusive to software developers. Other disciplines, mechanics, electronics etc also have their fair share of 'loners', but given the nature of software it probably attracts more with such behavourial issues. Communication is also just one aspect, the 'not-fun' can extend to documentation, planning, reporting, inter-disciplinary interactions and formal testing. The list can be arbitrary and at his/her whim.

Overall. not a team player, lacking full owership, and in effect only doing half the work. Also not a professional - the ultimate discriminator or benchmark. Any mitigation by the rest of the team will only be partial and probably too late.

Usually it is the unwillingness rather than not being capable of or being aware of.

I used to work on a project that had gone live but still required significant support and development. I was the sole full time development resource, so I had to do both enhancements to the original system as well as ongoing basic support.

I lasted about 15 months before I quit, because they didnt rotate me off. I dont think my communication skills are as poor as the individual that the OP mentions, but nevertheless, I vastly preferred programming to other mundane support tasks.

Anyway, what I realized from my experience is that there is always going to be monkey work and someone has to do it. And nobody likes doing monkey work. That being said, make sure you rotate who has to do the monkey work, because otherwise staff who are skilled enough will simply find another job where they dont have to do monkey work. Like I did. I think a better solution would be to have someone doing monkey work, and monkey work only, for an extended period of time, say 3-6 months. And then rotate that person. Most programmers would find the mindset change involved in swapping between programming and monkey work to upset their productivity, so you want to minimize the context switches required, but still make sure that the dev in question knows that its only temporary. And once his shift is done, he can go back to full time dev work.

Maybe I'm biased as I'm one of the biggest examples of "carving out a niche by being bad at the other stuff" I've ever seen, but I'm definitely down with the first answer. When the rubber meets the road, I was assigned tasks I excelled at, and other folks were assigned tasks they were good at.

Mostly though, it comes down to how important is it that something gets done NOW. If you have a great deal of wiggle room, there is much to be said about cross training and rotating people through tasks. If it's a NOW NOW NOW NOW job (Which is where my experience is), well rounded individuals are less useful than a well rounded TEAM. Still, I'm down with carving my niche. I get the job done, I let other folks fill out the paperwork

Honestly, I think geeks/nerds have ridden this "picked-on-loner" horse for far too long. It's dead. Dismount already. However you were treated in the past is no reason to not have any of the attendant skills necessary in a modern office. Communication skills being one of the primary skills. There are plenty of good devs out there with good communication skills to have to bother with a special snowflake who refuses to adapt.

I mean...along with that "picked-on-loner" pose geeks like to strike, they also love to raise the "adapt or die" flag whenever anyone from a different field moans about meeting job requirements.

Honestly, I think geeks/nerds have ridden this "picked-on-loner" horse for far too long. It's dead. Dismount already. However you were treated in the past is no reason to not have any of the attendant skills necessary in a modern office.

Hm yea.. just like how not being treated badly in their past is no excuse for managers not being able to actually write any code. No sarcasm - it would be a terrible excuse. I wonder what their excuse is then.

Sometimes I think this whole "modern office" and "good communications skills required" are some sort of conspiracy perpetrated by non-nerds to keep all nerds permanently in their mothers basements.

I don't work in software engineering or programming, so I'm not sure how those fields work. I do work in an engineering field, for a small new product development team. As a new product development team, we spend a lot of hours on nontechnical and technical-but-not-development-specific tasks including tons of documentation, customer meetings, supplier evaluation, and so forth. This is part of the job, and if someone doesn't want to or is unable to do it, both they and the company would be better served by having them work elsewhere. (As it is a large company, there's a good chance that individual could find work in one of the specialist engineering teams that support our group.)

My opinion is isn't just a matter of allocating to individual employees the tasks they are best at.

For some purposes (not all) specialist employees are just not as useful to have around as more broadly capable employees, even if they are better at one particular task. If the nature of the work requires lots of 'retooling', i.e. frequent changes in the nature of the work, changes in the balance of work between different engineering and business disciplines -- engineers with more flexible skills are going to be more efficient to re-direct than an engineer who is a single purpose tool. This happens on our team where we might shift gears from doing mostly technical work (design, modeling, prototyping) to proposal writing for a few weeks and then back again. The efficiency benefit of a nonverbal employee during 'development' mode doesn't compensate for their inefficiency during 'proposal mode'. But, that employee might have a home in a different department, which I think a bunch of you other commenters also pointed out. My point is only that there are some jobs for which nonverbal specialization is not tolerable, even if the employee is otherwise competent or even superior.

In interest of honest disclosure, my previous post is a little self serving, though I do believe it to be true. I'm one of those people who work as a non-specialist engineer. I'm not an ace developer or electrical engineer, but I can do things that many ace developers and ace electrical engineers cannot or will not do. I've found a work environment where the flexibility and verbal ability I described is legitimately more important than being the best at a single thing. With a limited number of bodies/dollars available to us, we all need to be able to perform at many things, from designing to testing to giving presentations to prospective customers, and able to switch from one mode to another at short notice. But not every team has that need. For some teams, the right answer really might be to keep specialist non-communicator guy around, and let him do what he does best.

With this (lack/quality of communication) being a recurring issue:- How do you train to be a better "communicator"? I know the common answer to this is "more communication!", imagine telling a bad musician this! They can keep practicing (bad music), but without feedback and guidance they just do more bad music...- So, how do you measure communication performance? Everyone liked me and was happy, how much did they like me, how happy were they? They felt welcome and understood, how welcome did they feel, how understood did they feel? They had a warm fuzzy feeling, was it warm enough, was it fuzzy enough?

In my experience, most people cannot quantify how much they felt about something, it's all relative. People can't really explain why we like some people and not others. Sure, they can rationalize it in hind-sight, but really it's not rational, it's emotional. Yet most everyone I know seems to rate their communication skills to "at least average, a bit more than average". But they cannot communicate how to improve communication aside from "more communication!"

I think that a manager should try to think in terms of team effort, rather than getting hung up on individual weak points. If someone is better at coding, then by all means, use that. Take advantage of your teams strong points.

There is a massive fundamental issue with making your most productive/elite coder the only one coding: What happens when this person leaves? Also you've condensed your probably important product/service onto one single point of failure. What happens when he needs vacation? Gets sick for a while? Having one rockstar coder do all the work for a while is a massive liability.

A few reasons: elite coders will write elite code. Many times this code is less accessible/less commented/more obscured simply from the skill level of the coder, especially in languages where terseness is an asset. Second, even pro coders make mistakes or can miss some bugs, it's human nature. Having a team work on something provides easy code review opportunities. If someone who doesn't work on the project much has to review the elite coders work, as time goes on the reviewer's experience and knowledge of the codebase becomes more irrelevant and he/she can not review the code effectively. Finally, having one elite coder can enforce the hero mentality that crops up (and leads to burnout), and when he does eventually leave there is no one familiar with the codebase which could lead to some serious downtime as a new dev has to get up to speed.

Just a little anecdote. When I started working as a web-dev I was considered a fairly decent programmer, enough so that people hired me knowing that I had extremely poor social skills (or rather some medicable social and mental problems). One small office I worked at had a no-hold policy, the manager solved the problem by instructing everyone other than me to *not* answer the phone. Initially I was crippled with anxiety but It got me communicating a lot better over time. To the point where I sometimes spoke to the manager socially and went out to lunch with the other employees a few times, it was a really big win for me.

Right, and putting the quarterback as defensive center on an American football team is needed because the quarterback needs to round out his skill set.

I really don't understand why people have this aversion to having specialists on a team. A jack of all trades is a nice thing to have but forcing everybody into a mold is just plain wrong. I can't tell you how much it irritates me that people only think along a single track line. Oh, he can't communicate like I can, lets force him into some work that makes him learn. Now I loath the job I used to love. This causes a fall in productivity as well as needless anxiety. Now I start making mistakes because I'm still not good at the job at hand and the loathing I have for it makes matters worse. Wash rinse repeat until I either quit, I'm fired, or I screw up so badly I take the company down with me.

"Developer who has poor communication skills" reads more like "big top down company management fails again." You are having the developers do the job of management, yet still treating them and compensating them as a developer.

"Developer who has poor communication skills" reads more like "big top down company management fails again." You are having the developers do the job of management, yet still treating them and compensating them as a developer.

No. Communication is an important part of being a developer. Unless you're a one-person shop, you're almost certainly developing an application based on someone else's vision. You need to be able to discuss the design & requirements, so it's clear that you all have the same idea of what is being built. You need to be able to talk about performance, scaling, and other non-functional requirements. When your internal client-facing support team comes back to you with a bug report or enhancement request, you need to be able to understand what they're describing, see it from their perspective, and either try to fix the bug or discuss the enhancement. You need to be able to accept feedback, and give it as well. If you can't communicate well, how do you know you're building the right thing?

This is true whether you're in a garage startup with your buddy, or are working on a large project with teams spread across continents. Communication becomes more difficult as the team gets larger or more distributed, but this is true nonetheless.

More often than not, these gaps in communication skills is a result of a large technical knowledge gap between the dev and the users. You need to engage the business oriented analysts to bridge this gap. It's usually not a problem with the dev's communication skills, but rather the business users need to have things explained with crayons on pictographs. The business users are only interested in the process. So make it as simple as possible so they are able to fully understand those processes. Also, DOCUMENT ALL YOUR PROCESSES. And have the business analysts do the same for the business processes. That way, everyone has a reference base.

"Developer who has poor communication skills" reads more like "big top down company management fails again." You are having the developers do the job of management, yet still treating them and compensating them as a developer.

No. Communication is an important part of being a developer. Unless you're a one-person shop, you're almost certainly developing an application based on someone else's vision. You need to be able to discuss the design & requirements, so it's clear that you all have the same idea of what is being built. You need to be able to talk about performance, scaling, and other non-functional requirements. When your internal client-facing support team comes back to you with a bug report or enhancement request, you need to be able to understand what they're describing, see it from their perspective, and either try to fix the bug or discuss the enhancement. You need to be able to accept feedback, and give it as well. If you can't communicate well, how do you know you're building the right thing?

This is true whether you're in a garage startup with your buddy, or are working on a large project with teams spread across continents. Communication becomes more difficult as the team gets larger or more distributed, but this is true nonetheless.

The interaction between users and dev is a business analyst and system analyst job functions. Your dev may have those skillsets, but you need to have those separate resources perform those particular duties and have your dev focus on the solutioning and software specifications. The BA/SA should be mapping the user functional descriptions into a traceability matrix and engaging the users to garner feedback.

There is a massive fundamental issue with making your most productive/elite coder the only one coding: What happens when this person leaves? Also you've condensed your probably important product/service onto one single point of failure. What happens when he needs vacation? Gets sick for a while? Having one rockstar coder do all the work for a while is a massive liability.

A few reasons: elite coders will write elite code. Many times this code is less accessible/less commented/more obscured simply from the skill level of the coder, especially in languages where terseness is an asset. Second, even pro coders make mistakes or can miss some bugs, it's human nature. Having a team work on something provides easy code review opportunities. If someone who doesn't work on the project much has to review the elite coders work, as time goes on the reviewer's experience and knowledge of the codebase becomes more irrelevant and he/she can not review the code effectively. Finally, having one elite coder can enforce the hero mentality that crops up (and leads to burnout), and when he does eventually leave there is no one familiar with the codebase which could lead to some serious downtime as a new dev has to get up to speed.

It's not a 'massive fundamental issue'. You're diverting from the core topic, which is how to deal with an individual who has poor communication skills. What you describe is a resource issue, you solve it by having more than one productive/elite coder. You always have to do this because that productive/elite coder has to be able to go on PTO (paid time off). And what you're describing is not a resource issue, but fundamental software dev issues. You solve these gaps by implementing quality software engineering processes and lifecycles (traceability, documentation, spiral lifecycles).

"Developer who has poor communication skills" reads more like "big top down company management fails again." You are having the developers do the job of management, yet still treating them and compensating them as a developer.

No. Communication is an important part of being a developer. Unless you're a one-person shop, you're almost certainly developing an application based on someone else's vision. You need to be able to discuss the design & requirements, so it's clear that you all have the same idea of what is being built. You need to be able to talk about performance, scaling, and other non-functional requirements. When your internal client-facing support team comes back to you with a bug report or enhancement request, you need to be able to understand what they're describing, see it from their perspective, and either try to fix the bug or discuss the enhancement. You need to be able to accept feedback, and give it as well. If you can't communicate well, how do you know you're building the right thing?

This is true whether you're in a garage startup with your buddy, or are working on a large project with teams spread across continents. Communication becomes more difficult as the team gets larger or more distributed, but this is true nonetheless.

The interaction between users and dev is a business analyst and system analyst job functions. Your dev may have those skillsets, but you need to have those separate resources perform those particular duties and have your dev focus on the solutioning and software specifications. The BA/SA should be mapping the user functional descriptions into a traceability matrix and engaging the users to garner feedback.

I agree with you, but the developer needs to be communicate with the BAs! I know from personal experience that this isn't a given. On one project, I had to step in between the BA and the developer because both were bad communicators -- the developer had the fairly standard "I don't know the problem domain, I just code what I hear you telling me", and the BA had years of historical baggage to overcome with being ignored by developers and project architects. So to be fair to the developer in question, this was not a normal situation; ordinarily you just need to be able to read & write. Diplomacy is extra. ;-)

I agree with you, but the developer needs to be communicate with the BAs! I know from personal experience that this isn't a given. On one project, I had to step in between the BA and the developer because both were bad communicators -- the developer had the fairly standard "I don't know the problem domain, I just code what I hear you telling me", and the BA had years of historical baggage to overcome with being ignored by developers and project architects. So to be fair to the developer in question, this was not a normal situation; ordinarily you just need to be able to read & write. Diplomacy is extra. ;-)

In your particular case, that would be a failure of the BA. The BA/SA are the individuals that require good or excellent communication skills. It's a necessity for their job function. In those cases, you would have to rely on the program manager (PM) to facilitate the discussion. Or engage more subject matter experts (SME) to assist in the solutioning. Formal process like Requirements and Solutions Analysis (RSA) go a long way to mitigate gaps in those situations.

Regarding the basis for cycling a dev through other IT functions to make them 'more well-rounded', that should be a voluntary participation of the individual dev. A more compelling basis for mandatory participation would be to rotate your developers between your development team and your operational support team. Because personal insight into the function of each team helps to shape the developer's solutioning process. A lot of times, solutioning addresses the requirements but requires inordinate amount of maintenance oversight. I see this bad example repeated numerous times in DOD lifecycles. Development to fulfill feature creep ends up requiring extensive maintenance costs/resources. The cost metrics of DOD software lifecycle attributes over 78% of costs to maintenance phase.