Engenheiros seniores caem em espiral ao sumir em projetos solo gigantes

O espiral da morte do engenheiro sênior

Sunil Pai descreve um padrão de fracasso que diz ser o mais comum que já observou, batizado de "senior engineer death spiral". Ele costuma começar quando o engenheiro entra em um emprego novo, recebe uma promoção ou assume um grande projeto - às vezes até pedindo esse projeto, na expectativa de que trabalhar mais em algo maior trará promoções. Nesse momento, a pessoa se obriga a "cosplay" de um engenheiro mais sênior do que é, tentando desenhar algo muito mais ambicioso.

O primeiro sintoma é o desaparecimento: por duas ou três semanas, não se ouve falar dela. Nas reuniões diárias, ela dá o que Pai chama de "positive update" - diz que as coisas vão bem, que em breve terá algo para mostrar, e que bastam perguntas. Ninguém pergunta, e nada aparece.

A espiral interna

Na cabeça da pessoa, o ciclo já começou: "não envio nada há um tempo, preciso trabalhar mais, vou compensar isso na próxima semana e ninguém vai notar". Ela perde sono, começa a ficar deprimida, pula refeições, e os relacionamentos - de trabalho e pessoais - sofrem. Os desfechos piores, segundo Pai, incluem burnout com um mês de afastamento, PIP (plano de melhoria de desempenho), demissão ou pedido de demissão por acreditar que "não há mais salvação".

Pai enfatiza que não se trata de um padrão visto apenas nos outros: ele mesmo passou por isso tantas vezes que hoje reconhece os sinais cedo o bastante para corrigir o rumo.

Por que agora é pior

Ele situa o problema em mudanças dos últimos cinco a dez anos: pandemia, agentes de código e trabalho remoto. Sem a estrutura de sentar ao lado de alguém e receber tarefas de Jira, o engenheiro tem mais autonomia - e acaba mais isolado. O risco é chegar ao ponto de colegas dizerem "não sei o que o Sunil anda fazendo" e começarem a se preocupar, porque o alerta pode vir tarde demais. A alternativa que ele propõe é ser alguém que não para de falar do que está trabalhando - sem precisar ser incômodo, mas compartilhando o trabalho.

A saída contraintuitiva: voltar um nível

A recomendação central parte de supor boa-fé em todos ao redor: a empresa contratou a pessoa como ela é hoje, não como ela imagina que será em seis meses. A partir daí, o conselho é "cair um nível": em vez de tentar parecer mais sênior, tornar-se, por um tempo, o melhor colega de equipe possível. Continua responsável pelo próprio trabalho, mas foca em destravar o movimento: corrigir bugs, pegar tarefas chatas na mesa de outra pessoa, trabalho braçal, organização, escrever documentos - coisas que ajudam o time.

O objetivo, explica Pai, é trocar uma mentalidade baseada em resultados por uma baseada em momento (momentum). Momento e relacionamentos são o que sustentam a recuperação; deles vem a resistência para manter o ritmo. A lição que ele extrai: grandes projetos não são feitos com grandes esforços pontuais, mas como uma maratona de trabalho lento, constante e incremental - em escala diária, quase horária, até virar memória muscular. Trinta dias depois, olhando para trás, o volume acumulado aparece.

Conclusão: reputação antes de software

Ao construir momento e consertar relacionamentos, o engenheiro busca confiabilidade e alivia o peso sobre colegas e gestor. É essa confiança construída que, depois, faz o time entregar trabalhos maiores. A frase final resume a tese: você está no negócio de construir reputação, e o software é consequência disso.