Categoria: Carreira e Liderança

Poucos profissionais entendem isso de verdade:

• Nem sempre é o mais técnico que lidera.
• Nem sempre é o mais rápido que cresce.
• Nem sempre é o mais experiente que influencia.

Este é o segundo texto da série Além do Código. No primeiro, falei sobre a diferença entre operar ferramentas e solucionar problemas. Agora o assunto é o que faz uma boa solução sair do papel: a comunicação em tecnologia.

Pelo que somos valorizados

Somos valorizados por:

• Clareza na comunicação
• Capacidade de traduzir o complexo em simples
• Conexão com pessoas
• Influência positiva no time

Você pode ter desenhado a melhor arquitetura da empresa. Se não consegue explicá-la para quem aprova o orçamento, ela não existe.

A melhor ideia perde para a ideia melhor explicada

Afinal, na prática, decisões técnicas são tomadas em reuniões, e reuniões são conversas entre pessoas com contextos diferentes. O diretor financeiro quer saber de custo e risco. O produto quer saber de prazo. O time quer saber o que muda no dia a dia. Quem consegue falar a língua de cada um conduz a decisão.

Saber se comunicar com pessoas é mais importante do que se comunicar com máquinas. A máquina aceita o comando exatamente como você escreveu. As pessoas, não.

Onde a comunicação em tecnologia aparece no dia a dia

Comunicação não é só apresentação para diretoria. Ela está em situações bem concretas:

• Explicar uma arquitetura para um stakeholder sem diagrama de 40 caixas: o problema, a proposta, o custo e o risco de não fazer.
• Apresentar uma ideia com confiança, inclusive quando ela contraria o que já foi decidido.
• Facilitar uma daily que dura 15 minutos e termina com bloqueios resolvidos, não com relatórios lidos em voz alta.
• Escrever um post-mortem que ensina em vez de culpar.
• Responder um incidente mantendo todo mundo informado sem gerar pânico.
• Revisar código com comentários que fazem a pessoa crescer, não só corrigir.

Dominar a comunicação em tecnologia posiciona você muito além do código.

Como desenvolver essa habilidade

1. Treine a versão de uma frase. Antes de qualquer apresentação, resuma a proposta em uma frase que um não técnico entenda. Se não conseguir, a ideia ainda não está clara nem para você.
2. Troque jargão por consequência. Em vez de “vamos implementar mTLS entre os serviços”, diga “vamos garantir que só os nossos serviços conversem entre si, e isso fecha o risco X”.
3. Escreva mais. Documentos de decisão, posts, resumos de reunião. Escrever organiza o pensamento e cria registro da sua contribuição.
4. Peça feedback sobre como você comunica, não só sobre o que você entregou.
5. Ouça antes de convencer. A objeção do outro quase sempre revela uma informação que você não tinha.

O desenvolvedor que sabe vender uma ideia vale muito mais.

Para refletir

📣 Você já está desenvolvendo a sua habilidade de comunicação? Qual soft skill você acha mais essencial na área de tecnologia hoje?

📚 Leia também: Arquitetura DevSecOps e Ferramentas, um exemplo de como explicar uma arquitetura em camadas, do problema às ferramentas.

Acompanhe e comente a série no meu LinkedIn.

---

Série Além do Código

• 1/4: Você está operando ou solucionando?
• 2/4: Comunicação vale mais que código (você está aqui)
• 3/4: Autonomia não se aprende em curso
• 4/4: Liderança não começa com um crachá

Poucos profissionais entendem este fato sobre a carreira em tecnologia: a empresa não te paga pela ferramenta que você domina. Ela te paga pelo problema que você resolve.

Este é o primeiro texto da série Além do Código, sobre o que realmente diferencia um profissional de tecnologia, além da parte técnica. Publiquei a versão curta no LinkedIn; aqui vai a versão completa.

Carreira em tecnologia: pelo que você não é pago

Nem sempre somos pagos para:

• Implementar ferramentas
• Operar ferramentas
• Escrever código

Isso soa estranho para quem passa o dia em um terminal, mas pense em quantas vezes você viu um projeto entregar “a ferramenta instalada” e, seis meses depois, ninguém saber dizer qual problema ela resolveu. Kubernetes sem necessidade de orquestração. Um SIEM que só gera alerta que ninguém lê. Um pipeline lindo que deploya um produto que ninguém usa.

Ferramenta é meio. Quando ela vira fim, o trabalho vira custo.

Pelo que você é pago

Somos pagos por:

• Conhecimento: entender o porquê por trás de cada decisão de arquitetura, não só o como.
• Habilidades: conseguir aplicar esse conhecimento num cenário real, com restrição de prazo, custo e gente.
• Mentalidade: olhar para um problema e perguntar “precisamos mesmo disso?” antes de “qual ferramenta usamos?”.
• Impacto real: disponibilidade que subiu, custo que caiu, risco que diminuiu, time que entrega mais rápido.

O operador sabe executar o procedimento. O profissional que soluciona sabe dizer quando o procedimento não deveria ser executado.

Por que isso ficou urgente

💥 Muitos estão se tornando apenas operadores de ferramentas, e esse perfil é o primeiro a ser substituído por IA.

Não é exagero. Gerar um manifesto, um módulo Terraform ou uma query já é trivial para um assistente de IA. O que continua difícil é decidir qual arquitetura faz sentido para aquele negócio, negociar o trade-off entre segurança e prazo, e explicar para a diretoria por que vale investir nisso agora. Essa parte não se automatiza com um prompt.

A IA não substitui quem soluciona. Ela acelera quem soluciona e torna desnecessário quem só opera.

Como sair do modo operador

Por isso, reuni algumas práticas que funcionam, tanto para quem está começando quanto para quem lidera time:

1. Comece toda tarefa pelo problema. Antes de abrir o console, escreva em uma frase o que vai melhorar para o negócio quando você terminar.
2. Meça o antes e o depois. Tempo de deploy, custo mensal, número de incidentes. Sem número, não existe impacto, existe opinião.
3. Questione o pedido. “Instala a ferramenta X” quase sempre esconde um problema Y. Descubra qual é.
4. Documente decisões, não só comandos. Um ADR curto vale mais que um runbook longo para quem chega depois.
5. Use a IA para operar, e o seu tempo para pensar. Deixe o assistente gerar o boilerplate e invista o tempo ganho em arquitetura, segurança e conversa com o negócio.

Para refletir

Você está operando ou solucionando?

Olhe para a última semana de trabalho e separe o que foi execução de procedimento do que foi decisão que mudou um resultado. A proporção entre as duas diz muito sobre para onde a sua carreira em tecnologia está indo.

📚 Leia também: Introdução ao DevSecOps, sobre como a cultura muda a forma de entregar tecnologia.

Acompanhe e comente a série no meu LinkedIn.

---

Série Além do Código

• 1/4: Você está operando ou solucionando? (você está aqui)
• 2/4: Comunicação vale mais que código
• 3/4: Autonomia não se aprende em curso
• 4/4: Liderança não começa com um crachá