Como gerenciar um desenvolvedor com poucas habilidades de comunicação

Gerencio uma pequena equipe de desenvolvedores em um aplicativo que está no meio do ciclo de vida de uma grande empresa. Infelizmente, isso significa que geralmente há uma divisão de 30/70 de tarefas de programação em "outro trabalho técnico". Este trabalho inclui:

• Trabalhando com equipes de DBA / Unix / Rede / Loadbalancer em várias tarefas
• Colocação e gerenciamento de pedidos de hardware ou infraestrutura em diferentes regiões
• Executando testes que ainda não foram migrados para o IC
• Análise
• Suporte / Investigação

É justo dizer que todos os Desenvolvedores preferem codificar, em vez de executar tarefas mais comuns, por isso tento distribuir os divertidos trabalhos de programação igualmente entre a equipe.

A maior parte da equipe foi contratada porque, embora eles não tenham as habilidades de programação de elite para escrever seu próprio compilador / mecanismo de jogo / sistema de negociação de alta frequência etc., são bons comunicadores que "podem fazer as coisas", trabalham com outras equipes e navegue um pouco pela complexa burocracia aqui. Eles são bons desenvolvedores, mas também são bons funcionários técnicos.

No entanto, um membro da equipe provavelmente possui habilidades de codificação acima da média, mas habilidades de comunicação abaixo da média. Tradicionalmente, o gerente de desenvolvimento anterior tendia a dar a ele as tarefas de programação e não as tarefas mais comuns listadas acima. No entanto, não acho que isso seja justo com o restante da equipe, que demonstrou aptidão para desenvolver um conjunto de habilidades completo, geralmente exigido em um departamento de TI de grandes empresas.

O que devo fazer nesta situação? Se eu continuar dando a ele mais trabalho de programação, sei que isso será feito mais rapidamente (e, inversamente, espero que ele conclua o outro trabalho mais devagar). Mas isso contraria meus princípios e promove a idéia de que você pode criar um "nicho confortável" para si mesmo simplesmente sendo ruim nas tarefas que não gosta.

Quero esclarecer que não estou tentando resolver esse problema devido a um ressentimento ou que tenho um "chip no meu ombro", como foi mencionado. Estou procurando conselhos sobre como manter uma equipe equilibrada, feliz e motivada. Ao observar a variedade de respostas a essa pergunta, parece que existem muitas opiniões diferentes sobre como conseguir isso.

Parece que você está se esforçando demais em ter indivíduos bem-arredondados e pouco esforço em ter uma equipe bem-arredondada .

Não há nada errado em ser bom em alguma coisa - na verdade, é provavelmente por isso que ele foi contratado! Você deve ser grato por ter alguém que é bom em programação para começar.

Você declarou:

... vai contra meus princípios e promove a idéia de que você pode criar um "nicho confortável" para si mesmo simplesmente sendo ruim nas tarefas que não gosta.

Se ele era um programador medíocre, então eu concordo. Mas você não disse isso. Você disse que ele era um bom programador. Ele não está sendo ruim nas outras tarefas para executá-las - ele apenas concentrou seus esforços em se tornar um programador melhor. Não há nada de errado com isso.

Como gerente, não é seu trabalho garantir que todos sejam "bem-vindos". É seu trabalho garantir que as merdas sejam feitas. E você não está fazendo isso. Na verdade, você está tomando decisões que impedem que as coisas sejam feitas.

Qualquer que seja o seu problema, você precisa superar isso - você está tornando sua equipe menos produtiva.

Você está pegando um pouco de calor aqui nas outras respostas para a sua decisão de "fazer algo" sobre esse cara, mas eu entendo perfeitamente o que você está dizendo. Se os outros membros da equipe "todos preferem codificar, em vez de executar tarefas mais mundanas", ficarão irritados por você estar recompensando o mau desempenho do pobre comunicador , dando-lhe apenas as tarefas que todos desejam.

Imagine que você é um dos "bons comunicadores" da equipe, cujas habilidades são comparáveis ​​ao desenvolvedor em questão. Você lida com chamadas, trabalha com outras pessoas que não são de TI que mal conhecem o mouse a partir de um teclado, redige planos para aprovação do usuário e muito mais, tudo porque o seu chefe pede. Enquanto isso, o desenvolvedor mal-humorado, por ter "poucas habilidades de comunicação", fica sentado em seu cubo o dia todo, ignorando os usuários que trabalham apenas nas coisas "divertidas".

Agora você disse que o desenvolvedor rabugento tem habilidades "acima da média", mas não disse que ele era o melhor. Isso significa que talvez 1/3 da sua equipe, aqueles bons desenvolvedores de comunicadores com o nível de habilidade do desenvolvedor mal-humorado ou superior, estejam todos chateados.

Vale a pena perder um pouco de produtividade do seu MELHOR PESSOAL PERFORMANTE, porque eles estão incomodados com o mal-humorado-dev? Você terá que decidir.

A menos que você queira demitir o cara, sugiro que você siga uma destas abordagens:

1) Mentor ele para ser um melhor comunicador. Só você pode dizer se isso é viável. Você pode achar que apenas segurar a mão um pouco mais pode ajudar. Algumas pessoas têm pavor de interações formais nos negócios e expressam isso ficando chateadas quando solicitadas a fazê-lo.

2) Incentivar a "boa comunicação", com dinheiro ou outros benefícios. Deixe claro que você realmente valoriza bons comunicadores e seus desenvolvedores não ficarão tão irritados, mas a recompensa deve ser real e significativa. "Almoço com o gerente do distrito" não serve. Nem o prêmio "jogador estrela / parabéns / attaboy" é apenas um pedaço de papel. Tem que ser dinheiro extra, licença extra, algum tempo flexível, algum reconhecimento sério com superiores que controlam aumentos salariais etc.

Em primeiro lugar, culpar os membros da sua equipe ... denota uma fraca capacidade gerencial.

Quero dizer, se ele realmente tem poucas habilidades de comunicação, sinto muito por sua vida social, mas, no trabalho, isso não é tanto o problema dele quanto o seu . E, convenhamos, ele pode realmente ficar entediado com seu ambiente de trabalho chato, ou com problemas particulares influenciando o desempenho dele, ou planejando secretamente matar todos vocês.

A comunicação leva pelo menos duas e, afinal, aquela com habilidades de pessoas pobres pode ser você. Não importa se o resto dos membros da equipe está se dando muito bem, todos eles podem compensar (mesmo sem saber) por alguma deficiência de comunicação que você tem e ignorar alegremente.

De qualquer forma, não saia por aí perguntando à Internet sobre as pessoas que estão sentadas a três mesas de você, vá ao sujeito e pergunte a ele se realmente há algo errado e se pode ser resolvido. (ou algo monótono que pode ser otimizado ou aprimorado)

Talvez ele simplesmente odeie sua posição na mesa (ele está de frente para os banheiros?) E isso o deixa de mau humor.

Dica: ouça a resposta, como se ele fosse um ser humano sensível, não um recurso humano.

(por exemplo: tente explicar detalhadamente a necessidade de certas práticas e o significado de certas decisões, algumas pessoas pesquisam detalhes, pois dão a elas a sensação de ter um capitão que não está dirigindo o navio para os penhascos)

As pessoas são diferentes. Como gerente, você precisa tratar as pessoas de maneira diferente (mas justa!) Para aproveitar ao máximo sua equipe.

Dito isto, provavelmente é bom para o desenvolvedor com habilidades sociais ruins trabalhar neles. Eu descobriria o que o desenvolvedor não gosta de codificar (ou gostaria de fazer) que envolve mais dessas habilidades. Envolva-os nessa tarefa e, idealmente, eles melhorarão as habilidades sociais como efeito colateral.

As pessoas geralmente não são ruins em algo para sair do trabalho; são ruins porque não gostam ou têm aptidão para isso. Você não pode ajudar o último, então trabalhe no primeiro.

A divisão 30/70 pode ser onde todos os seus problemas começam. Eu nunca vi desenvolvedores felizes com essa divisão.

Vi desenvolvedores se sentirem confortáveis ​​com 10, 15% de outro trabalho (e fiquei feliz porque é divertido quando a dose é certa), mas 30% é demais. Prefiro pensar que outros membros da equipe preferem não falar o que pensam do que apenas um que não gosta de "30% de outro trabalho".

Também acho importante ajustar sua "matemática da produtividade" para valores mais realistas. Ele nunca vai chegar a 100% por causa de perdas inevitáveis ​​nas "alternâncias de contexto".

• ^{30 + 70, somando 100% de produtividade ao alternar entre programação e outro trabalho , nunca acontecerá na vida real; é mais provável cerca de 20 + 50 ou mesmo 20 + 40. As alternâncias de contexto são especialmente dolorosas para os desenvolvedores de software - se você estiver interessado, verifique este artigo para uma boa explicação sobre o motivo: NÃO ACORDE O PROGRAMADOR!
  Os programadores que valorizam sua produtividade naturalmente ficariam descontentes com perdas como essa.}

Quanto à execução de testes parte do trabalho, você considerou passá-lo aos testadores? O fato de os programadores poderem fazer isso (acho que qualquer programador experiente deveria ser capaz disso) não significa que deveriam . Os testadores também podem fazê-lo, e o fazem melhor, e não sofrerão perdas de produtividade em "alternâncias de contexto".

Outro ponto que me faz pensar em como você utiliza os recursos de controle de qualidade é a menção de suporte / investigação . Os testadores profissionais com quem eu costumava trabalhar tendem a ter "primeira palavra" em coisas assim.

• ^{Como ex-testador, eu os entendo muito bem - os problemas de produção têm sido para mim (como testador) uma fonte inestimável de dados para aprender sobre a cobertura dos testes ("esse problema foi coberto adequadamente pelos meus testes?") E por priorização de defeitos ("tudo bem, foi coberto por testes e relatado antes do lançamento, mas defini a prioridade / gravidade apropriadas naquela época?").}

É muito fácil para um bom testador descobrir quando passar a investigação do problema de suporte aos desenvolvedores, e isso não acontece com muita frequência. Razões para sobrecarregar os desenvolvedores com isso simplesmente me escapam da cabeça. Como eu já escrevi, eles certamente podem fazer isso (eu geralmente esperaria que o desenvolvedor sênior soubesse como fazer qualquer coisa que o controle de qualidade faça), mas isso não significa que eles devam .

Eu tenho duas coisas a dizer sobre isso

1. Você recrutou um programador ou desenvolvedor de software?
   Quando você está considerando um desenvolvedor de software, tudo o que você mencionou faz parte integrante do desenvolvimento de software. Você não pode ignorar nenhum deles, a menos que tenha recrutado apenas uma tarefa específica. Na IMO, 50% do desenvolvimento total de software é codificado; tudo é design, análise, teste, documentação, etc.

2. Ninguém nasce perfeito.
   Não é possível que você encontre uma pessoa que seja boa em tudo. Você tem que fazê-los lutar e fazê-los aprender coisas.

Como gerente, você precisa tirar o melhor proveito deles, eu concordo, mas, a longo prazo, você pode enfrentar problemas. Mostre a eles a sensação de que eu não sou bom nisso / não posso me dar ao luxo de fazer isso . Acima de tudo, trate todos igualmente, de forma a obter o resultado mais eficiente da sua equipe.

Se todos os membros da sua equipe tiverem o mesmo título / descrição do trabalho e a descrição do trabalho incluir tudo o que você listou, esse programador precisará ter essas outras habilidades aprimoradas ao receber mais dessas tarefas não programadoras. Da mesma forma, sua outra equipe não terá suas habilidades de programação aprimoradas se precisar trabalhar continuamente em tarefas que não sejam de programação (use ou perca).

Mas ainda acho que sua principal prioridade provavelmente deve ser o cumprimento dos prazos (o que você ainda poderá fazer ao distribuir o trabalho uniformemente).

EDIT: Se você tem uma equipe pequena, provavelmente faz sentido que todos os membros possam usar vários chapéus. Se você tem uma equipe grande o suficiente, provavelmente faz sentido ter grupos especializados em diferentes áreas. A partir da sua postagem, parece que você não tem uma equipe grande o suficiente para ter grupos de especialistas.

Não está claro em sua postagem original o que exatamente falta nas habilidades de comunicação desse desenvolvedor. A falta de interesse em ir a reuniões ou fazer um trabalho do tipo planejamento / coordenação (por exemplo) não indica necessariamente más habilidades de comunicação. Talvez o desenvolvedor simplesmente sinta que esse tipo de trabalho é um trabalho do gerente e reduz sua produtividade como desenvolvedor? Ou talvez ele sinta que há muita sobrecarga organizacional e essa é uma forma de protesto contra o que ele considera apenas um desperdício de tempo? Afinal, o problema oposto em que as pessoas falam o dia todo e nunca fazem nada também é bastante comum no escritório.

É importante que você fale com esse desenvolvedor de maneira não conflituosa e tente descobrir por que ele evita as tarefas que não são de programação. Provavelmente não é um motivo único, ele pode ter tantos motivos diferentes quanto tipos diferentes de tarefas. Certifique-se de que ele entenda que o objetivo da conversa é para que você possa aprender como melhorar efetivamente a produtividade e a satisfação no trabalho de todos os membros da equipe (você não quer pegá-lo). Este é um momento para você ouvir e não discutir ou tentar abordar suas preocupações com reações bruscas. Você provavelmente também deve se encontrar com os outros membros da equipe, talvez eles estejam bem em deixar esse cara fazer o trabalho pesado de desenvolvimento enquanto se concentram no lado mais chato da profissão.

Após esta reunião, dedique algum tempo a refletir sobre as conversas que você teve e tente considerar a perspectiva desse funcionário com a mente aberta. Talvez seus sentimentos iniciais estejam corretos e ele não tenha algumas habilidades importantes que você deve pressioná-lo a desenvolver. Ou talvez ele tenha feito alguns desafios válidos para suas suposições. Talvez você possa trabalhar com outras equipes para formalizar alguns processos e reduzir a necessidade de comunicação redundante. Talvez outras equipes não estejam se esforçando e você precise ter um bate-papo amigável com a gerência. Existem muitas possibilidades que você pode não estar considerando.

Por fim, e mais importante, mantenha uma conversa de acompanhamento com indivíduos ou uma reunião de equipe, se for apropriado. Se você identificou problemas organizacionais reais que estão ao seu alcance para afetar, informe seus funcionários sobre as ações que você tomará para melhorar a situação de trabalho deles. Se você ainda acredita que o funcionário está errado, sente-se com ele e explique quais mudanças você precisa dele e por quê. Os desenvolvedores tendem a responder bem às explicações lógicas / práticas. "Não é justo para seus colegas dar todo o trabalho divertido. Gostaríamos que todos fossem desenvolvedores puros, mas essa não é a realidade da situação, por isso precisamos compartilhar o fardo do trabalho ruim."

Claro, se esse cara é apenas um idiota mal-humorado, se recusa a dizer por que ele é infeliz, não responde à razão e não é bem respeitado por seus colegas ... bem ... é hora do Plano de Melhoria de Desempenho.

Embora você esteja tentando gerenciar uma equipe e queira manter todos motivados (ter uma sensação de justiça ajuda), você está sacrificando o projeto por não ter sua melhor programação para programadores? Quero dizer, este é o ponto, não é?

Você não tem medo de subutilizar e / ou corre o risco de perder seu melhor desenvolvedor? Seu trabalho é tentar aliviar esses tipos de tarefas de todos.

Ser tratado da mesma forma não significa que você trate todos da mesma forma. Se os outros desejam relaxar as tarefas de não programação para receber mais tarefas de programação, eles não correm o risco de não serem bons?

EDIT: Além dos seus sentimentos pessoais, você não identificou um problema. Em algum momento, a falta de comunicação atrapalha o programador. Outros mostrarão ressentimento e seu trabalho poderá sofrer. Até agora, você parece ser o único com problemas. A menos que haja algo mais que você não esteja compartilhando?

EDIÇÃO 2 Eventualmente, todo mundo vai pedir um favor especial. Essa pessoa faz menos comunicação e mais codificação (o que deveria ser feito em todas as contas). Alguém mais quer entrar um pouco mais tarde. Outro precisará pular uma reunião para cumprir um prazo. Uma pessoa gráfica recebe um monitor maior. Quando você enfatiza demais a pontuação, esquece o que é importante.

Eu sou um administrador de linux mal-humorado que faz muitos scripts e foi notado que tenho poucas habilidades de comunicação. Eu pareço muito com o seu cara. De fato, essa é a única área em que me envolvo nas avaliações de desempenho. Por outro lado, estou continuamente liderando minha equipe em inovação e solução de problemas, e criei e liderei o caminho para a nova plataforma que estamos lançando, poupando muito tempo à minha equipe e à minha empresa. muito dinheiro ao ser permitido ser eu mesmo.

Foi solicitado ao meu ex-chefe que sua família / esposa e a gerência sênior da nossa empresa deixassem seu cargo .... simultaneamente. Ele trabalhou incansavelmente para equilibrar as responsabilidades de maneira justa e assumiu muita carga. Durante qualquer interação com alguém de fora do departamento, se houvesse um mal-entendido em comunicação que lhe retornasse, ele era rápido em, ah, corrigi-lo punitivamente. Ele era pobre em "gerenciar para cima", então nossa equipe foi a última a obter recursos até que fosse uma emergência e, em seguida, a empresa pagou em excesso aos fornecedores com arremessos de vendas lisos por hardware não testado, sem consultar a equipe que usaria essas ferramentas. Em um esforço para criar uma equipe "bem equilibrada", ele microgerenciou nossas listas de tarefas e tentou equilibrar as tarefas para que os membros da equipe pudessem melhorar suas habilidades em áreas onde não eram ótimas, o que resultou em MUITO código quebrado ou implementações mal arquitetadas. Enquanto outras pessoas, além do autor, receberam tarefas de suporte específicas para esse código quebrado, para que pudessem "aprender" - as implementações, o código e os testes mal arquitetados criaram muita má vontade entre os membros da equipe e, na verdade,aumento das ocorrências do "jogo da culpa", que é um caminho rápido para um estado de equipe tóxico.

Meu chefe atual é um indivíduo calmo e organizado, que veio do cargo de administrador júnior e que subiu. Ele toma boas decisões e depende muito dos membros da equipe para definir suas próprias prioridades. Ele é um excelente comunicador e reage com calma e em conjunto com seu supervisor a quaisquer problemas, idéias ou necessidades de comunicação expressos por minha equipe. Ele "trabalha para cima" incansavelmente. Ele é lento em fazer grandes mudanças na arquitetura e consulta com toda a equipe antes de fazer alterações em nosso ambiente e se sente à vontade em confiar nas especialidades dos membros da equipe.

Sob o novo gerente, nosso tempo de inatividade caiu para quase zero (o que também reduziu a porcentagem de tempo que gastamos em tarefas de suporte de cerca de 40% para cerca de 10%), a satisfação de nossa equipe ultrapassou os limites e estamos no caminho certo, passou de uma "quebra do banco em novos hardwares a cada três a cinco anos" para um plano de aquisição contínua que deve economizar para a empresa cerca de um milhão de dólares por ano em cinco anos. Esse plano era um programa de base que nunca teria acontecido sob o gerente anterior, mas foi ativamente enviado à gerência sênior pelo novo gerente e dependia de encontrar MUITAS sinergias nos conjuntos de habilidades da equipe. Fomos informados informalmente pelo CIO de que agora somos a única equipe da empresa que "realmente se importa" e que ele " interferirá o mínimo possível em nosso ambiente de trabalho e embaralha o máximo de recursos para áreas problemáticas que identificamos quanto possível. Isso se manteve verdadeiro e está reduzindo ainda mais o "custo" de nosso suporte, embora tenha interrompido as cargas de trabalho de outras equipes - mas também diminuiu o "custo" de suporte dessas equipes.

Veja, o local para os desenvolvedores melhorarem seus conjuntos de habilidades é na escola ou em seu próprio tempo. O lugar para eles produzirem coisas é no tempo da sua empresa. A melhor maneira de produzir as coisas é produzir o que elas sabem melhor. Ao trabalhar em áreas onde um desenvolvedor não se sente confortável, ele deve contratar um segundo desenvolvedor especializado e trabalhar em equipe, ou o desenvolvedor especializado deve escrever o código e produzir documentação e diagramas. Encaminhe as tarefas de suporte às pessoas que escreveram o código. Sim, isso aumenta o que chamamos de "fator de ônibus" - a probabilidade de seu departamento atingir um lance de velocidade se o especialista for atropelado por um ônibus. (Ou demitido, ou troque de emprego, ou ...) A verdade é que sua perda de produtividade devido a esse medo é de magnitude superior à perda real quando um "evento de barramento" acontece. O que geralmente acontece durante um "evento de ônibus" é que o herdeiro do trabalho do especialista o refaz à sua própria imagem para que ele possa apoiá-lo de maneira mais eficaz, geralmente resolvendo um monte de problemas e diminuindo ainda mais o tempo gasto em suporte, e a vida continua em.

Atribua coisas às pessoas que podem fazê-las melhor. Faça-os apoiar e documentar seu trabalho. Promova sua criatividade e permita que eles se concentrem sem distrações ou microgerenciamento. Todo o resto é BS da escola de administração, que infelizmente parece que sua empresa está nadando. Isso não significa que sua equipe também precise nadar nela.

Do ponto de vista de uma empresa, um bom gerente promove os valores da empresa enquanto executa tarefas de acordo com esses valores. Do ponto de vista de um funcionário de TI, um bom gerente permite que a equipe faça o que é certo para fazer o mais rápido e limpo possível e age como uma barreira fecal contra a gerência sênior, empurrando os valores que eles aprenderam nas aulas de MBA no fim de semana pelas gargantas dos subordinados. Você está sendo um homem de empresa, e isso pode não ser o melhor para sua equipe. Aqueles com "boas" habilidades de comunicação são educados demais para dizer isso.

• Verifique se o funcionário sabe o quanto as habilidades de comunicação são importantes para a descrição de seu trabalho. Trabalhe com ele para melhorar.
• Não insista para que sejam tão bons quanto os outros membros da equipe em tais tarefas.
• Atribua tarefas de acordo com os princípios em que você acredita. Encontre um equilíbrio entre a atribuição eficiente de tarefas a habilidades e justiça / diversão.

Essas são apenas idéias resumidas, espero que alguém roube esses pontos e os junte a uma das outras respostas. ;-)

Performance é tudo. Dê a ele as tarefas de programação. Converse sobre isso com o resto do departamento. Opcionalmente, traga alguém para executar tarefas com ou apenas alguém com tarefas com. Não pense na programação de se divertir. Tudo é "divertido" do seu ponto de vista.

Caso contrário, você criará uma situação extremamente difícil de gerenciar e menos eficaz do que poderia ser.

Que grande pergunta, é o tipo de coisa que todo líder de equipe, supervisor, gerente de técnicos deve pensar. Gosto da sua abordagem, todos devem ter uma tarefa 'divertida'. Além disso, ter uma equipe que pode realizar tarefas diferentes e ter treinamento cruzado impede que o Princípio de Peterbilt cause estragos 'membro indesipensível da equipe deixa a equipe ou até tira um suspiro de férias'.

Agora, como apontado por muitos posts, o trabalho não é justo e não deveria ser. Os gerentes são medidos em quanto trabalho valioso é realizado.

• Os gerentes combinam tarefas com indivíduos com base em habilidades.
• Bons gerentes combinam tarefas com base em habilidades, crescimento, interesse e aumento da produtividade da equipe.
• Os grandes gerentes fazem com que sua equipe faça isso com uma pequena ajuda e orientação. Ou seja, sem que o gerente passe o dia todo nisso.

Converse com seu bom programador, pergunte a ele se há coisas que ele deseja aprender. Que outras tarefas ele aceitaria ... até o que é menos censurável para ele. Ele pode ajudar outros membros da equipe com a programação deles? Sim, eu sei que a comunicação é um problema, então talvez ele deva estar trabalhando nisso.

Outra maneira de empacotar isso é ter uma lista de tarefas e permitir que cada membro da equipe escolha alguma coisa. Deixe seu bom programador escolher primeiro. Se você o avisar com antecedência e mostrar a lista de tarefas ainda melhor.

Se você obtém resistência, o que quase sempre faz com a mudança, encontra um ponto de venda, algo de valor para ele, por que ele se beneficiará? Por fim, você pode apenas dizer a ele para fazer isso pela equipe.

Também espere que erros e menor produtividade comecem, isso é um sinal de que as pessoas estão aprendendo. Este projeto pode sofrer, mas o próximo será melhor.

Para encerrar, é seu trabalho garantir que as coisas sejam feitas, mas também aumentar sua equipe e se você pode envolvê-la no processo ainda melhor. Alguns podem dizer que a melhor maneira de garantir que as coisas sejam feitas é uma equipe que sabe o que precisa ser feito e possui os resultados.

Edit: Ah, e continue tentando, o conselho acima vem de anos cometendo erros, mas eu sempre soube que queria ajudar minha equipe a crescer e sabia que a produtividade é o rei, então continuei tentando coisas novas quando a última tentativa falhou.

A melhor resposta já foi aceita, mas estou surpreso que ninguém apontou que a "atribuição de tarefas" não é a única coisa com a qual o gerente pode trabalhar. Ter um "programador acima da média" que também tenha "habilidades de comunicação acima da média" deve (todas as outras coisas serem iguais) ser um desenvolvedor mais bem pago / mais experiente do que alguém com habilidades de programação semelhantes e habilidades de comunicação fracas. Isso pode ajudar a compensar qualquer "favoritismo" percebido da equipe. (Em algumas organizações, ter habilidades acima da média em "Análise de Requisitos" e abaixo da média em outras áreas pode valer muito mais para a empresa devido ao tipo de trabalho que está sendo realizado. Como gerente, você precisa decidir como lidar com isso. .)

Outra coisa a observar: dar à pessoa em questão nada além de tarefas de programação levará ao isolamento a longo prazo. Certifique-se de continuar dando a eles algumas das outras tarefas (mas elas podem ser bem-sucedidas, não as configure para feedback negativo !!), para que sejam visíveis e tenham visibilidade com os outros departamentos / equipes.

Finalmente ... verifique com os outros membros da equipe se eles vêem alguma desigualdade nas atribuições da equipe periodicamente. Isso pode ser uma grande preocupação para você, mas o número 15 na lista de todos os outros.

Como, por sua própria avaliação, esse programador é o melhor da equipe, de certa forma é "justo" dar a essa pessoa o trabalho desejado (como resultado de ter demonstrado ser mais capaz de fazê-lo). Afinal, provavelmente havia pessoas que gostariam de trabalhar nesta empresa, mas que não foram contratadas - mas ninguém vai dizer que não é "justo" para elas que não consigam fazer esse código.

Penso que uma abordagem justa seria dizer a outro membro menos qualificado da equipe que deseja fazer mais codificação: "estamos deixando (mais ou menos) a liderança nessa questão. Talvez você possa assumir a liderança. a próxima coisa a aparecer, se você puder demonstrar ter aprendido habilidades x e y ".

Como alguns dos outros que responderam, entendo sua posição e tenho ambições semelhantes.

Embora seja o caso de dizer que faz sentido atribuir tarefas às pessoas mais bem equipadas para realizá-las, também há sentido em ampliar as habilidades das pessoas, a fim de fornecer uma equipe dinâmica e flexível.

Se esse cara precisar fazer elementos não codificantes em sua função, mas suas habilidades de comunicação forem mais fracas do que realmente são necessárias, ele precisará melhorar. Supondo que você tenha algum tipo de sistema de revisão / avaliação de desenvolvimento, este é o momento de levantar a questão.

As principais questões são mapear claramente o que você exige dele, avaliar se ele possui as habilidades necessárias para cumprir e elaborar um plano de treinamento para permitir isso. O treinamento não precisa necessariamente ser formal, mas você precisa ajudá-lo a adquirir as habilidades necessárias.

Se ele simplesmente não pode ser incomodado, isso acabaria em uma questão disciplinar. Se ele não tem a capacidade, apesar de ter tentado e ter sido apoiado por você, pode haver medidas disciplinares disponíveis (o que eu diria que seriam duras e contraproducentes), mas da mesma forma você poderia simplesmente aceitar que ele não é cortado para certas tarefas.

Conversar com o cara será um dos seus primeiros portos de escala . Você pode achar que ele não tem confiança ou discernimento. Você também pode achar que ele é muito sensível e apreciará a oportunidade de melhorar a si mesmo.

Você deve contratar um júnior para fazer todo o trabalho pesado e informar a todos que eles precisam ajudá-lo com qualquer coisa que ele / ela pedir ajuda.

Eles estarão mais inclinados a incomodar o codificador "acima da média" por causa de suas habilidades e o resto da equipe recebe um novo lacaio. O júnior aprende desde o início e a empresa acaba com um funcionário bem-formado no final.

Esperar que todos tenham as mesmas habilidades de comunicação é tão racional quanto esperar que você ensine o homem aleijado a correr tão rápido quanto o resto da equipe.

As pessoas são diferentes, têm habilidades diferentes e fraquezas diferentes. Demitir um grande programador só porque ele não consegue alcançar os outros em habilidades de comunicação seria como despedir um homem aleijado porque ele não pode andar tão rápido quanto os outros. Seria injusto do ponto de vista ético e será contra seus próprios interesses econômicos - fazer o trabalho.

Você deve primeiro, se você não conseguiu fazer isso no passado, leia sobre a síndrome de Asperger . Más habilidades sociais são o principal indicador dessa síndrome.

Segundo, você pode contratar e demitir quem quiser, mas se você não conseguir lidar com as forças e fraquezas de seus funcionários, acabará com um monte de programadores comuns, porque os melhores sairão (se não forem demitidos primeiro) .

Há um filme, Adam , no qual o programador genial é demitido apenas porque ele escreveu algo que não era esperado. Sua idéia poderia trazer muito dinheiro para o empregador, mas ele não podia usar a chance porque estava concentrado em seus "princípios".