O 1:1 tinha acabado cinco minutos antes da hora marcada. Silêncio.
É sempre o mesmo silêncio, não importa a empresa, o manager ou o fuso horário. Aquele ponto final na conversa que não é bem um ponto final, mas um ACK silencioso de que a transmissão foi recebida, mas não processada por completo. Eu tinha dado a atualização sobre a refatoração, o impacto no latency e como a nova estrutura de dados ia simplificar os deployments daqui a três meses. Coisas que, na minha cabeça, eram o relatório perfeito do porquê a gente deveria começar a discutir o próximo nível.
O gerente só disse: “Ótimo. Bom trabalho, podemos encerrar por aqui”.
Nenhuma palavra sobre a progressão. Nenhuma pista. De novo, o silêncio.
E é aí que a gente, que prefere interagir com o terminal a ter que decifrar a política de escritório, se perde. Porque o sistema é barulhento. Ele premia a voz, a exposição, a promessa de entrega. A gente, por outro lado, se concentra na entrega real. A diferença entre o código que funciona e o código que funciona bem geralmente é invisível até que um problema silencioso se manifeste, um daqueles bugs que não dão stack trace e consomem um dia inteiro.
O que eu tenho tentado entender, escrevendo aqui no final do dia — depois que o barulho da casa e do Slack pararam —, é como esse nosso trabalho, que é inerentemente silencioso, pode se traduzir em avanço de carreira sem que a gente precise se desdobrar em um personagem de autoajuda corporativa. Não se trata de pedir duas vezes, mas de não precisar pedir. O que eu percebi é que a promoção não é um evento; é uma falha silenciosa no sistema de gestão que, de repente, é corrigida.
O Código como Testemunho Inegável
A primeira estratégia, se é que podemos chamar isso de estratégia e não apenas de sobrevivência, é fazer com que o diff da sua Pull Request seja um registro de impacto mais eloquente do que qualquer discurso no stand-up.
A gente gasta tempo demais tentando explicar nosso valor em palavras. É exaustivo traduzir o benefício de uma cache bem implementada para a linguagem de negócios.
O caminho menos custoso para o introvertido é empurrar o impacto para a base de código. Se você está fazendo refatoração que reduz a complexidade ciclomática de um módulo crítico pela metade, você não precisa dizer que melhorou a saúde do código. O histórico do Git diz por você.
É o que eu chamo de liderança passiva. O Tech Lead que consegue uma promoção não é o que fala mais, mas o que elimina o maior número de futuros problemas na raiz. O código limpo é um feedback contínuo para quem revisa, para quem debuga, e, eventualmente, para quem avalia. Ele se acumula, silenciosamente. Quando chega o momento da avaliação formal, a conversa não é sobre a sua performance ambígua, mas sobre uma coleção de artefatos inegáveis. “Aqui, veja os 20 serviços que não caíram no último trimestre. Minha intervenção.” É uma abordagem analítica para um problema humano.
Antecipar o Silêncio do Backlog
O segundo ponto que me incomoda é a passividade no backlog. A gente se apega à ideia de que só deve trabalhar no que está explicitamente atribuído. Mas o salto de júnior para sênior, ou de sênior para líder técnico, não é sobre completar tarefas; é sobre definir quais tarefas importam.
A promoção acontece quando você começa a operar no nível de abstração superior ao seu título atual.
O que isso significa, na prática, para alguém que odeia reuniões de planejamento? Significa caçar as dependências não escritas.
Quantas vezes você viu um ticket que dizia “Melhorar a performance de X” e que, na verdade, era um sintoma de uma arquitetura podre em Y? O profissional que espera o ticket está preso no nível da execução. O profissional que se promove silenciosamente é o que abre um spike não solicitado, mapeia a podridão em Y e adiciona um comentário detalhado no ticket original, dizendo: “A causa raiz está aqui, o retorno sobre o investimento será maior se atacarmos Y antes de X. Já fiz a análise inicial.”
Isso é trabalho invisível para o sistema de gestão de projetos. Não está no Trello. Mas está na cabeça do seu gerente e dos seus pares. É a diferença entre esperar a água começar a ferver (o prazo estourado) e ajustar o termostato da caldeira duas horas antes. É o trabalho que evita a reunião de crise. E é o que eu tenho tentado cultivar: o hábito de prevenir o barulho, em vez de reagir a ele. O alívio de não ter que participar de uma reunião emergencial é a prova mais concreta da sua eficácia.
O Feedback Silencioso, Mas Estruturado
A terceira e mais difícil parte é a gestão da expectativa. O manager não vai adivinhar seu próximo passo, mas pedir diretamente parece sempre tão… mercantil.
O que eu percebi é que a gente não deve pedir uma promoção. A gente deve apresentá-la como um estado de fato, com a sutileza de um deploy em produção às 2 da manhã.
Eu comecei a manter um diário de impacto. Não um brag document cheio de adjetivos, mas uma folha de cálculo fria. De um lado, as responsabilidades e métricas do meu nível atual (L4, digamos). Do outro, as responsabilidades e métricas do próximo nível (L5). E no meio, em uma coluna separada, o que eu já estava fazendo que se encaixava no L5.
Por exemplo: L5 Responsabilidade: Mentoria de dois juniores. Minha coluna: Instalei um processo de revisão de código mais rigoroso com a Maria e o Pedro, resultando em 30% menos bugs de integração no último mês.
Quando o 1:1 de avaliação chega, eu não digo: “Eu quero uma promoção”. Eu digo: “Aqui está o meu registro de impacto. Pela descrição do L5, eu já estou operando 70% acima do meu escopo atual. Podemos alinhar a compensação a este escopo, ou há alguma área que você vê como deficiente?”
É uma declaração analítica. Não é um pedido, é uma negociação baseada em dados que você construiu em silêncio por meses. Você remove a ambiguidade da conversa porque transformou o silêncio em dados concretos. A promoção, então, não é mais um favor ou uma negociação de poder, mas o reconhecimento lógico de um desequilíbrio: você está entregando L5 e sendo pago por L4.
É exaustivo ter que gerenciar a percepção do seu trabalho tanto quanto o trabalho em si. A gente só queria escrever código que resolvesse problemas de forma elegante e ir para casa. A realidade é que, para progredir, o profissional técnico precisa se tornar, minimamente, um comunicador eficaz do seu próprio silêncio.
Eu percebi que essa necessidade de traduzir o trabalho quieto para a linguagem do valor executivo não termina quando você chega em um posto de liderança, pelo contrário. Aí a gente passa a ter que traduzir o silêncio do time inteiro. O desafio é outro: como fazer essa gestão de expectativas e essa delegação sem precisar ser o centro do barulho, sem gastar toda a energia que você poupou no desenvolvimento.
A questão é que essa tradução do silêncio para o valor é uma tarefa constante. É como um re-deploy sem fim do seu próprio valor, e esgota, porque no fim o que a gente quer é só codar bem, sem esse teatro todo. Mas aí a gente vira Tech Lead, e o problema muda de escala. Não é mais só o seu silêncio que precisa ser traduzido, mas o silêncio de quem reporta para você. Ficar calado não é uma opção quando o trabalho precisa ser empurrado para a frente, e a gente não pode simplesmente assumir todas as tarefas porque tem gente no time que, como nós, prefere que o código fale por eles.
