O Efeito Aquiles

Existem profissionais excelentes em tudo que fazem. Exceto por algum detalhe besta e acabam perdendo performance por isso. Eu chamo isso de “o efeito de Aquiles”.

São profissionais com altíssima capacidade técnica, extremamente importantes para a companhia. São do tipo de profissional que todo gestor gosta de ter como um ás na manga. Porém, muitas vezes este ás acaba fazendo ou deixando de fazer coisas que seriam extremamente importantes para sua evolução ou para trazer um senso de ordem ao que constroem.

A História de Aquiles

Todo mundo já conhece a historia de Aquiles, recapitulando:

Aquiles (em grego: Ἀχιλλεύς; transl.: Akhilleus), na mitologia grega, foi um herói da Grécia, um dos participantes da Guerra de Troia e o personagem principal e maior guerreiro da Ilíada, de Homero.

Aquiles tem ainda a característica de ser o mais bonito dos heróis reunidos contra Troia, assim como o melhor entre eles. A figura de Aquiles foi sendo moldada por diversos autores num espaço de mil anos, o que explica suas diversas contradições. A mais conhecida é a que fala que Aquiles era invulnerável em todo o seu corpo por se banhar no rio Estige, exceto em seu calcanhar (conforme um poema de Estácio, no século I). Segundo estas versões de seu mito, sua morte teria sido causada por uma flecha envenenada que o teria atingido exatamente nesta parte de seu corpo, desprotegida da armadura. A expressão “calcanhar de Aquiles”, que indica a principal fraqueza de alguém, teria aí a sua origem.

Fonte: wikipedia.

Na versão pertinente para esta publicação, ele era imbatível, exceto por tal calcanhar. Aquiles venceu a guerra de Troia junto de outros heróis, mas lá morreu por uma flechada, ao acaso, no calcanhar.

A Morte de Aquiles

Na versão que eu gosto, foi uma morte estupida.

Eu diria que o problema de Aquiles não foi ter uma vulnerabilidade. Todo mundo tem defeitos e todo mundo sabe, ou deveria saber, o preço que paga  por ser quem é.

O problema de aquiles não foi esse. Foi o descaso com um detalhe. Ele poderia ter protegido o calcanhar. Mas não. No caso dele, o detalhe foi rejeitar seus limites. Não teve diligencia de proteger a vulnerabilidade e acabou estupidamente morto.

Mas como isso se relaciona a carreira?

O Efeito Aquiles

E a carreira? Quantas vezes como profissionais não agimos com Aquiles? Aquele comentário importante no código… Aquele commit não feito… Um gestor que não gere seu time e abandona os desenvolvedores para trabalharem como bem entendem… Por mais brilhante que se tenha sido na guerra, uma flechada no calcanhar pode matar figurativamente: tolher uma promoção,  render alguma alcunha de indisciplinado…

Um dos melhores exemplos de perfil que sofre tal qual aquiles é o engenheiro genial antissocial. Que pode ate terminar as suas tarefas, mas não consegue documentar ou, meses depois, não lembra mais o que fez.

Sei de um caso de um gestor que se negava a usar o servidor de versionamento padrão da companhia. Sei também que uma pane na estação  de trabalho de um de seus subordinados arrasou um projeto. Ele foi demitido um tempo depois: se isso foi o principal motivo eu não sei, mas certamente não deve ter ajudado.

Desenvolvedores e o Efeito Aquiles

Para os desenvolvedores, só tenho um conselho: atentar aos detalhes. No Autodesenvolvimento, deixo bem claro que tais detalhes podem significar ser promovido ou não. Exemplos de detalhes importantes:

  • os relatórios estão em dia? Despesas, testes etc?
  • o código gerado é bem comentado?
  • a quantidade de soluções provisórias… É muito grande?
  • a documentação esta em dia?
  • o desenvolvedor pensou no que fez? consegue explicar?

É como dizem, a beleza está nos detalhes…

Os Resultados do Efeito Aquiles

Desenvolvedores deveriam se preocupar com esse tipo de coisa em suas carreiras. Consigo, de imediato, pensar em alguns problemas e entraves que tem origem neste tipo de postura:

  • Achar-se bom para executar atividades importantes;
  • Subestimar todas as atividades (e acabar trabalhando dobrado);
  • Baixa qualidade final (acabamento) das tarefas executadas;
  • Deterioração da imagem profissional.

Lidar com Aquiles

Infelizmente este é um mal que acomete desenvolvedores em uma escala alarmante. As melhores cabeças são capazes disso. Mas antes de aprofundar nisso, cabe uma avaliação do gestor da área em que Aquiles trabalha.

Em primeiro lugar, disciplina só existe se houver alguma definição de um conjunto de regras. Costumo dizer que ninguém leva multas de estacionamento em uma terra sem lei.

Feitas as considerações e partindo do princípio que o gestor gere seu time, o que fazer quando se tem um colega ou um subordinado assim?

Existem algumas possíveis razões pelas quais alguém deixa de fazer alguma coisa numa companhia. Quando se trata de Efeito Aquiles, normalmente temos:

  • Desconhecimento. O sujeito realmente não sabe que aquilo é importante.
  • Rebeldia. O profissional não executa algo para chamar a atenção de alguma forma.
  • Ego. O profissional se julga melhor ou bom demais para cumprir tarefas que julgou inferiores.
  • Necessidade. O profissional não teve escolha e teve que quebrar uma regra.
  • Boicote. Deliberadamente o profissional não executa algo para causar algum dano à companhia.

Desconhecimento: andar de olhos vendados.

Inclui-se aqui também desatenção.

Nos meus anos como gestor, eu já vi gente deixar de cumprir obrigações menores por desconhecimento.  Natural: o sujeito não faz algo por não saber que era necessário. Portanto, o tratamento é o mais simples: uma vez detectado que o sujeito não faz aquilo de propósito, a primeira coisa é educar o indivíduo de que algumas atividades são importantes.

Também convém explicar ao indivíduo que as atitudes dele podem lhe ocasionar problemas ou afastar boas oportunidades. Também é importante conscientizar que, sem querer, ele pode passar uma imagem de gênio rebelde ou cientista maluco  – nenhuma delas é boa para a carreira, ao contrário do que se imagina.

Normalmente, a coisa melhora pr si só. Se não melhorar, é bom fazer um acompanhamento até que o profissional desenvolva o hábito de executar tais tarefas.

Rebeldia: nem sempre é ruim.

Por quê? Porque rebeldia é uma manifestação, uma forma, infelizmente infantil, de chamar a atenção. Para provar ao (normalmente ausente) gestor que o funcionário está lá e precisa ser ouvido.

Eu soube de casos de pessoas tentarem alertar algum chefe sobre algo que perceberam que estava errado e, sem conseguir sensibilizar ao próprio gestor ou o gestor da área em que algo deveria mudar, resolveram deixar acontecer só para serem convocados a uma reunião de ações de melhoria depois.

Portanto, eu recomendo que um gestor, quando percebe que um funcionário comprometido e capaz está  agindo de maneira estranha, deve  conversar com este. Talvez, alguma mensagem importante tenha passado despercebida… Porém, há um alerta muito importante aqui: cuidar para que um ato rebelde não seja um boicote a companhia disfarçado.

Ego: motivo mais comum entre top performers.

Para consertar este tipo de comportamento a primeira coisa é identificar se isso é natural ou se isso é proposital. Se não for proposital, o profissional se acha o melhor e achava que poderia deixar detalhes de lado, cabe a educação do profissional. Porém, eu duvido que essa situação sequer exista.

Se ficar claro que o profissional faz isso de propósito (algo muito mais comum) e se ele for bom mesmo, o único argumento é deixar claro que aquilo está o impedindo de crescer. Que ele pode curtir a vida desregrada dele conquanto não contamine os demais. Eventualmente ele vai ver os outros promovidos e, se for esperto, vai mudar de atitude. Sozinho.

Esse comportamento é raramente problemático quando isolado: o profissional, simplesmente para decretar aos demais que ele é o melhor, assume que não precisa cumprir regras. Porém, profissionais egocentricos trazem no pacote vários outros problemas: estes profissionais são os piores para trocar informações, tratam mal aos colegas e, portanto, se acham tão bons que compensam tudo isso.

Raramente compensam.

Necessidade: a mais rara e normalmente inexistente explicação.

Eu tenho uma teoria: só quem conhece as regras pode quebrar elas. E se ele entende regras, vai quebrar apenas quando for necessário, algo que fará muito raramente. Gosto desta frase do Freeman Dyson:

“A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few ideas as possible. There are no prima donnas in engineering.”

~Freeman Dyson

Normalmente, ao fazer isso, o desenvolvedor vai ter um motivo muito bem fundamentado para fazê-lo. Igualmente terá consultado alguns colegas para, de fato, concluir que tal coisa é necessária.

Para completar, isso só vai acontecer em locais onde, claro, existam regras. E não é de agora que são poucos os locais de desenvolvimento, pelo menos no Brasil, onde desenvolve-se de maneira ordenada e profissional…

Boicote: um problema sem solução.

Por fim, eu muito raramente presenciei, entre desenvolvedores, descumprimento de tarefas com objetivos de boicote. Já presenciei muita gente discursar contra diretores, donos e acionistas, reclamando de mais-valia, que estão “sugando o trabalho alheio”. E mesmo nestes eu não vi nenhum comportamento terrorista. Eu jamais vejo motivos para alguém boicotar a companhia que paga o seu salário.

Para deixar clara a diferença entre rebeldia e boicote, gosto da analogia: você pode negar carona a algum amigo por estar de mal com ele, mas não deixaria de salvá-lo caso estivesse se afogando.

Nestes casos, uma boa dica é perguntas ao suposto rebelde o que poderia mudar. Se ele tiver o que dizer, ótimo, só queria chamar a atenção. Entretanto, se ele quer apenas destruir, não vai saber o que dizer. Este tipo de pessoa só quer mesmo é chamar a atenção, amotinar-se sem propósito construtivo e, na maioria das vezes, sindicalizar os colegas para, no final das contas, não fazer nada.

Nota: e o que fazer quando alguém boicota a empresa?

Demissão é ate um favor que se faz a este tipo de perfil. Nenhum time de alta performance funciona com maçãs podres. Uma maçã podre é, neste contexto, alguém que adora quebrar regras sem motivo e influenciar os demais que tal comportamento é adequado. Eu até hoje só encontrei um jeito de resolver este problema. Demitindo o sujeito.

O Papel do Gestor

Cada desenvolvedor deve avaliar-se para não acabar contaminado pelo efeito Aquiles. Eu costumo deixar claro: cada um é dono de sua própria carreira.  Mesmo assim, o papel do gestor de equipe tem destaque total para sanear este problema, pois até mesmo o melhor profissional é influenciado pela qualidade da gestão do time de que faz parte.

Uma boa analogia é a do jogador de futebol. Ele não faz gol contra só porque está em time ruim. Pelo contrário. Porém, sem um bom técnico ele não irá mostrar todo seu potencial.

O papel do gestor, portanto, é fundamental para erradicar o “efeito Aquiles” de um determinado grupo. Grupos saudáveis tendem a eliminar naturalmente este tipo de situação. Portanto, caso o gestor detecte um departamento infestado por tal situação, o que normalmente se manifesta de uma desmotivação generalizada ou uma queda abrupta de performance, deve ministrar algumas vacinas:

  • Definição de um Plano de Trabalho;
  • Definição de um Método de Trabalho;
  • Profissionalização: eliminar pessoas que atuam apenas no que “estão a fim”;
  • Remoção de integrantes anti-profissionais do grupo;
  • Amadurecimento dos elementos rebeldes – estes são os primeiros a adotar as mudanças propostas pelo gestor;
  • Educação dos desatentos.

O gestor que não entende estas manifestações corre um risco muito grande de se ver, em um prazo curto, com uma péssima equipe:

  • Desatentos continuarão desatentos;
  • Rebeldes ou aqueles que agiram por necessidade (os bons) vão achar outro emprego;
  • Egocêntricos ou uma hora viram rebeldes (e vão embora em seguida) ou passam a boicotar a companhia (que os ofendeu a “não reconhecer sua grandeza”);
  • Boicotadores vão ficar.

E assim o gestor passa a ter um péssimo departamento sob seu comando. Afinal, não vai o gestor sofrer justamente do Efeito Aquiles


Gostou? Que tal pagar com um like? Deixe seu comentário!


Creative Commons License

Esta obra está licenciado com uma Licença Creative Commons Atribuição 4.0 Internacional.

Sobre rftafas 183 Artigos
Ricardo F. Tafas Jr é Engenheiro Eletricista pela UFRGS com ênfase em Sistemas Digitais e mestre em Engenharia Elétrica pela PUC com ênfase em Gestão de Sistemas de Telecomunicações. É também escritor e autor do livro Autodesenvolvimento para Desenvolvedores. Possui +10 anos de experiência na gestão de P&D e de times de engenharia e +13 anos no desenvolvimento de sistemas embarcados. Seus maiores interesses são aplicação de RH Estratégico, Gestão de Inovação e Tecnologia Embarcada como diferenciais competitivos e também em Sistemas Digitais de alto desempenho em FPGA. Atualmente, é editor e escreve para o "Repositório” (http://161.35.234.217), é membro do editorial do Embarcados (https://embarcados.com.br) e é Especialista em Gestão de P&D e Inovação pela Repo Dinâmica - Aceleradora de Produtos.
0 Comentários
Inline Feedbacks
View all comments