A importância de pensar antes de falar
Pensar antes de falar é uma habilidade essencial para profissionais que querem se comunicar com clareza e evitar conflitos no ambiente de trabalho.
É engraçado como a gente passa a vida inteira aprendendo a falar e, no fim, o que mais pesa é o que a gente não disse. Ou, pior, o que a gente disse sem pensar. Lembro de uma reunião, dessas que parecem nunca ter fim — algo muito comum para quem ainda está aprendendo a dominar reuniões virtuais no Zoom e Teams. Era sobre um backlog enorme, cheio de coisas que precisavam ser resolvidas “para ontem”. Um colega, daqueles mais expansivos, soltou uma ideia no meio da discussão. Era algo que, na superfície, até fazia sentido. Mas aí você começava a puxar o fio, e a coisa se complicava. Ele falou, a ideia foi lançada, e o silêncio que se seguiu não foi de concordância, mas de quem estava tentando processar a bomba que tinha acabado de cair na mesa.
Fiquei pensando nisso depois, enquanto o editor de código piscava na tela e a cafeína já batia no limite. A gente, de TI, tem umas manias estranhas. Somos bons em abstrair problemas, quebrar em pedaços menores, mas na hora de verbalizar, às vezes a coisa degringola. É como dar um deploy de uma feature que você só testou no ambiente local, sabe? Funciona lá, na sua cabeça, mas quando vai pro ar, pro ambiente real, que é a mesa de reunião, a coisa é outra.
Quando falar rápido cria problemas
A gente vive num mundo que valoriza muito a proatividade, a fala, a “voz ativa”. E eu entendo. Ninguém quer ser visto como desinteressado, como aquele que não contribui. Mas existe uma diferença brutal entre contribuir e simplesmente preencher o vácuo com barulho. Já vi muito silêncio ser interpretado como desinteresse, sim. Mas também já vi muita fala ser interpretada como… bom, como fala que não leva a nada.
É um paradoxo, eu acho. A gente passa horas debruçado em lógicas, em como fazer um sistema ser robusto, como prever falhas. E a nossa comunicação, que é uma das interfaces mais críticas que a gente tem, muitas vezes é tratada como um módulo à parte, sem refatoração, sem testes. É como se a gente esperasse que a fala, por si só, fosse magicamente se encaixar.
O deploy sem testes da comunicação
Lembro de um caso de um bug silencioso. Aquele que não estoura, não dá erro, mas vai corrompendo os dados devagarzinho. Ninguém percebe até que a inconsistência é grande demais pra ignorar. A fala sem filtro, sem um mínimo de processamento, parece um pouco com isso. Não é um erro gritante na hora, mas vai criando pequenas inconsistências no entendimento, pequenas rachaduras na comunicação que, com o tempo, podem virar um problema enorme. Uma falha silenciosa no canal de comunicação.
É que, para nós, o código tem uma sintaxe. Uma lógica. E a língua, no dia a dia, também tem. Só que a gente trata o código com mais reverência, com mais cuidado. Fazemos code review, discutimos padrões, pensamos em escalabilidade. Mas na hora de falar, muitas vezes, é no improviso total. É “deploy em produção sem testar”, no pior sentido.
A dívida técnica da fala impulsiva
Sempre me pego pensando naqueles momentos em que a gente é pego de surpresa por uma pergunta. O impulso é responder na hora, para mostrar que sabe, que está atento. Mas aí a resposta sai incompleta, talvez até errada, e você tem que gastar o dobro de energia para corrigir, para explicar de novo, para desfazer o mal-entendido. É a dívida técnica da comunicação. Você economiza tempo no planejamento da fala, mas paga juros altos depois.
É diferente de ser hesitante, de ter medo de se expressar. Não é sobre isso. É sobre dar um tempo para o processamento. É como quando você está depurando um problema complexo. Você não sai digitando qualquer coisa. Você observa, analisa os logs, tenta reproduzir. Às vezes, o silêncio de quem está pensando é muito mais produtivo do que a verborragia de quem só quer ser ouvido. Muitas vezes isso acontece porque a pessoa está praticando uma técnica de escuta ativa, que permite compreender melhor o problema antes de responder.
AO silêncio estratégico em reuniões
O feedback também é um terreno minado. Quantas vezes a gente já recebeu um feedback que parecia um ataque ou uma crítica pessoal. Por isso, aprender como dar feedback construtivo em code review pode evitar conflitos e melhorar a colaboração dentro do time.
Não é sobre ser perfeito, claro que não. Errar faz parte, e a comunicação é um processo contínuo de ajustes. Mas a gente podia tratar a fala com um pouco mais do mesmo rigor que a gente trata um pedaço de código crítico. Antes de fazer um push, a gente revisa, pensa nos impactos, nos possíveis side effects. Antes de falar, a gente podia fazer o mesmo. Uma espécie de “pull request verbal”.
Às vezes, eu só queria que as pessoas dessem um tempo. Um respiro. Não pra concordar, nem pra discordar, mas pra processar. Pra ver se a feature que está sendo proposta é realmente necessária, ou se é só uma ideia bonita na teoria que vai dar dor de cabeça na implementação.
No fim das contas, a gente vive de sistemas. E a comunicação é um sistema como qualquer outro. Tem entradas, processamento e saídas. E se o processamento for negligenciado, o sistema inteiro falha. E a gente, que entende tanto de sistemas, às vezes esquece de aplicar o que sabe no mais básico: o jeito como a gente interage.
A complexidade da comunicação é algo que ainda me deixa pensando. Não é uma questão de certo ou errado, mas de quanto esforço e reflexão a gente realmente dedica a esse aspecto tão fundamental do nosso dia a dia, muitas vezes tratando-o com uma simplicidade que ele claramente não tem.
No fim das contas, aprender a pensar antes de falar pode transformar completamente a qualidade da sua comunicação profissional.
