Você teve um engenheiro sênior brilhante, com anos de experiência, e ele saiu depois de quatro meses. Na entrevista de desligamento, disse que o trabalho em si estava bom. O problema era o gestor: reuniões sem pauta, feedback só quando algo dava errado, nenhuma conversa sobre pra onde ia a carreira dele.
É um padrão conhecido em tech: as pessoas não pedem demissão da empresa, pedem demissão do gestor direto. Em times remotos, esse efeito se multiplica, porque o gestor é praticamente o único ponto de contato humano que um desenvolvedor tem com a empresa. Se essa relação não funciona, não tem escritório bonito nem salário competitivo que compense.
Como melhorar como Engineering Manager de um time remoto
1. Faça da 1:1 semanal uma prioridade de verdade, não uma caixinha pra marcar
Cancelar a 1:1 quando o trabalho aperta é a forma mais rápida de dizer pro seu liderado que ele não importa. Se você tem oito pessoas no time, são oito horas por semana no máximo, e é o investimento com melhor retorno que você vai fazer como gestor. Use esse tempo pra falar sobre o que está travando a pessoa, não pra pedir status da sprint, pra isso já existe a daily.
2. Defina o que significa fazer bem o trabalho em cada função
Criar clareza nas expectativas é provavelmente o trabalho mais importante de um gestor de engenharia. Existem três níveis de metas que um dev precisa ter claros pra render bem:
Metas do time: pra onde vai a arquitetura ou o produto neste trimestre, e por quê. Metas individuais: o que essa pessoa está desenvolvendo especificamente, seja uma skill técnica, liderança técnica ou ownership de um módulo. Prioridades da semana: qual é a única coisa que realmente importa entregar, pra que a pessoa não passe o dia inteiro apagando incêndio.
Se tudo é prioridade, nada é. Seu trabalho é filtrar o ruído antes que ele chegue ao time, não repassar exatamente como chegou até você.
3. Delegue o que já não é mais o seu trabalho, não só o que sobra
O erro mais comum ao passar de IC sênior pra gestor é continuar revisando cada PR como se você ainda fosse o dono do código. Delegar de verdade significa identificar quais tarefas ocupam seu tempo sem precisar do seu julgamento específico, e soltá-las, mesmo que você faça mais rápido sozinho. Se você continua sendo o gargalo técnico do time, você não está gerindo, está adiando seu próprio papel.
4. Dê feedback específico, não o sanduíche do elogio
Dizer bom trabalho com a feature, mas revisa o naming não ajuda ninguém a melhorar. O feedback que muda comportamento é concreto: o que aconteceu, que impacto teve, o que você espera da próxima vez. E precisa ser dado perto do momento em que aconteceu, não guardado pra revisão trimestral.
5. Faça coaching em vez de resolver tudo sozinho
A maioria dos gestores chegou ao cargo por ser bom em resolver problemas técnicos. O instinto de dar a resposta direta quando alguém do time está travado é forte, mas cada vez que você faz isso, tira dessa pessoa a chance de aprender a resolver sozinha. Perguntar o que você já tentou ou quais opções você vê antes de intervir gera times mais autônomos, mesmo que no começo seja mais lento.
6. Não vire a cara pra quem rende muito mas maltrata o time
Quando um gestor não lida com o mau comportamento do seu engenheiro estrela (aquele que arrasa os juniores no code review, que só responde pro CTO), ele está dizendo pro resto do time que resultado importa mais do que como vocês se tratam. É uma das formas mais rápidas de perder as pessoas boas que realmente sabem trabalhar em equipe.
Ser um bom gestor de engenheiros remotos não é um talento inato, é uma prática que se exercita reunião após reunião. A métrica real de que você está indo bem não é quanto código o time entrega essa semana, é se, daqui a um ano, as pessoas que você tem hoje ainda estão lá, e ainda querem estar.
