Uma engenheira sênior me disse uma vez que boa comunicação é um multiplicador de todas as outras habilidades profissionais. Eu não acreditei nela de cara. Achava que comunicação era a camada soft por cima do trabalho de verdade — a parte que importava quando o trabalho já tivesse terminado.

Ela estava certa. Eu estava errado.

Depois de alguns empregos, percebi que os engenheiros que eu mais respeitava não eram necessariamente os programadores mais fortes, e todos eles eram excepcionalmente bons em contar coisas diferentes para audiências diferentes de formas que essas audiências conseguiam agir. Eles não escreviam o mesmo status update pra todo mundo. Escreviam um update pro gestor, um pro time, uma autorrevisão pra si mesmos e — quando o trabalho pedia — algo específico pra QA ou pro cliente. Mesma semana. Audiências diferentes. Lentes diferentes.

Este post é sobre essa prática e o jeito pequeno e deliberado como eu a conduzo hoje. O diário que você mantém todo dia vira o input. O output são múltiplos relatórios, cada um moldado para uma audiência.

Quatro audiências, quatro necessidades diferentes

O gestor

O que o gestor precisa de você é basicamente um pequeno conjunto de coisas, repetido de forma confiável:

• Resultados, expressos em linguagem de negócio ou produto, não linguagem de implementação.
• Riscos, levantados cedo e claramente. O gestor prefere ouvir sobre um problema duas semanas antes do que no dia em que ele estoura.
• Pedidos, se houver. “Preciso dessa decisão de você”, “Gostaria de trazer essa pessoa.”
• Calibração de confiança. “No caminho certo” vs. “em risco” vs. “bloqueado”, aplicados com honestidade.

O gestor geralmente não quer — e frequentemente não quer ativamente — detalhes de implementação, justificativas técnicas ou um resumo de cada reunião. O critério de inclusão é: meu gestor se arrependeria se eu deixasse isso de fora, considerando o que ele precisa fazer essa semana?

O time

O que o time precisa é mais próximo do trabalho em si, mas também não é uma transcrição:

• O que está em andamento, pra que o time evite trabalho duplicado e identifique pontos de integração.
• Onde você está travado ou com dúvida, pra que possam ajudar.
• O que está prestes a ser entregue, pra que se preparem pra revisão ou trabalho downstream.
• O que você notou, pra que o conhecimento coletivo do time cresça.

O time é a audiência que mais se beneficia de franqueza sobre o meio bagunçado. “Passei dois dias perseguindo a causa errada do bug de auth; no final era X.” Essa frase é mais valiosa pro time do que uma postmortem polida, porque diz a eles a mesma armadilha está lá na próxima vez.

Você mesmo

O que você precisa da sua própria escrita é a mais pessoal das quatro:

• Padrões, identificados a partir de uma visão mais longa que um único dia.
• Atrito, identificado e nomeado pra que não fique invisível.
• Decisões que você tomou e o raciocínio na hora, pra que o eu-do-futuro possa recuperar não só o quê mas por quê.
• Avaliações honestas da sua própria semana — o que fez bem, o que faria diferente.

A audiência de si mesmo é a mais propensa a ser pulada. Parece autoindulgente. Não é. É como você vai compondo, e pular isso é a razão pela qual alguns engenheiros aprendem rápido e outros estacionam.

O revisor (quando aplicável)

Quando o trabalho vai ser verificado por outra pessoa — QA, um revisor de segurança, um cliente — o revisor quer:

• O que mudou e por quê, incluindo os casos de borda que você considerou.
• O que você testou, e o que não pôde ou não testou.
• Lacunas conhecidas. “Funciona pros casos A e B; C ainda não está tratado.”
• Instruções de reprodução, escritas pra alguém que não tem o seu contexto.

A audiência do revisor é a mais exigente em clareza, porque a consequência de escrita pouco clara é retrabalho ou pior.

Por que uma fonte com quatro lentes ganha de quatro trackers separados

Eu costumava achar que a resposta certa era quatro cadernos paralelos — um pra cada audiência. Dia um, escrever quatro entradas; dia dois, mais quatro. No final da semana, quatro fios de escrita.

Isso desmoronou em menos de um mês. O custo de escrever quatro entradas paralelas é alto demais; uma delas sempre fica de fora, o que significa que aquela audiência começa a não receber nada, o que faz o sistema inteiro parecer quebrado.

O que funcionou, depois de algumas iterações, é uma fonte, quatro lentes.

A fonte é o diário — capturado do mesmo jeito todo dia, no mesmo lugar, independente da audiência. As lentes são derivadas da fonte sob demanda, semanalmente ou quando uma audiência pede. As lentes são visões diferentes da mesma semana.

Mesma fonte. Seleção, ordenação e ênfase diferentes.

Isso funciona porque a informação é invariante — o que eu fiz nessa semana é o que eu fiz nessa semana. O que muda por audiência é qual subconjunto importa e como é enquadrado. Seleção e enquadramento são o que você deveria fazer pra cada audiência de qualquer forma. Fazê-los sob demanda a partir de uma única fonte é a versão barata do mesmo trabalho.

O que eu não delego

A aplicação da lente — traduzir das entradas do diário para output moldado por audiência — pode ser amplamente delegada a um assistente de IA. As regras de enquadramento são estáveis; o input é texto; a transformação é razoavelmente mecânica.

O que eu não delego é a revisão editorial depois que a lente é aplicada.

Um relatório do gestor rascunhado pelo assistente é competente. Às vezes ele vai escolher o resultado errado pra abrir. Às vezes vai suavizar demais um problema porque foi treinado em fraseado corporativo-educado. Às vezes vai chamar algo de “no caminho certo” quando eu sei que não está.

A revisão editorial de cinco minutos — eu leio o que o assistente produziu e reescrevo as partes que não estão bem — é a parte que precisa ser minha. Não porque o assistente não consiga chegar perto; consegue. Porque a proximidade importa. Um relatório do gestor que está 90% certo e 10% levemente errado nas coisas erradas é pior que um relatório 80% tão polido mas preciso em tudo.

É o mesmo ponto que eu fiz no post anterior: o assistente reduz o atrito; o julgamento continua sendo meu.

Uma nota sobre tom

Uma coisa sobre comunicar pra múltiplas audiências que eu subestimei por muito tempo: o tom de cada relatório é parte da mensagem.

Um relatório do gestor em linguagem casual de chat sinaliza “isso não é importante o suficiente pra pensar com cuidado.” Um relatório do revisor em prosa vaga sinaliza “eu não fiz meu dever de casa.”

O vocabulário e o tom estão fazendo um trabalho que os bullet points sozinhos não conseguem. Quando reviso meus próprios rascunhos, essa checagem de tom é a última coisa que faço antes de enviar. Isso soa certo pra quem vai ler? Se não, o que especificamente parece fora?

Como isso funciona na prática

Uma sexta-feira típica pra mim, final do dia, funciona mais ou menos assim.

• Abro as entradas da semana no diário (cinco arquivos, um por dia útil).
• Peço ao assistente de IA pra produzir quatro rascunhos: update do gestor, update do time, resumo pessoal e quaisquer notas pendentes de revisão.
• Pra cada rascunho, faço uma revisão editorial de cinco minutos. Corto o que não merece seu lugar. Reformulo qualquer coisa que suavize onde eu quero ser direto, ou direcione onde eu quero suavizar.
• Posto cada relatório no canal apropriado: update do gestor num thread de DM privado, update do time no canal do time, resumo pessoal fica na minha pasta, notas do revisor anexadas ao artefato correspondente.

Tempo total: trinta a quarenta minutos pra semana inteira. Sem o modelo de fonte-e-lente, o mesmo conjunto de relatórios costumava levar mais de duas horas e frequentemente era pulado.

A versão de trinta minutos não é de qualidade inferior. De certa forma é superior, porque as regras de enquadramento não oscilam entre relatórios e cada audiência sabe o que procurar.

Esse é o pitch inteiro. Comunique com frequência, comunique de forma diferente pra audiências diferentes, e deixe a fonte ser uma e as lentes serem muitas.