Por que a comunicação técnica falha
A comunicação técnica falha por uma razão fundamental: o comunicador está pensando na solução, não no problema da audiência. Um engenheiro que explica uma decisão de arquitetura em termos de microsserviços, latência de rede e consistência eventual está respondendo uma pergunta que a diretoria nunca fez — e ignorando as perguntas que ela realmente tem: isso vai funcionar? Qual é o risco? Quanto vai custar? Quando teremos resultados?
Isso não é falta de inteligência da diretoria — é falta de contexto compartilhado. A diretoria pensa em termos de negócio porque é exatamente isso que ela deveria fazer. O trabalho do líder de TI é construir a ponte entre esses dois universos — não simplificar tecnologia ao ponto de ser desonesto, mas conectar decisões técnicas a consequências de negócio que a audiência consegue avaliar.
O modelo de comunicação bidirecional
Comunicação eficiente com stakeholders não-técnicos é bidirecional, não uma palestra. Antes de apresentar qualquer decisão técnica, vale entender qual é o modelo mental da audiência sobre o assunto. Uma diretoria que acredita que infraestrutura em cloud é sempre mais barata do que on-premise vai ouvir sua proposta de migração com um conjunto de pressupostos que podem ou não ser corretos. Se você não mapeia esses pressupostos primeiro, você acaba discutindo a decisão a partir de premissas implícitas diferentes — e o resultado é confusão ou desconfiança, não alinhamento.
Uma prática eficiente: antes de qualquer apresentação importante, faça uma conversa informal com 1-2 membros da audiência para entender como eles estão enquadrando o problema. Isso calibra sua comunicação e frequentemente revela objeções que você pode endereçar antes de entrar na sala.
"A diretoria não precisa entender a solução técnica. Precisa entender se você entende o problema de negócio que está sendo resolvido."
Como explicar dívida técnica sem jargão
A analogia mais poderosa para dívida técnica é financeira — não por coincidência, o termo foi inventado por Ward Cunningham exatamente por isso. Dívida técnica é como dívida financeira: faz sentido em alguns momentos (quando você precisa de velocidade hoje e pode pagar depois), mas cobra juros no presente na forma de maior custo e maior risco.
Para tornar concreto, traduza a dívida em três dimensões que a diretoria consegue avaliar:
- Velocidade: "Este módulo tem dívida acumulada que faz qualquer mudança levar 3x mais tempo. Nos últimos 6 meses, perdemos X semanas de desenvolvimento por causa disso."
- Risco: "Este componente foi responsável por Y dos últimos Z incidentes de produção, com impacto médio de W horas de downtime."
- Custo de endereçar: "Resolver isso requer 2 sprints de 2 devs sêniores. O retorno é que a velocidade de desenvolvimento nessa área aumenta em 40% e o risco de incidente cai significativamente."
Apresentando trade-offs tecnológicos para quem não é técnico
Toda decisão técnica envolve trade-offs. O problema é que tecnólogos frequentemente apresentam trade-offs como se a audiência tivesse o mesmo contexto para avaliar cada lado — o que raramente é o caso.
A estrutura que funciona para apresentar trade-offs para não-técnicos: apresente as opções em termos de suas consequências de negócio, não de suas características técnicas. Em vez de "Opção A usa microserviços, Opção B usa monólito", apresente "Opção A nos dá mais flexibilidade para escalar partes independentes do sistema, mas exige mais investimento inicial em infraestrutura e complexidade operacional. Opção B nos permite entregar mais rápido no curto prazo, mas cria mais limitações de escala no longo prazo."
Apresente sua recomendação com clareza. Gestores de TI que apresentam três opções sem recomendar uma criam ansiedade de decisão na audiência. A diretoria não tem contexto para avaliar trade-offs técnicos melhor do que você — é seu papel fazer a recomendação e defender ela com evidências.
Executivos leem de cima para baixo. A conclusão vem primeiro, a evidência vem depois — ao contrário de relatórios científicos. Se um executivo para de ler após o segundo parágrafo (o que acontece frequentemente), ele deve ter entendido o ponto central. Estrutura recomendada: (1) O que estamos propondo em uma frase. (2) Por que faz sentido em dois parágrafos. (3) O que precisamos. (4) Qual é o próximo passo. Detalhes técnicos: apêndice.
A estrutura de apresentação que funciona na diretoria
Apresentações para diretoria ou board de tecnologia têm características específicas: audiência com pouco tempo, alta expectativa de clarity, e conforto com risco e trade-offs de negócio — mas não com jargão técnico.
A estrutura que funciona consistentemente:
- Problema/oportunidade (1 slide): qual é a dor de negócio ou a oportunidade que estamos endereçando? Dados concretos quando possível.
- Proposta (1-2 slides): o que estamos propondo fazer. Em linguagem de negócio, não técnica.
- Por que agora? (1 slide): qual é o custo de não fazer isso agora? Urgência baseada em evidência.
- Impacto esperado (1 slide): o que muda depois da implementação? Métricas de negócio.
- Investimento necessário (1 slide): tempo, pessoas, orçamento.
- Riscos e mitigação (1 slide): o que pode dar errado e como estamos nos preparando.
- Próximos passos (1 slide): o que precisamos decidir hoje e o que acontece depois.
Como responder "por que isso está demorando tanto?"
Essa pergunta aparece em todo ciclo de desenvolvimento — e a forma como você responde define sua credibilidade como líder de TI. Respostas que não funcionam: justificativas técnicas que a pessoa não entende, culpar dependências externas sem assunção de responsabilidade, ou promessas de "vai ficar pronto logo" sem contexto.
A resposta que funciona tem três partes: contexto (o que aconteceu que explica o prazo), plano atual (o que está sendo feito agora e quando vai ficar pronto), e proposta de comunicação (como você vai manter a pessoa informada sem precisar que ela pergunte de novo). Isso demonstra ownership, transparência e proatividade — as três coisas que stakeholders precisam ver para confiar no líder técnico.