Ainda sinto o peso daquele silêncio na reunião de terça. Não o silêncio respeitoso, de quem pensa antes de falar, mas aquele que precede uma tempestade, ou talvez, o que sobra depois dela. A pauta era simples: refatorar um módulo antigo que estava gerando mais bug do que feature. Mas o que era para ser uma discussão técnica, rapidamente descambou para algo pessoal. E agora, dias depois, o ar ainda parece denso, carregado de algo que ninguém quer nomear, mas que todos sentem: o respeito, ou a falta dele.
É curioso como a gente, que lida com lógica e código, pode ser tão ilógico e imprevisível em relações humanas. Em TI, um bug é um bug. Você rastreia, isola, corrige, faz deploy. Com pessoas, o desentendimento não é um bug isolado; é mais como um débito técnico que vai se acumulando, afetando a performance geral do sistema. E, diferente do código, não tem um “git revert” para desfazer a palavra dita, o tom de voz, o olhar que julgou.
Lembro do Tom. Ele, com a melhor das intenções, apontou uma falha na lógica que o Rafa tinha implementado. Não foi grosseiro, mas foi direto demais, talvez. O Rafa, que passou a noite debugando aquilo, sentiu-se atacado, e a resposta veio no mesmo tom, só que um pouco mais alto. Dali pra frente, a discussão sobre o código virou uma disputa sobre quem tinha razão, quem era mais competente. E eu, ali, observando, sentindo a energia da sala murchar, como um servidor que de repente perde a conexão. O deploy da refatoração, que era para ser um alívio, virou um campo minado.
Não é sobre quem estava certo ou errado. Em tese, os dois tinham pontos válidos sobre a implementação. É sobre a forma. É sobre o terreno comum que se perde quando a confiança se abala. E o respeito é isso, um terreno comum, um protocolo de comunicação não escrito que permite que a gente discuta ideias sem destruir a relação. Quando esse protocolo quebra, é como se a gente passasse a falar linguagens diferentes, mesmo usando as mesmas palavras.
Passei a semana pensando nisso, quase como um problema de arquitetura de software. Como redesenhar a comunicação quando a arquitetura original falhou? Não dá pra simplesmente ignorar. O código do Tom e do Rafa ainda se cruza. Dependem um do outro para certas entregas. O silêncio deles, agora, é mais perturbador do que a discussão acalorada de terça. É um silêncio cheio de subentendidos, de mensagens que não são ditas, mas que são percebidas. Um NULL pointer exception social, por assim dizer.
Acho que a primeira coisa, e talvez a mais difícil, é reconhecer que o dano está feito. Não adianta fingir que não aconteceu. É como um bug silencioso em produção: ele está lá, minando a confiança, até que uma hora tudo colapsa. E ninguém quer ser o primeiro a admitir. O introvertido aqui, então, menos ainda. Fico pensando em como abordar, qual a melhor API para iniciar essa conversa. Um ping casual no chat? Um e-mail mais formal? Ou esperar uma oportunidade em alguma daily? A última opção me parece a mais arriscada, o terreno menos controlado.
Talvez o ponto não seja “reconstruir”, no sentido de levantar algo do zero, mas “refatorar” o que já existe. Olhar para o código, identificar os pontos de atrito, as variáveis mal nomeadas, as funções que fazem mais do que deveriam. No caso das pessoas, seria entender o que levou àquela explosão, o que estava por trás da argumentação técnica que virou pessoal. Cansaço? Pressão? Uma história de desentendimentos menores acumulados? Em TI, a gente sabe que muitas vezes o bug aparente é só um sintoma de algo mais profundo.
Pensei em situações em que o respeito foi reconstruído. Geralmente, não é com uma conversa dramática. É com pequenos gestos. Um code review bem feito, onde o feedback é específico e sobre o código, não sobre a pessoa. Um oferecimento de ajuda em um bug urgente. Compartilhar um insight que resolve um problema que o outro estava enfrentando. Coisas pequenas, quase banais, mas que, somadas, vão alterando o state da relação, redefinindo as flags de confiança. É um deploy contínuo de boa vontade.
O feedback, por exemplo. Muitas vezes é dado de forma “genérica” ou “construtiva”, mas parece um ataque pessoal. O desafio é tirar o ego da equação. Focar no problema, não no executor do problema. “Essa implementação pode causar um gargalo aqui”, em vez de “você fez essa implementação errada”. A diferença é sutil, mas o impacto no receptor é enorme. É a diferença entre um erro no log e uma falha crítica de sistema.
Também percebo que, às vezes, o silêncio pode ser mal interpretado. Eu, por ser mais na minha, já fui visto como desinteressado ou até arrogante, quando na verdade estava só processando a informação. Numa equipe onde a comunicação já está fragilizada, esse tipo de silêncio é ainda mais perigoso. Ele abre espaço para suposições, para preencher lacunas com o pior cenário possível. É como um timeout de rede; a ausência de resposta não significa que não há processamento, mas pode ser interpretada como tal.
Não sei se há uma fórmula. Acredito que é um processo. Quase como a evolução de um sistema. Você não faz um redeploy completo a cada erro. Você patch aqui, refatora ali, testa, monitora. E a cada interação, espera que a confiança e o respeito se restabeleçam. Não de uma vez, mas aos poucos. Um commit por vez, talvez. Sem grandes expectativas de que um único evento resolva tudo. O rollback de um desentendimento profundo é um caminho longo, com muitas etapas.
Ainda sinto o peso daquele silêncio, então. E, sinceramente, não sei bem como vai ser. Há um incômodo que persiste, uma sensação de que as coisas estão um pouco fora do lugar. Talvez seja como um daqueles bugs intermitentes, difíceis de reproduzir, mas que a gente sabe que estão lá, prontos para reaparecer no pior momento.
