Um desenvolvedor se comunica com o negócio quando abre cada conversa pelo impacto para quem está ouvindo (prazo, custo, risco ou receita) e só depois entra no detalhe técnico, se pedirem. Na prática isso vira hábitos que você treina: traduzir a mesma entrega para cada audiência, avisar atraso no minuto em que percebe, discordar com proposta na mão e documentar cada decisão cara de desfazer.
Esse é o assunto do capítulo 3 do meu livro Maturidade em TI, a dimensão que chamo de U1, Comunicação e Influência. Das sete dimensões que uso para medir maturidade, é a que mais trava gente boa.
Por que comunicação pesa tanto para quem programa?
Liderando time, vi dois sêniores empatados em técnica se separarem na carreira. O que subiu falava claro, que é diferente de falar bonito. Defendia um trade-off em uma frase e fazia o gestor sair da reunião sabendo o que decidir.
Na minha carreira construí sistema que deu certo e sistema que fracassou, e a stack nunca foi o divisor. Os fracassos seguiram o mesmo roteiro: o time não explicava a complexidade do que fazia, não tinha argumento para defender o prazo, e cada revisão de data virava briga. Aparecia o “a TI não entrega nada”, o time ia apagar o próximo incêndio, e um patrocinador abortava o projeto. Os sucessos foram chatos de tão simples: conversa constante e toda definição documentada, técnica ou de negócio.
Daí vem uma leitura minha de campo, sem auditoria: comunicação resolve 80% dos problemas de uma operação de tecnologia. Se duas pessoas têm a resposta certa e só uma consegue defender, o time vai com quem defendeu. A outra vai para casa achando que foi passada para trás.
Como traduzir uma entrega técnica para cada pessoa?
A mesma entrega pede uma frase diferente para cada cadeira. Pense numa otimização de autenticação que derrubou a latência do login de 80 ms para 12 ms.
- Para outro dev, você fala do mecanismo: o token, a rotação, o número de milissegundos.
- Para o tech lead, fala do ganho e do preço: latência caiu, a lógica ficou mais complexa, o ganho compensa.
- Para o gestor de produto, fala do usuário: login mais rápido, efeito esperado na conversão do cadastro.
- Para o CEO, uma frase: “Login mais rápido. Sentimos menos abandono no cadastro.”
Quem fala de token com refresh rotacionado para o CEO avisa, sem querer, que não sabe ler quem está na frente. E o CEO percebe na hora.
Uma regra ajuda em qualquer reunião: antes de abrir a boca, escreva na cabeça uma frase que responda por que aquilo importa para quem está ouvindo, agora. “O pagamento parou para clientes novos nos últimos 40 minutos; explico a causa ou vou direto para a solução?” funciona. Começar contando que o fornecedor mudou a versão da API e o handler não estava versionado faz a sala desligar no segundo minuto.
Como avisar atraso sem perder a confiança?
Avise no minuto em que percebeu. Se esperar o time perguntar ou o dia acabar, você já perdeu.
A mensagem tem quatro partes: o bloqueio que apareceu, as alternativas que você já avaliou e por que descartou, o caminho que escolheu e a nova data. Se precisar de ajuda, diga qual, com nome. Gestor que recebe isso cedo consegue reorganizar o plano. Gestor que descobre na véspera fica com a sensação de que o time esconde coisa, e essa sensação dura meses.
O mesmo vale para pedir ajuda. “Não sei fazer, me ajuda?” gasta o tempo do outro. Conte o que tentou, onde travou e qual caminho você pensa seguir, e peça para validar. Você economiza o tempo de quem ajuda e ganha fama de quem respeita o tempo dos outros.
Como dizer não a um prazo sem virar o chato do time?
A maioria dos times entra em reunião de decisão sem preparar nada: não sabe quem estará na sala, não leva número, não leva opção. A conversa fica no achismo e você sai com o prazo entubado nas suas costas.
Antes de uma reunião em que uma decisão vai sair, responda por escrito quatro perguntas. Quem estará na sala e o que cada um precisa ouvir (o CFO ouve custo e risco, o CEO ouve prazo e resultado). Qual decisão você quer que saia, numa frase. Que material sustenta a conversa: número, opções com prós e contras, sua recomendação. E qual é a sua resposta se pedirem para apertar o prazo.
Para discordar, uso uma estrutura que treino nos times: reconhece a parte válida do outro, isola o ponto específico que preocupa, propõe uma alternativa e pergunta se faz sentido testar. Num exemplo do livro, o dev concorda que o lançamento é importante para o cliente, mostra que as três últimas entregas parecidas levaram em média 2,3 vezes o tempo orçado e propõe entregar as duas funcionalidades de maior impacto no trimestre e empurrar as outras três. Isso tira a conversa do “não dá” e coloca o gestor para escolher o que entra.
O que documentar para o negócio confiar no time?
Documente toda decisão que custa caro desfazer ou que alguém vai questionar daqui a seis meses: escolha de banco, de framework, de provedor de autenticação, contrato de API pública. Nome de variável e ordem de import ficam de fora.
O formato é curto, três parágrafos de um registro de decisão (ADR): o que foi decidido, por que (com as alternativas que você descartou) e o que muda para os outros times, inclusive como reverter. Leva uns dez minutos. Quando a crise chegar e alguém perguntar por que vocês fizeram daquele jeito, você abre o documento e a conversa termina, em vez de recomeçar do zero.
Isso muda a carreira de quem já é bom tecnicamente?
Pedro (nome trocado, com permissão) era dev sênior numa fintech, cinco anos de casa, autor de metade do sistema de cobrança. Pediu promoção a Staff três vezes em dois anos e ouviu não nas três. Na quarta, o CTO explicou: tecnicamente ele já estava no nível, mas resolvia tudo em silêncio. No radar, comunicação estava em 2 e o resto em 4.
Em nove meses ele escreveu quatro RFCs (os dois primeiros voltaram para revisão), apresentou um tech talk sobre a arquitetura de cobrança, começou a comentar PRs de outros times e documentou as cinco decisões mais importantes dos dois anos anteriores. Algumas tinham economizado centenas de milhares de reais e ninguém sabia que eram dele. Foi promovido no ciclo de dezembro, dez meses depois do diagnóstico, com a mesma técnica e a mesma stack.
Como saber se estou me comunicando melhor?
Meça três números em 30 dias: quantas pessoas te procuraram para pedir opinião antes de decidir, quantos documentos seus outras pessoas citaram ou linkaram, e quantos status semanais você mandou sem ninguém pedir (a meta é um por semana). Anote tudo numa planilha simples toda sexta, em dez minutos. Sem registro, “estou comunicando melhor” é fé.
E saiba a hora de parar. Status sem mudança desde ontem polui o canal, e pedir validação para cada decisão da sua alçada é insegurança disfarçada de humildade.
Para quem decide e não é técnico: cobre a tradução. Quem lidera tecnologia na sua empresa tem obrigação de falar com você em prazo, custo, risco e receita. Se a resposta vier em jargão, peça a versão em impacto. Time que não traduz a própria entrega também não consegue defender o próprio orçamento.
Onde ir a partir daqui
Escolha uma ação para esta semana: mande na sexta o primeiro status sem ser cobrado, ou escreva o ADR da última decisão cara que o seu time tomou.
O capítulo 3 de Maturidade em TI traz as oito ações completas, as cinco moedas de influência sem cargo e o registro de evidências que transforma comunicação em material de promoção.
Baixe os 22 templates do livro: os modelos de atraso, pedido de ajuda, discordância e ADR estão lá, prontos para copiar.