A luz do monitor já projeta sombras longas no meu canto da sala. Silêncio. Ou quase. O barulho do ar condicionado, constante, e o clique suave do meu mouse são a trilha sonora do fim do dia. Mais uma daily meeting, mais uma onde minhas contribuições foram concisas. Talvez concisas demais. Aquela sensação de que o que eu disse foi entendido, mas não sentido, sabe? Como se a profundidade da coisa ficasse subentendida, não pela clareza, mas pela minha própria incapacidade ou falta de vontade de mastigar cada detalhe.
É estranho, essa dança entre o que se sabe e o que se comunica. A gente passa horas debruçado em um problema, decompõe a arquitetura, refatora um pedaço de código complexo, e no fim, na hora de apresentar, parece que a parte mais difícil é não o problema em si, mas a narrativa dele. Como um bug silencioso que fica ali, latente, só esperando a condição certa pra aparecer e derrubar tudo. A gente sabe que ele existe, sabe a raiz, mas convencer os outros da sua iminência… ah, essa é outra história.
Sempre me pego pensando nisso quando o assunto é “autoridade técnica”. Parece que existe uma correlação direta entre o volume de palavras proferidas e o peso das ideias. Já vi tanta reunião longa, com tanto bla-bla-bla, tanto desvio do foco original, que chega a dar um cansaço só de lembrar. Prazos estourando por falta de alinhamento, não por falta de gente trabalhando, mas por gente demais falando sem chegar a um ponto. E eu ali, absorvendo, processando, muitas vezes com a solução na ponta da língua, mas a barreira do “interromper é falta de educação” me segurando. Ou, pior, a dúvida se o que eu tenho a dizer realmente vale a pena quebrar o fluxo. E o silêncio, claro, quase sempre interpretado como desinteresse. Como se a ausência de som significasse ausência de pensamento.
A questão do feedback é outra que me pega. Quantas vezes o “está tudo bem” significa que ninguém realmente olhou a fundo, ou que a pessoa não soube como verbalizar uma crítica construtiva? Ou, o inverso: você gasta tempo em um code review, aponta falhas que podem gerar um deploy problemático, e a resposta é um “ok” seco. Não tem debate, não tem aprofundamento. É quase como se o meu olhar técnico, que detectou aquela falha sutil, não tivesse o peso de uma “opinião” mais vocalizada.
Lembro de uma vez, um problema com uma integração. O backlog estava abarrotado, mas eu sabia que se aquele ponto específico não fosse tratado, teríamos retrabalho. Passei os detalhes em um email, bem técnico, com os logs e a análise. A resposta veio um dia depois, curta: “Entendi. Vou ver.” E o item ficou lá, patinando. No final, o retrabalho aconteceu. Não foi por falta de aviso, foi por falta de conexão. Minha comunicação foi eficaz no nível técnico, mas não no nível de impacto.
E aí, a gente tenta se adaptar. Tenta colocar mais “carnal” nas palavras, tenta antecipar as objeções, tenta desenhar o cenário completo. Mas é exaustivo. É como tentar refatorar um código gigantesco que você não escreveu, sem a documentação adequada. Você sabe onde quer chegar, mas cada passo é uma descoberta, um desvio.
Existe uma diferença, eu acho, entre ser ouvido e ser levado a sério. O introvertido muitas vezes é ouvido. As pessoas são educadas, prestam atenção quando a gente fala. Mas ser levado a sério… isso parece exigir um certo tipo de performance, uma presença que nem sempre é natural pra gente. É como um bug que não causa um crash imediato, mas corrói a performance ao longo do tempo. É difícil justificar um “conserto” quando o sistema aparentemente funciona.
Às vezes, penso que a autoridade técnica para quem não é de “falar muito” precisa ser construída de outras formas. No código limpo, nas soluções elegantes, nos relatórios detalhados que mostram o problema antes que ele exploda. É uma autoridade silenciosa, que se prova na resiliência do sistema, na diminuição dos bugs, na eficiência da entrega. Mas essa prova é lenta, é quase invisível no dia a dia. É como um processo de build que, por ser automatizado, ninguém vê o trabalho pesado por trás.
A gente vive em um ambiente onde o “fazer acontecer” muitas vezes se confunde com o “aparecer que está fazendo acontecer”. E essa é uma armadilha constante. O trabalho de bastidor, o planejamento meticuloso, a antecipação de problemas que não ocorreram graças ao seu esforço… isso raramente gera aplausos. É um pouco como a diferença entre uma refatoração bem-sucedida, que torna o código mais robusto, e uma nova feature brilhante que todo mundo vê e usa. A feature brilha, a refatoração previne a dor de cabeça futura.
Talvez o segredo não seja tentar ser quem a gente não é, forçar a voz onde o silêncio é mais natural. Talvez seja encontrar maneiras de fazer a qualidade do nosso trabalho falar por si. Criar artefatos que comuniquem a complexidade do que fazemos, que traduzam a profundidade do nosso pensamento técnico em algo tangível. Documentação, diagramas claros, exemplos de código que são quase didáticos. Uma espécie de “testemunho” do nosso conhecimento, sem que a gente precise discursar a respeito.
Porque, no fundo, o que a gente quer é que a solução funcione, que o sistema seja estável, que o time avance. E se a gente consegue fazer isso bem, mesmo que em silêncio, a autoridade deveria vir. Mas não vem. Ou, pelo menos, não da forma que o mundo parece esperar. E a gente fica com essa sensação de que ainda há um gap, uma falha silenciosa entre a intenção e o reconhecimento.
É como se a gente estivesse sempre ajustando o foco de uma lente, tentando capturar a imagem perfeita, mas o mundo em volta não parasse de se mover. E a cada ajuste, a gente se questiona se o problema está na lente, no objeto, ou apenas na nossa própria maneira de enxergar.
Ainda é uma questão meio borrada na minha cabeça. Essa história de construir autoridade sem fazer barulho é um nó que parece nunca se desfazer por completo.
