A tela do monitor ainda está quente, a luz fraca da madrugada entrando pela janela. Mais um dia encerrado. Ou quase. A mente, por algum motivo, resolveu que agora seria a hora perfeita para revisitar aquele incômodo que vem rondando, tipo um bug intermitente que você sabe que está lá, mas não consegue reproduzir consistentemente. “Como Vencer o Medo de se Tornar Referência Técnica”, o título na minha cabeça soa um pouco grandioso demais, ou talvez irônico. Não é bem sobre “vencer”, mas mais sobre entender essa barreira silenciosa.
Lembro de uma daily de ontem. O time todo ali, e a discussão sobre um problema no pipeline de CI/CD. Eu tinha uma ideia, uma abordagem que já usei em outro projeto. Mas fiquei quieto. Observei. Deixei o outro colega apresentar a solução dele, que também era válida. E depois, no privado, ele veio me perguntar se eu tinha alguma sugestão, porque a dele parecia ter um ponto fraco. E eu, com um certo alívio e uma pontinha de arrependimento, compartilhei a minha. Por que não na hora? É sempre a mesma pergunta. O silêncio. Um silêncio que, às vezes, é interpretado como falta de interesse, ou pior, incompetência, quando na verdade é só… um silêncio.
Ser “referência técnica”. A frase já traz um peso. É como se você tivesse que carregar uma tocha, liderar a expedição. Mas a gente só quer codar, fazer a coisa funcionar, refatorar um legado que daria um artigo à parte. E aí vem a cobrança, nem sempre explícita, de que você deve se posicionar, deve ter as respostas, deve ser o farol. E o medo… o medo de que a tocha apague.
Essa sensação, ela não é de agora. Vem de outras reuniões onde eu tinha certeza de que a abordagem A era melhor que a B, mas o consenso foi pra B. E eu não insisti. Talvez por cansaço de uma discussão infrutífera. Talvez por não querer parecer “o chato” que sempre discorda. E o resultado? Meses depois, a abordagem B dando problema, e a gente refatorando pra algo muito parecido com a A original. O que custava ter falado mais alto? O que custava ter defendido o ponto? O custo é sempre maior depois, disso eu tenho certeza.
É um paradoxo, essa coisa de querer ser bom no que faz, mas recuar quando a oportunidade de mostrar isso aparece. É como ter um bug na sua própria lógica. Você testa, debuga, e o problema continua lá, intermitente. Você sabe que tem a capacidade, mas na hora H, algo trava. Uma falha silenciosa. Aquela que não derruba o sistema, mas impede uma otimização importante. Impede um deploy mais rápido.
Não é sobre arrogância, nem sobre querer ser o “dono da verdade”. É sobre ter a confiança de que o que você tem a contribuir é valioso. Mas o processo de chegar a essa confiança é tortuoso. Ele passa por code reviews onde um detalhe é apontado, e você passa a duvidar de tudo. Passa por um feedback ambíguo de um gestor, que diz que você é bom, mas precisa “aparecer mais”. O que diabos significa “aparecer mais”? É dar palpite em tudo? É forçar a barra?
Esses pensamentos voltam e voltam. É como um loop infinito no código que eu ainda não consegui otimizar. A gente se dedica tanto a resolver problemas externos, a otimizar sistemas, a entender a lógica de frameworks complexos, mas a lógica interna, essa, muitas vezes, fica num limbo de “depois eu vejo”. E o “depois” nunca chega, e o medo de se expor, de ter a sua solução questionada, de não ter a resposta para uma pergunta inesperada, ele persiste.
O medo não é de errar, exatamente. Acho que a gente, de TI, convive com o erro o tempo todo. Faz parte. É o medo de ser o errado. O medo de que o erro seja a sua marca, o seu “bug” pessoal. De ser o cara que se posicionou e errou, enquanto os outros ficaram quietos e “certos”. É uma armadilha, essa. Porque quem fica quieto nunca erra em público, mas também nunca acerta em público. E o impacto, no fim das contas, é o mesmo: a não contribuição plena.
Talvez não seja sobre vencer o medo, mas sobre entender que ele é parte do processo. É como quando a gente faz um deploy importante. Aquele frio na barriga, a checagem tripla de tudo, a sensação de que algo pode dar errado. Mas a gente faz. Porque o sistema precisa ir pro ar. Talvez essa “referência técnica” seja só mais um deploy, uma entrega, um passo adiante, mesmo com o frio na barriga.
Fico pensando que, no fundo, a gente busca um certo tipo de validação. Não é pra ser elogiado, mas pra ter a certeza de que o que a gente faz, pensa, sugere, realmente faz diferença. E essa validação, muitas vezes, só vem quando a gente se arrisca a sair do silêncio. É uma refatoração constante, interna. Um passo de cada vez. Aos poucos.
Ainda não sei a resposta definitiva. Não há um manual, um playbook. É uma daquelas coisas que se manifestam de formas diferentes para cada um. Mas escrever sobre isso, mesmo que de forma tortuosa e sem um caminho claro, já é um jeito de começar a entender a lógica desse “bug” interno. E talvez, só talvez, encontrar um patch.
Ainda é estranho pensar em se expor, em falar mais alto. A inquietação persiste, um eco da daily de ontem. Mas a clareza de que essa inércia tem um custo, isso, pelo menos, se solidifica.
