De desenvolvedor a gestor: o que ninguém me contou sobre liderar o time do qual eu fazia parte

Durante boa parte da minha carreira, o meu valor era medido pelo código que eu entregava. Resolver o bug que ninguém achava, desenhar a integração mais complicada, ser a pessoa a quem o time recorria quando algo travava. Até que, um dia, a pergunta mudou: em vez de “o que você entregou?”, passou a ser “o que o time entregou?”.

Virar gestor do time do qual você fazia parte é uma das transições mais difíceis da carreira em tecnologia. Ninguém te entrega um manual. Você continua sentando perto das mesmas pessoas, participando das mesmas reuniões, mas o seu papel, e a forma como te enxergam, mudou da noite para o dia.

Estas são as lições que eu gostaria que tivessem me contado antes.

1. Seu trabalho deixa de ser resolver, e passa a ser destravar

O primeiro instinto de quem vem do desenvolvimento é pegar o problema mais difícil para si. Parece produtivo, mas é uma armadilha: enquanto você está mergulhado em uma tarefa, ninguém está olhando para o sistema como um todo.

O gestor técnico precisa enxergar onde o fluxo está travando: a tarefa parada esperando uma decisão, a dependência de outra área, a pessoa sobrecarregada, o requisito que ninguém entendeu direito. Muitas vezes, a coisa mais valiosa que você faz no dia não é uma linha de código, é uma conversa de 15 minutos que destrava três pessoas.

2. Ex-colegas não viram liderados automaticamente

A relação muda, e fingir que não mudou é pior. Algumas pessoas vão testar limites, outras vão se afastar, e algumas vão esperar favorecimento.

O que funcionou para mim foi ser transparente desde o começo: conversar individualmente com cada pessoa, explicar como eu pretendia trabalhar, o que eu esperava e o que elas podiam esperar de mim. Respeito não vem do cargo; vem da coerência entre o que você diz e o que você faz, todos os dias.

3. Você vai ter que soltar o código (mas não totalmente)

Existe um equilíbrio difícil aqui. Se você continua codando como antes, vira gargalo e deixa a gestão de lado. Se você se afasta completamente, perde a capacidade de avaliar decisões técnicas e de conversar de igual para igual com o time.

O meu ponto de equilíbrio foi continuar perto da arquitetura, das revisões e das decisões técnicas importantes, mas sair do caminho crítico das entregas. Código que só eu entendo, sendo gestor, é risco para o time.

Mas nunca parei de codar. Com menos frequência, claro, mas de tempos em tempos eu assumia um desenvolvimento, nem que fosse uma demanda de sustentação. Era a forma de não perder o conhecimento do produto: saber onde cada coisa acontece dentro do sistema e conhecer os detalhes técnicos que só quem coloca a mão no código conhece.

Isso faz diferença no dia a dia. Consigo identificar e reduzir gargalos mais rápido e responder às dúvidas dos devs com mais agilidade, porque ainda conheço o produto por dentro. Se eu tivesse me afastado totalmente, com o tempo perderia essa habilidade, e eu não queria isso.

4. Feedback é parte do trabalho, não um evento anual

Quando eu era desenvolvedor, feedback era algo que acontecia na avaliação de desempenho. Como gestor, aprendi que feedback precisa ser frequente, específico e próximo do fato.

Elogio público e específico (“a forma como você documentou essa integração economizou horas do time”) vale mais que um “bom trabalho” genérico. E a conversa difícil, quando adiada, só fica mais difícil. Reuniões individuais regulares, mesmo curtas, se tornaram uma das ferramentas mais importantes da minha rotina.

5. Proteger o time também é trabalho

Pressões de prazo, mudanças de prioridade e demandas urgentes chegam o tempo todo. Parte do papel do gestor é filtrar e traduzir: o que é realmente prioridade, o que pode esperar, o que precisa ser negociado.

Isso não significa esconder o contexto do time. Pelo contrário: quanto mais o time entende o porquê das prioridades, melhores decisões toma sozinho. Mas significa não repassar ansiedade sem filtro.

6. Sua métrica de sucesso muda

Talvez a mudança mais difícil seja emocional. Como desenvolvedor, o sentimento de “fiz algo hoje” era imediato. Como gestor, as vitórias são mais lentas e menos visíveis: uma pessoa que cresceu, um processo que ficou mais fluido, um conflito que não escalou, um prazo cumprido sem heroísmo.

Aprendi a medir meu trabalho pelo desempenho e pela autonomia do time, e não só pela minha produção individual, seja como gestor, seja como alguém que continua desenvolvendo.

O que eu faria diferente

Algumas coisas eu acertei desde o início, como conversar individualmente com cada pessoa do time e combinar como seria o meu papel, inclusive em que eu continuaria técnico. Mas, se pudesse voltar ao primeiro dia como gestor, faria uma coisa mais cedo: buscar um mentor ou par fora do time, alguém com quem conversar sobre as decisões difíceis sem expor ninguém.

A transição de desenvolvedor para gestor não é uma promoção do mesmo trabalho. É uma mudança de profissão. E quanto antes a gente aceita isso, mais rápido começa a fazer um bom trabalho.

E você, já passou por essa transição ou está prestes a passar? O que mais te surpreendeu?