O que acontece quando o técnico faz tudo certo e o projeto ainda quebra
Já vi engenheiro resolver um bug complexo em três horas, só para ver o produto rejeitado duas semanas depois porque o cliente não entendia a lógica por trás da solução. Isso não é falha técnica. É a competência interpessoal, e o mercado insiste em tratar como secundária quando na verdade decide se o trabalho entrega valor ou vira case study de fracasso.
a competencia interpessoal é uma das habilidades mais subestimadas em equipes técnicas
Não estou falando de ser simpático ou sorridente o tempo todo. Competência interpessoal é a capacidade de traduzir seu conhecimento técnico em algo que outras pessoas possam usar, aceitar e defender internamente. Quando você trabalha com produtos digitais, isso significa algo muito concreto: conseguir fazer um gerente comercial explicar para o marketing o que realmente acontece no fluxo de checkout, ou fazer um designer entender por que determinado micro-detalhe de interação impacta a taxa de conversão em 0,8%. Sem essa tradução, cada área trabalha com informações distorcidas e o produto paga o preço. No dia a dia eu vejo isso acontecer o tempo todo. Um desenvolvedor descreve um processo de forma técnica demais e o cliente fecha o olho porque não consegue visualizar o problema. O gerente de produto então assume uma solução baseada em premissas erradas. Depois vem a reclamação, a pressão, a cobrança de prazo, e ninguém conseguiu evitar isso porque ninguém dominava a comunicação entre áreas. A habilidade técnica resolve o problema. A interpessoal evita que ele seja criado do jeito errado.
Um exemplo prático que uso com frequência é a situação de levantar requisitos com stakeholders dispersos. Já tive um projeto onde o cliente tinha cinco áreas internas solicitando funcionalidades diferentes para o mesmo módulo. Cada uma falava uma língua diferente: operações queria relatórios, vendas queria automação, financeiro queria controle de acesso. Se eu fosse direto para a solução, ia construir algo que satisfazia uma área e frustrava as outras. O caminho foi mais lento no início mas economizou semanas de retrabalho: reuni os responsáveis em uma sessão de mapeamento de jornada compartilhada, desenhei o fluxo no quadro branco antes de qualquer código, e deixei claro quais decisões precisavam ser tomadas por eles, não por mim. O resultado foi um protótipo aprovado em duas rodadas, não oito. Existe um detalhe que poucos mencionam e que faz diferença real: a competência interpessoal funciona melhor quando você entrega informações no formato que o outro precisa receber, não no formato que você acha mais correto. Um analista financeiro não vai se importar com a arquitetura do sistema. Ele vai querer saber se aquilo gera auditabilidade. Um head de marketing quer saber se a funcionalidade vai funcionar no mobile e se dá para medir o impacto. Um líder operacional precisa ver o tempo economizado. Ajustar o recado para quem está do outro lado da mesa, ou da videoconferência, é um treino que se melhora com prática intencional, não com livros de autoajuda.
Também preciso ser honesto sobre os limites dessa habilidade. Competência interpessoal não resolve tudo. Se a empresa tem problemas estruturais de governança, se os prazos são irrealistas por decisão de cima, se há falta de orçamento para ferramentas básicas, nenhuma quantidade de soft skill vai consertar isso sozinha. Nessas situações, o ideal é combinar a comunicação clara com documentos formais que deixem os riscos registrados, e encaminhar a decisão para quem pode alterar a estrutura. Tentar resolver problemas sistêmicos apenas com empatia e negociação costuma ser desperdício de energia. Outro ponto que muita gente não vê: a competência interpessoal não é sinônimo de concordar com todos. Às vezes o papel mais importante é explicar com clareza por que determinada solicitação não cabe no escopo atual, ou por que o prazo proposto ignora dependências críticas. Fazer isso sem soar agressivo exige precisão, não suavidade. O erro comum é amenizar demais a mensagem e gerar falsa segurança. Melhor ser direto e documentado do que vago e depois culpar a comunicação.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Se você quer desenvolver essa habilidade de forma prática, aqui vai um método simples que eu aplico e recomendo: Primeiro, antes de qualquer reunião importante, escreva um parágrafo objetivo dizendo qual é o problema, qual é o impacto atual e qual decisão você espera que a outra parte tome. Isso parece óbvio, mas muitas pessoas entram em discussões longas sem definir o que precisam fechar. Ter esse parágrafo escrito muda completamente a direção da conversa.
Segundo, quando estiver explicando algo técnico, use analogias do universo da outra pessoa, não do seu. Se você fala com comercial, compare o fluxo com um funil de vendas. Se fala com operacionais, compare com uma linha de produção. Analogias adequadas aceleram o entendimento porque a pessoa conecta a novidade com algo que já domina. Terceiro, faça resumos escritos após reuniões decisórias. Um e-mail curto confirmando o que foi combinado reduz em até setenta por cento os mal-entendidos que aparecem semanas depois. Eu vejo equipes perderem prazos inteiros porque alguém assumiu algo diferente do que foi dito, e o resumo escrito evita isso.
Quarto, aprenda a fazer perguntas de validação. Em vez de perguntar se ficou claro, peça para a outra pessoa repetir o que entendeu com as próprias palavras. Isso mostra que você se importa com o entendimento real, não apenas com parecer estar tudo resolvido na superfície. Há também uma armadilha comum: achar que competência interpessoal é algo que se aprende de uma vez. Não é. É um músculo que precisa de feedback constante. Anotar o que funcionou e o que não funcionou em cada interação importante ajuda a identificar padrões. Eu costumo manter um caderno simples com anotações pós-reunião: o que a pessoa entendeu, onde travou, o que gerei de confusão. Depois de alguns meses, fica claro onde estão seus pontos cegos de comunicação.
Outra situação real que vale registrar: em um projeto de integração entre dois sistemas legados, a equipe técnica já tinha escolhido a solução ideal há semanas. O problema era que o diretor de TI não confiava na abordagem porque não via conexão com o roadmap estratégico dele. Em vez de argumentar com dados técnicos, eu agendei uma conversa de quinze minutos para entender quais eram as métricas que ele usava para avaliar investimentos. Descobri que o indicador principal era tempo de resposta do usuário final. Reinterpretei a solução técnica usando aquela métrica e apresentei um comparativo simples. Em dez minutos ele aprovou. A solução já estava pronta. O que faltava era a tradução correta. Se você está começando a trabalhar com equipes multidisciplinares e sente que o conhecimento técnico não está sendo suficiente, treine especificamente a habilidade de explicar o que você faz para pessoas que não compartilham seu vocabulário. Comece com situações de baixo risco, como conversas com colegas de outras áreas, e evolua para stakeholders mais externos. A prática deliberada faz diferença em poucas semanas.
Para fechar sem forçar uma moral qualquer: competência interpessoal não é um diferencial bonito de currículo. É um requisito funcional para quem quer que seu trabalho técnico realmente chegue ao usuário final. Projetos que quebram raramente quebram por falta de talento técnico. Frequentemente quebram porque ninguém dominou a ponte entre o que foi construído e o que foi solicitado. Dominar essa ponte é o que separa quem entrega resultado de quem entrega esforço.
