No fim do dia, a tela do VS Code já nem faz tanto sentido. Os parênteses e chaves se misturam, e a linha de código parece um emaranhado de pensamentos que se recusam a se organizar. É essa hora, quando o barulho do escritório finalmente cede lugar ao silêncio dos meus próprios fones de ouvido, que a cabeça começa a processar o que realmente aconteceu. Ou o que não aconteceu.
Hoje foi mais um daqueles dias. Uma reunião atrás da outra, quase todas orbitando o mesmo problema, mas sem nunca realmente cravá-lo. Eu ali, observando, ouvindo, processando cada fala, cada nuance, cada interrupção. O fluxo parecia tão óbvio na minha cabeça, a sequência lógica para desatar aquele nó. Mas falar… colocar aquilo para fora, no meio daquele turbilhão de vozes, parecia exigir uma energia que simplesmente não estava disponível. Não ali, não daquele jeito.
E é aí que entra essa coisa de “matriz de decisão”. Não uma matriz formal, com eixos e quadrantes bonitinhos, mas uma espécie de rabisco mental, uma heurística de batalha para quem, como eu, prefere a quietude da lógica ao embate da oratória. Porque a gente precisa decidir, e rápido. Especialmente quando a inação ou a decisão errada impacta o código, o backlog, a daily.
Pensei no que meu antigo líder, o Marcos, costumava dizer. Ele era um cara barulhento, expansivo, e adorava um whiteboard cheio de rabiscos. Pra ele, a decisão era um ato quase físico, um “vamos lá, galera, quem tá comigo?”. Eu sempre admirei a energia, mas nunca consegui replicá-la. Meu processo é outro. É mais como um debugger interno, pausando cada variável, inspecionando o estado da memória.
A primeira linha dessa minha matriz invisível é sempre: “Qual é o custo do silêncio agora?”. Não o silêncio do líder, mas o meu. Se eu não falar, o que acontece? Um bug silencioso, que só vai aparecer em produção? Um atraso que vira bola de neve? Um caminho que a equipe vai seguir por puro desconhecimento de uma alternativa mais simples? Esse é o gatilho, a primeira checagem. Se o custo for alto, a gente respira fundo e tenta.
Teve uma vez, no projeto daquele sistema de relatórios, que o time estava discutindo uma abordagem para o cache. Eu tinha refatorado um módulo parecido no projeto anterior e sabia exatamente onde estavam as armadilhas. Vi o pessoal inclinando para uma solução que parecia boa na superfície, mas que ia dar uma dor de cabeça em escala. Minha primeira reação foi esperar, ver se alguém mais percebia. Ninguém percebeu. O silêncio estava me custando o retrabalho futuro. Tive que me forçar a interromper, a desenhar o fluxo no ar, a mostrar o ponto de falha. Não foi bonito, não foi eloquente, mas salvou um deploy problemático.
A segunda linha é sobre o “formato”. Se eu preciso me manifestar, qual a melhor forma? É na reunião, no meio do auê? Ou é melhor um comentário no Pull Request? Um e-mail com um raciocínio mais completo? Uma conversa rápida no Slack depois que a poeira baixar? Eu aprendi, na marra, que tentar competir com quem tem voz alta em um call de 30 pessoas é receita para frustração. Melhor calibrar a entrega.
Lembro de uma daily onde o feedback sobre uma feature estava ambíguo. A gerente de produto parecia satisfeita, mas o cliente, nas entrelinhas, não estava. Eu sentia que algo estava faltando, mas a daily é rápida, um flash. Não era o lugar para destrinchar. Então, depois, mandei uma mensagem direta para a gerente de produto, com prints e pontos específicos. Não foi uma crítica, foi uma observação técnica: “Essa parte X pode gerar confusão por causa de Y.” Ela entendeu, e conseguimos ajustar antes que virasse um problema maior. O formato fez a diferença.
A terceira linha, talvez a mais difícil, é a da “energia”. Quanto de mim eu consigo colocar nisso sem me esgotar completamente? Porque não é só falar. É processar a reação, é lidar com a contra-argumentação, é manter a linha de raciocínio quando o ambiente é caótico. Às vezes, a bateria simplesmente não está cheia. Nesses momentos, entender como delegar tarefas sem parecer mandão também se torna parte da estratégia. E nessas horas, a matriz me diz para priorizar, para escolher as batalhas.
Não é sobre fugir da responsabilidade. Longe disso. É sobre reconhecer as próprias limitações de processamento em tempo real e encontrar rotas alternativas. Se a decisão não pode esperar e a minha capacidade de intervenção direta na reunião é zero, talvez seja hora de cutucar o colega que é mais expansivo, passar a informação para ele, deixá-lo ser o porta-voz. Esse tipo de estratégia aparece também no artigo sobre tech leads introvertidos delegar e motivar equipes, onde a delegação estratégica se torna uma ferramenta de liderança.
Essa matriz, ainda inacabada, ainda torta, é um espelho do meu jeito de ser. Não é um guia para ninguém, é só o meu próprio mapeamento interno das complexidades. Reconhecer o problema nos outros, na forma como a dinâmica se estabelece, e tentar achar um jeito de ainda assim contribuir, ainda assim mover a agulha, sem precisar ser o centro das atenções. É um balé complexo entre a observação silenciosa e a intervenção cirúrgica, uma busca constante pelo ponto de equilíbrio.
No fim das contas, a gente está sempre tentando otimizar. Otimizar o código, otimizar o processo, otimizar a própria interação. E para nós, que processamos o mundo em ciclos de clock mais lentos e com menos ruído externo, essa otimização passa por entender onde, quando e como a nossa contribuição, por mais silenciosa que seja, pode ser mais eficaz. O desafio não é mudar quem somos, mas aprender a operar no nosso melhor modo.
Essa coisa de ser um líder, ou apenas um profissional tentando liderar um pedaço de código ou um fluxo de trabalho, sendo introvertido, ainda é um tópico que me faz divagar. Parece que a gente tá sempre em busca da sintaxe correta para se fazer entender sem ter que reescrever o próprio sistema operacional. Muitas vezes esse processo acontece antes mesmo de percebermos os sinais de que você já age como líder técnico dentro do time. Ainda não cheguei lá, claro. Mas cada dia é uma nova iteração, um novo commit tentando refinar a branch principal.
