O dia tinha acabado. Aquela sensação de estar com a cabeça cheia, mas sem ter feito nada de realmente concreto, que é a marca de umas três reuniões ruins em sequência. Abri o notebook de novo, não para código, mas para esvaziar a mente de um jeito organizado, como a gente faz com um backlog que inchou demais.
O que ficou da última daily não foi o que precisava ser feito. Foi o modo como um colega, o P. (que é gente boa, mas hiperativo), soltou uma crítica no meu trabalho. Não era nem sobre a funcionalidade em si, mas sobre a abordagem. E o pior, veio no meio de um monte de gente, jogada no ar, como quem só quer “ajudar a refinar”.
De novo, aquele instante em que o cérebro congela, tentando processar a informação inesperada, a audiência e o tom — tudo ao mesmo tempo. É tipo um bug silencioso que te pega no deploy. Não é fatal, mas faz a aplicação parar por um segundo. E aí você tem que decidir em frações de segundo como responder sem parecer defensivo, mas também sem engolir algo que você sabe que pensou muito para fazer daquele jeito.
A Busca Pela Resposta Mínima
Fiquei pensando nas frases que a gente deseja ter na ponta da língua nesses momentos. Não é para humilhar ninguém ou dar uma aula de arquitetura, longe disso. É para preservar a energia, estancar a crítica sem criar uma discussão de meia hora ali na frente de todo mundo, e principalmente, manter a compostura.
Tentei refazer mentalmente a cena, pensando em cinco saídas rápidas, quase como patches de comunicação. Não são fórmulas mágicas, só modos de ganhar tempo e redirecionar a coisa para um canal menos exposto.
Essa dificuldade de reagir com clareza em tempo real é parecida com o que acontece nas dailies, quando precisamos sintetizar nosso raciocínio sob pressão. Falei mais sobre isso em Roteiro 3 Tópicos: Daily em 60 Segundos e Volte ao Código.
Uma das coisas que me incomoda é a ambiguidade. Críticas soltas quase sempre são ambíguas. O P. disse algo como: “Essa estrutura vai dar um retrabalho enorme no futuro, não sei se pensamos nisso.” O instinto é responder com uma tese sobre escalabilidade. Erro. Gasta energia e te põe no papel de professor.
A primeira coisa que pensei que eu deveria ter dito era algo simples, focado no ponto de vista dele, sem assumir a culpa ou o acerto: “Entendi. Você está vendo um risco de longo prazo nessa implementação?” Isso devolve a bola para ele, forçando a ser mais específico. Sai do “isso está ruim” e entra no “o risco é X”. Se ele não tiver um X, a crítica esvazia ali mesmo. Se tiver, pelo menos o debate se torna técnico.
Outra que eu deveria ter usado, porque o tempo de reunião era curto, seria a que foca no backlog. Afinal, a gente tem outras coisas pra entregar, né? “Faz sentido a sua preocupação. Podemos agendar um follow-up de 15 minutos para discutirmos a melhoria do design? Hoje preciso fechar [coisa importante da daily].” Isso mostra que você valoriza a opinião, mas a prioridade é o que está no papel. Tirar o assunto da daily é ouro. Transforma uma crítica pública em uma conversa técnica privada e agendada.
O Silêncio Como Munição
Um dos incômodos que sempre carrego é o silêncio. Meu silêncio quase sempre é interpretado como desinteresse, ou pior, como concordância muda. Fico processando, estruturando a resposta, avaliando o custo-benefício de falar, e quando percebo, o trem já passou.
O problema é que o silêncio raramente é neutro. Ele comunica algo, mesmo quando não queremos. Exploro melhor essa leitura equivocada do silêncio em Silêncio em Reuniões Ágeis.
A crítica do P. me pegou de surpresa, mas não era totalmente inválida, ele só não soube apresentar. O que me leva à terceira “frase de combate” — a que valida o incômodo dele, mas protege meu tempo de trabalho: “Boa observação. Posso te mandar por mensagem a minha justificativa técnica e a gente alinha se precisa de refatoração, ok?” Isso transforma a crítica dele em um item de ação para você, mas tira a urgência desnecessária da reunião. De novo, tira do palco principal.
A quarta frase é para quando a crítica é mais emocional ou baseada em “achismo” (e acontece muito). O P. talvez estivesse cansado e só jogou a frustração. Nesses casos, a gente precisa de algo que peça o dado, o concreto: “Onde exatamente você acredita que o impacto disso será maior?” “Onde” é melhor que “por que”. Onde ele consegue te mostrar o código, a linha, o diagrama. Isso transforma a opinião em um pedido por evidência.
E a última, a que encerra a conversa na hora, é quase um rollback rápido: “Essa abordagem atende os requisitos atuais. Se for necessário, podemos criar um ticket para avaliar a mudança depois.” É a frase do “está funcional, vamos para a próxima”. Transfere o peso da mudança para o processo formal (o ticket no backlog), e não para o seu ego na reunião.
Não usei nenhuma dessas, claro. Na hora, só balbuciei um “sim, a gente pode rever isso” e mudei de assunto. E o incômodo ficou. A diferença entre o que você pensa e o que você realmente diz em uma situação de pressão é sempre maior do que eu gostaria.
O que me faz pensar que talvez o problema não seja só a frase que falta. É todo o palco, a dinâmica de estar ali, exposto, e ter que ser rápido de um jeito que a gente, que prefere o silêncio do código, não consegue ser naturalmente. É como se a gente estivesse sempre em desvantagem nesse tipo de ambiente, onde a agilidade na fala conta mais do que a solidez do argumento técnico.
Ainda não digeri bem a forma como essas interações acontecem em reuniões virtuais. Parece que, com a tela no meio, o filtro social fica mais fino, e as críticas chegam mais cruas, mais invasivas. É um assunto que sempre volta no meu dia a dia, em quase todas as dailies ou reviews.
Continue aprofundando
Se críticas inesperadas ainda drenam sua energia, estes textos ajudam a organizar essa reação:
• A Arte de Pensar Antes de Falar
• 7 Taticas Anti-Ansiedade: Domine Reunioes no Zoom/Teams
• 4 Passos: Feedback em Code Review sem Drama ou Conflitos
