O sistema caiu. O VP de produto quer saber o que aconteceu. Você sabe explicar em português — "o serviço de autenticação saturou a fila de mensagens e o load balancer não redistribuiu." Mas em inglês, pra alguém que não é técnico? Aí trava.
O problema quase nunca é vocabulário. É tradução de conceito. Profissional de tech tende a explicar o *como* (detalhes técnicos), quando o stakeholder quer saber o *quê* (impacto), o *quando* (prazo) e o *e agora?* (solução). Em inglês, essa diferença fica ainda mais clara — porque o idioma te obriga a ser direto.
Simplificando sem parecer simplista
A frase mais útil que existe pra isso é "in simple terms." Ela não é condescendente — é um sinal de que você tá traduzindo de propósito.
"In simple terms, the system can't handle the number of users we have right now."
"In simple terms" = em termos simples. Funciona como um aviso: "vou traduzir pra linguagem de gente." O VP ouve isso e relaxa — sabe que vai entender. Compare com "the authentication microservice is saturating the message queue" — tecnicamente preciso, mas inútil pra quem precisa tomar decisão de negócio.
Analogias: a ferramenta mais subestimada
"Think of it like a highway. We built it for two lanes, but now we have five lanes of traffic."
"Think of it like..." = pense nisso como... Analogias funcionam em qualquer idioma, mas em inglês corporativo são esperadas. Stakeholder americano ou europeu tá acostumado com essa forma de comunicação. Se você explica um problema de capacidade com "highway and lanes", a pessoa visualiza instantaneamente — sem precisar saber o que é load balancer.
Explicando a causa
Stakeholder quer saber por que aconteceu. Mas não quer um post-mortem de 40 slides. Quer uma frase.
"The root cause is a dependency on a third-party service that went down."
"Root cause" = causa raiz. Essa expressão veio de engenharia e virou padrão em tech. "Third-party service" = serviço de terceiros. "Went down" = caiu, ficou offline. Uma frase, três informações: a causa, de quem é a culpa (terceiro), e o que aconteceu. Suficiente pra um update executivo.
Comunicando impacto
Aqui tá o que o stakeholder realmente quer saber. Não o que quebrou — mas o que isso significa pro negócio.
"The impact is that customers are seeing slower load times during peak hours."
"The impact is that..." = o impacto é que... Estrutura perfeita pra conectar problema técnico com consequência de negócio. "Slower load times" = tempos de carregamento mais lentos. "Peak hours" = horário de pico. Repara: zero jargão técnico, 100% compreensível.
"Without this upgrade, we're looking at a forty percent increase in downtime over the next quarter."
"We're looking at" = estamos olhando pra (projeção). Número concreto + período = argumento que convence finance e produto. "Downtime" = tempo fora do ar. Se você quer aprovação pra um projeto técnico, traduza o risco em porcentagem ou dinheiro — "40% increase in downtime" fala mais alto que "the infrastructure needs refactoring."
Dando o status e próximos passos
Problema explicado, impacto claro. Agora: o que tá sendo feito?
"We have a workaround in place, but the permanent fix will take about two weeks."
"Workaround" = solução temporária, gambiarra elegante. "Permanent fix" = correção definitiva. Essa distinção é importante — mostra que o problema não tá sendo ignorado, mas que a solução completa precisa de tempo. Stakeholders gostam de ouvir "workaround in place" porque significa que já tem algo funcionando.
"We need to migrate to a new infrastructure, which means some planned downtime."
"Migrate" = migrar. "Planned downtime" = tempo fora do ar planejado. Repara a diferença: "downtime" é problema. "Planned downtime" é decisão. Quando você adiciona "planned", transforma uma notícia ruim em estratégia controlada.
"We're monitoring the situation and I'll send an update by end of day."
"We're monitoring" = estamos monitorando. "By end of day" (EOD) = até o fim do dia. Sempre termine um update de problema com próximo passo + prazo. Stakeholder quer saber quando vai receber notícia de novo — se você não diz, ele fica perguntando a cada hora.
Quando a pergunta é sobre segurança
Primeira coisa que C-level pergunta quando algo cai: "os dados dos clientes estão seguros?"
"There's no risk to customer data. The issue is performance, not security."
Direto. Sem rodeio. Se não é segurança, diga logo na primeira frase — senão o stakeholder fica em pânico achando o pior. "The issue is X, not Y" é uma estrutura poderosa pra limitar o escopo da preocupação.
Vendendo projetos técnicos
Technical debt, refactoring, infraestrutura — como convencer alguém não-técnico a investir nisso?
"The technical debt has been building up, and it's now affecting our ability to ship new features."
"Technical debt" = dívida técnica. Esse termo já é relativamente conhecido por stakeholders de tech companies. Mas a segunda parte é a chave: "affecting our ability to ship new features." Traduzir dívida técnica em velocidade de entrega é a forma mais eficaz de conseguir budget pra refactoring. Nenhum VP vai aprovar "precisamos refatorar a arquitetura." Mas "não conseguimos lançar features novas" — aí a conversa muda.
Resumindo
- "In simple terms..." abre a porta pra explicar sem jargão — use sempre
- "Think of it like..." + analogia = stakeholder entende na hora
- Comunique impacto em linguagem de negócio: porcentagem, downtime, clientes afetados
- "Workaround in place" + "permanent fix" — mostre que já tem solução temporária
- Sempre termine com próximo passo + prazo: "I'll send an update by EOD"
Quiz rápido
1. O sistema caiu e o VP pergunta o que aconteceu. Qual a melhor forma de explicar?
- a) "The authentication microservice saturated the message queue and the load balancer failed to redistribute"
- b) "In simple terms, the system can't handle the number of users we have right now"
- c) "It's a technical issue, don't worry about it"
Resposta: b) — Linguagem simples + impacto claro. A opção (a) é pra um post-mortem técnico, não pra stakeholder.
2. O que significa "we have a workaround in place"?
- a) O problema foi resolvido definitivamente
- b) Tem uma solução temporária funcionando enquanto trabalham na correção definitiva
- c) O time decidiu ignorar o problema
Resposta: b) — Workaround = solução temporária. "In place" = já implementada.
3. Como convencer um VP a investir em refactoring?
- a) "The codebase is a mess and we need to fix it"
- b) "The technical debt is affecting our ability to ship new features"
- c) "We need to refactor the architecture because it's old"
Resposta: b) — Traduz dívida técnica em impacto no negócio (velocidade de entrega).
Leia também: Como liderar uma daily standup em inglês · Como participar de uma call com equipe internacional