Você é um desenvolvedor sênior excelente. Escreveu código elegante, resolveu problemas complexos e ganhou respeito técnico do time. Agora te ofereceram uma posição de engineering manager. É uma promoção, certo? Sim, mas é também uma mudança radical de carreira. As habilidades que te trouxeram até aqui não são as mesmas que te levarão adiante.
A identidade de quem era programador
A transição mais difícil não é técnica, é emocional. Sua identidade profissional era de alguém que resolve problemas com código. Agora sua ferramenta principal é conversa. Seu output visível era commits e features entregues. Agora seu output é invisível: pessoas crescendo, processos melhorando, conflitos resolvidos antes de explodir.
Nos primeiros meses, você vai sentir que não fez nada produtivo. No fim do dia, nenhuma linha de código escrita, apenas reuniões, conversas e emails. Isso é normal e é o trabalho. A produtividade de um gestor é medida pelo output do time, não pelo seu output individual.
O que muda no dia a dia
Como dev: você tinha blocos longos de foco para codificar. Interrupções eram o inimigo. Feedback era instantâneo ao executar código e ver se funciona. Progressão era visível a cada commit.
Como gestor: seu dia é fragmentado entre one-on-ones, reuniões de alinhamento, recrutamento, planejamento e firefighting. Interrupções são seu trabalho, não distração. Feedback é lento e ambíguo, pois você não sabe se aquela conversa difícil surtiu efeito até semanas depois. Progressão é sutil e difícil de medir.
Os primeiros 90 dias como gestor
Mês 1 ouça mais do que fale: faça one-on-ones com cada membro do time focando em entender motivações, frustrações e expectativas. Não tente mudar nada ainda. Entenda o sistema antes de intervir.
Mês 2 identifique quick wins: resolva 1 a 2 problemas que o time reclama há tempo e que você pode resolver com sua nova autoridade. Pode ser melhorar o processo de deploy, eliminar uma reunião inútil ou aprovar a compra de uma ferramenta pedida há meses.
Mês 3 estabeleça ritmo: defina sua cadência de one-on-ones, planning, retros e reviews. Comunique expectativas e como você pretende trabalhar. Peça feedback sobre seu estilo de gestão.
Habilidades críticas para desenvolver
Delegação: a tentação de resolver tudo tecnicamente é enorme. Resista. Quando um bug crítico aparece, sua reação instintiva será abrir o IDE e resolver. Mas se você faz isso, seu time nunca aprende a lidar com crises e você nunca tem tempo para gestão.
Use a regra: se alguém do time pode resolver em 2x o tempo que eu levaria, delegue. Você economiza seu tempo para tarefas que só você pode fazer, como planejar, recrutar e desenvolver pessoas.
Coaching ao invés de directing: quando alguém traz um problema técnico, não dê a resposta. Pergunte: o que você já tentou? Quais opções está considerando? O que acontece se fizermos X? Ajude a pessoa a chegar à solução sozinha. É mais demorado no curto prazo mas cria autonomia no longo prazo.
Comunicação para cima: como dev, seu gestor traduzia suas necessidades para a diretoria. Agora você faz esse papel para seu time. Aprenda a comunicar progresso, riscos e necessidades de forma que não-técnicos entendam.
Gestão de energia: gestão é emocionalmente drenante. Cada conversa difícil, cada conflito mediado, cada feedback negativo dado consome energia emocional. Cuide da sua saúde mental. Encontre um mentor que já faz gestão. Participe de comunidades de engineering managers.
Mantendo relevância técnica
Não precisa abandonar completamente o técnico. Mas sua relação com código muda: participe de design reviews e architectural decisions. Faça code reviews quando possível, focando em mentoria. Mantenha-se atualizado lendo artigos e participando de conferências. Reserve 10% a 20% do tempo para contribuições técnicas que não estão no caminho crítico.
Não pegue tarefas do sprint do time. Se você assume uma task e fica preso em reuniões, vira gargalo e o time fica bloqueado. Contribua em ferramentas internas, automação de processo ou protótipos exploratórios que não têm deadline.
Quando voltar para IC
Nem todo bom gestor era um dev que queria ser gestor. Se após 6 a 12 meses você percebe que não gosta da rotina de gestão, que sente falta profunda de programar e que lidar com problemas de pessoas te drena ao invés de energizar, tudo bem voltar para a trilha de contribuição individual.
Mudar de volta para IC não é fracasso. É auto-conhecimento. Os melhores Staff e Principal Engineers frequentemente são pessoas que testaram gestão e decidiram que seu impacto é maior contribuindo tecnicamente. O importante é tomar essa decisão conscientemente, com informação suficiente.
Tem um projeto em mente?
Somos especialistas em transformar ideias em produtos digitais. Apps, sites, automações e IA — vamos construir juntos.
