Ruído na linha
O café já esfriou faz tempo e a luz do monitor é a única coisa que realmente parece fazer sentido agora. São quase sete da noite. O silêncio do escritório vazio — ou do quarto, já nem sei mais onde termina um e começa o outro — é o oposto exato daquela cacofonia da Planning de hoje de manhã. Eu estava tentando explicar o risco de mexer na camada de persistência agora, sem um refactoring prévio, e a sensação foi a de tentar fazer o deploy de um código enquanto alguém fica puxando o cabo do servidor.
É um fenômeno curioso. A gente trabalha com lógica, com fluxos estruturados, com protocolos que esperam um sinal de ACK para continuar a transmissão. Mas, na hora da reunião ágil, o protocolo cai. Vira um UDP caótico onde todo mundo envia pacotes e ninguém se importa se eles chegaram ao destino. Fui interrompido três vezes antes de terminar a segunda frase. Na primeira, foi o Scrum Master querendo “manter o timebox”. Na segunda, um desenvolvedor mais sênior que achou que já sabia o que eu ia dizer. Na terceira, eu simplesmente desisti.
Fechei o microfone. O ícone ficou vermelho. É um alívio estranho, mas um alívio carregado de um peso que não deveria estar ali.
Eu me pergunto se isso acontece porque sou naturalmente mais quieto. Para quem é introvertido, a conversa tem um ritmo diferente. Eu espero o fim de uma ideia para começar a minha. Mas, nessas reuniões, o fim de uma ideia é um vácuo que alguém preenche em milissegundos. Se você respira para tomar fôlego, perdeu a vez. É quase como um race condition cerebral. Se eu não dou o “lock” na conversa logo de cara, o processo é atropelado por outro com maior prioridade — ou apenas com um volume de voz mais alto.
O problema é que esse silêncio forçado gera um tipo de dívida técnica emocional. Eu guardo a observação sobre o bug potencial. Eu guardo a dúvida sobre a arquitetura. O projeto segue, a sprint é fechada, e aquela falha silenciosa que eu tentei apontar lá atrás continua lá, crescendo, esperando o pior momento para estourar em produção. E o pior é que, quando estoura, ninguém lembra que houve uma tentativa de aviso. O silêncio é interpretado como concordância. “Mas ninguém falou nada na Planning”, eles dizem. É, ninguém ouviu.
Às vezes, eu fico revisando a cena na cabeça, tentando entender se eu deveria ter sido mais agressivo. Mas a ideia de ter que lutar por um espaço para falar sobre trabalho parece tão exaustiva quanto o próprio trabalho. A gente fala tanto de “segurança psicológica” nos treinamentos, mas na prática, a segurança parece ser apenas para quem já se sente seguro o suficiente para interromper os outros. Para o resto de nós, é só uma questão de quanto tempo você aguenta ficar com a mão levantada virtualmente sem ser notado.
Lembro de uma Daily na semana passada. Eu estava com um impedimento real, algo que estava travando o deploy do ambiente de homologação. Comecei a falar e, no meio do caminho, alguém soltou um “ah, mas aproveitando esse gancho…”. O assunto mudou para o churrasco do fim de semana e o meu impedimento virou fumaça. Voltei para o meu código com o mesmo problema, mas agora com uma camada extra de cansaço. É como se o backlog de coisas não ditas estivesse ficando maior que o backlog do produto.
Esse tipo de distorção acontece quando a daily deixa de ser um protocolo claro de sincronização e vira um espaço difuso de comentários paralelos. Por isso adotei um formato mais objetivo que explico em Roteiro 3 Tópicos: Daily em 60 Segundos e Volte ao Código.
Eu não acho que as pessoas façam por mal. É uma ansiedade coletiva. Todo mundo quer mostrar serviço, todo mundo quer resolver logo, todo mundo quer ser o dono da solução. Só que nessa pressa, a gente acaba ignorando o sinal mais fraco, que geralmente é o mais analítico. É a falha no sistema de comunicação da equipe: a gente otimiza o tempo de fala, mas não a qualidade da escuta.
Engraçado como isso se reflete no código. Quando um processo interrompe outro sem salvar o estado, o resultado é corrupção de memória. Na reunião, é a mesma coisa. Minha linha de raciocínio foi corrompida. Quando eu tento retomar, já esqueci o ponto principal ou a energia para explicar já se dissipou. É mais fácil só digitar “ok” no chat e seguir o fluxo, mesmo sabendo que o fluxo está indo para o precipício.
Fico pensando se isso é uma falha de arquitetura do tal “Agile”. Criamos rituais para tudo, mas esquecemos de como os seres humanos realmente se conectam. Colocamos vinte pessoas numa chamada de vídeo e esperamos que a colaboração aconteça por osmose, ignorando que o latência da rede e a personalidade de cada um criam barreiras invisíveis. O resultado é essa sensação de exaustão ao fim do dia, não pelo código que escrevi, mas pelas palavras que tive que engolir.
Talvez o problema seja essa interpretação de que silêncio é desinteresse. Para mim, o silêncio é processamento. Eu estou compilando o que foi dito antes de emitir uma resposta. Mas o ambiente corporativo não tem timeout para reflexão. Se você não responde instantaneamente, você é considerado um nó inativo na rede.
Curiosamente, esse mesmo padrão aparece na comunicação escrita. No Slack, o atraso ou a pausa também é interpretado como desatenção ou concordância muda. Detalho esses ruídos em 4 Erros de Comunicação no Slack que Geram Bugs.
Talvez essa percepção de que o silêncio é interpretado como vazio seja o que mais me incomoda ultimamente. Não é só na hora de falar do código; parece que essa leitura errada do que eu não digo está vazando para outros cantos, como se o que eu calo fosse mais importante do que o que eu tento dizer. É um padrão que começou a aparecer nos feedbacks trimestrais e eu ainda não entendi bem onde isso vai parar.
Continue aprofundando
Se você sente que seu silêncio é mal interpretado nas reuniões, estes textos ampliam essa reflexão:
• Escuta Ativa: A Técnica Simples Para Ser O Mais Inteligente Da Sala
• 7 Táticas Anti-Ansiedade: Domine Reuniões no Zoom/Teams
• 5 Frases para Responder Críticas Inesperadas em Reuniões
