O que muda de verdade quando você vira manager
A mudança mais difícil não é aprender a fazer 1:1s ou escrever avaliações de performance. É a mudança na relação com o próprio trabalho. Como desenvolvedor, você sabe que fez um bom dia de trabalho quando o código funciona, o teste passa, o PR vai para review. O feedback é quase imediato.
Como gestor, o feedback é atrasado, indireto e frequentemente ambíguo. Você teve uma boa semana se o time parece mais alinhado, se aquele desenvolvedor que estava travado finalmente desbloqueou, se uma decisão que você tomou há três semanas provou ter sido a certa. Isso é muito mais difícil de sentir e de medir.
O que ninguém conta no momento da promoção: você vai passar meses sem sentir que está sendo produtivo, mesmo quando está fazendo um trabalho excelente. Isso é normal. A maioria das pessoas que fazem essa transição sem suporte luta com esse sentimento por 6 a 18 meses.
O luto do código (e por que é real)
Chamar de "luto" não é exagerado. Para a maioria dos desenvolvedores que se tornam managers, codar não era apenas uma função profissional — era uma fonte de identidade, fluxo e satisfação genuína. A relação com o computador, com os problemas lógicos, com a sensação de construir algo que funciona — tudo isso diminui drasticamente quando você vira gestor.
Muitas pessoas reagem a esse luto com uma das duas estratégias erradas: ou continuam codando muito mais do que deveriam (o que cria um gargalo técnico e impede o time de crescer), ou abandonam completamente o código e ficam tecnicamente desconectados (o que enfraquece a credibilidade técnica e a capacidade de tomar boas decisões).
A posição saudável fica no meio: manter contato com o código de forma deliberada e com escopo limitado. Contribuir com código que não esteja no caminho crítico. Fazer code reviews com profundidade. Participar de decisões arquiteturais. Manter o vocabulário técnico vivo sem ser o gargalo da execução.
"Você não está abandonando o que te trouxe até aqui. Você está expandindo o escopo do que pode construir — de sistemas para pessoas e organizações."
As armadilhas dos primeiros 90 dias
Os primeiros 90 dias são onde a maioria dos gestores primários comete os erros mais duradouros. Esses erros são compreensíveis — vêm de instintos que funcionavam muito bem como desenvolvedor mas não funcionam como gestor.
Armadilha 1: resolver problemas técnicos que o time poderia resolver
Como dev, você resolveu problemas. Era isso que trazia satisfação e reconhecimento. Como gestor, resolver problemas técnicos que o time poderia resolver sozinho é um custo — impede que as pessoas desenvolvam autonomia e mantém você preso em trabalho de execução quando deveria estar trabalhando em nível de liderança.
Armadilha 2: mudar tudo porque você tem ideias melhores
Chegar com uma lista de melhorias e começar a implementá-las na primeira semana é um erro clássico. Mudanças antes de você entender o sistema completo — os trade-offs que levaram às decisões atuais, as dinâmicas do time, o contexto histórico — frequentemente criam mais problemas do que resolvem. Passe as primeiras semanas ouvindo, não mudando.
Armadilha 3: evitar conversas difíceis
Desenvolvedores raramente precisam dar feedback direto sobre comportamento ou ter conversas sobre performance. Gestores precisam disso constantemente. A tentação é adiar essas conversas — especialmente quando você virou gestor de colegas que eram pares. Evitar essas conversas cria problemas que crescem exponencialmente. Quanto mais cedo você pratica essas conversas, mais rápido você se torna um gestor capaz de ter elas.
Construindo credibilidade com o time
Credibilidade como gestor é diferente de credibilidade como desenvolvedor. Como dev, credibilidade vem do código que você escreve, das decisões técnicas que você toma, do conhecimento que você demonstra. Como gestor, credibilidade vem de comportamento consistente ao longo do tempo.
O que constrói credibilidade de gestor em times técnicos:
- Fazer o que disse que ia fazer: se você prometeu resolver um bloqueio, resolva. Se disse que ia criar uma estrutura de 1:1, mantenha-a. Consistência entre palavra e ação é o alicerce da confiança.
- Defender o time para fora: quando produto empurra por deadline impossível, você não passa a pressão direto para baixo — você negocia. Quando a diretoria quer cortar recursos, você apresenta o impacto. O time precisa saber que você tem as costas deles.
- Ser transparente sobre o que pode e não pode compartilhar: gestores têm contexto que não podem sempre compartilhar. A forma honesta de lidar com isso é dizer "Não consigo compartilhar o raciocínio por trás disso agora, mas entendo que é frustrante e me comprometo a trazer mais contexto quando puder." Isso é muito melhor do que fingir que não há contexto ou inventar uma explicação.
- Admitir quando errou: gestores que nunca admitem erros perdem credibilidade rapidamente em times técnicos. Devs trabalham com evidências. Se a evidência mostra que a decisão foi errada e você não reconhece, eles aprendem a não confiar no seu julgamento.
Se você virou gestor de pessoas que eram seus colegas, a primeira conversa é a mais importante. Seja direto: "Nosso relacionamento mudou. Eu ainda me importo com a sua perspectiva e quero que você seja honesto comigo. Mas eu tenho responsabilidades sobre o time que antes não tinha, e isso vai mudar como tomamos algumas decisões." Clareza sobre a mudança é muito melhor do que fingir que nada mudou.
Como manter o vocabulário técnico sem ser o gargalo
Manter relevância técnica sem travar o time requer uma distinção clara: há diferença entre participar de decisões técnicas e ser quem decide. Um bom gestor técnico participa das discussões de arquitetura com perguntas que aprofundam o raciocínio — "Qual é a nossa estratégia de fallback se esse serviço cair?" — mas delega a decisão final para o desenvolvedor mais apropriado.
Reserve de 10 a 20% do tempo para atividades técnicas: code reviews, participação em discussões de arquitetura, sessões de pair programming ocasionais com devs mais júniors. Isso mantém o vocabulário vivo e a credibilidade técnica ativa sem criar dependência.
Os primeiros 30-60-90 dias
Uma estrutura que ajuda a organizar a transição:
Primeiros 30 dias: escuta ativa. Faça 1:1 com cada membro do time, com o seu gestor e com stakeholders chave. Entenda as dores atuais, as decisões passadas e as expectativas. Não mude nada ainda. Documente o que você observa.
Dias 31-60: intervenções pontuais. Com base no que aprendeu, comece a fazer pequenas mudanças nas áreas de maior impacto. Estabeleça sua cadência de rituais: 1:1s semanais, planning, retrospectiva. Comece a construir a relação com produto e outras equipes.
Dias 61-90: visão e ajustes. Compartilhe com o time como você está pensando sobre o próximo trimestre. Peça feedback sobre como os primeiros dois meses foram. Identifique o maior gap entre onde o time está e onde precisa estar, e proponha um plano para endereçá-lo.