Existe um momento na carreira de muitos desenvolvedores sênior em que a pergunta surge naturalmente: continuo crescendo na trilha técnica ou assumo a gestão de pessoas?
Durante anos tratei essa como uma escolha excludente. Ou você era o arquiteto que sabia tudo sobre o sistema, ou era o gestor que organizava sprints e one-on-ones. A realidade, isso aprendi na prática, é bem mais rica do que esse dilema binário.
O mito da gestão como abandono técnico
Quando assumi minha primeira coordenação, senti uma pressão implícita para "largar o teclado". Reuniões, relatórios, 1:1s — de repente o calendário do google estava cheio e o vscode (IDE que costumo utilizar) ficava dias sem abrir. Achei que era assim que deveria ser.
O problema apareceu rápido: perdi a capacidade de fazer perguntas boas durante os refinamentos. Deixei de entender o custo real das decisões de arquitetura. Pior de tudo, o time percebeu. A credibilidade técnica, que é a base de qualquer liderança em engenharia, começou a erodir.
Como reequilibrei
A virada foi entender que liderança técnica não é sobre saber mais do que o time — é sobre manter fluência suficiente para fazer as perguntas certas e proteger o time de decisões ruins vindas de cima.
Algumas práticas que adotei:
- Reservo blocos de código semanais. Não são os maiores, mas são sagrados. Contribuo em features menores, faço code review ativo, ajudo a destravar bugs em par.
- Participo dos refinamentos como desenvolvedor. Não só como facilitador. Leio o código antes das reuniões, trago dúvidas técnicas reais.
- Uso minha visão de gestor para proteger o time técnico. Sei quando uma demanda de negócio vai gerar dívida técnica inaceitável. E sei como traduzir isso para a liderança de produto de forma que faça sentido para eles.
O papel da confiança
Nenhum desses ajustes funciona sem um ingrediente fundamental: confiar no time para executar sem microgestão.
Um dos maiores erros que cometi no início foi querer revisar tudo. Além de insustentável, enviava uma mensagem errada — de que eu não confiava nos desenvolvedores. Quando aprendi a delegar com contexto claro (o porquê da tarefa, não só o o quê), o time cresceu e eu ganhei espaço para atuar no que só eu podia fazer.
Para quem está nessa transição
Se você está chegando na liderança técnica agora, meu conselho principal é: não abandone a técnica, calibre sua profundidade. Você não precisa ser o melhor programador da sala, mas precisa entender o suficiente para liderar com credibilidade.
E principalmente: a maior entrega de um tech lead não é o código que ele escreve, é o ambiente que ele cria para que outras pessoas escrevam código excelente.