A promoção que resolve o problema errado

Em boa parte das empresas brasileiras, o engenheiro mais experiente vira coordenador porque é a única forma de reconhecer sua senioridade e ajustar o salário. A intenção é legítima. O efeito colateral também é conhecido: quem revisava as mudanças mais delicadas, quem lembrava por que a integração com o ERP foi feita daquele jeito, passa a ocupar a agenda com orçamento, aprovação de férias e reunião de diretoria. A empresa ganha um gerente em formação e perde, por alguns meses, sua principal referência técnica. Ninguém decidiu isso em ata. Foi consequência de uma estrutura de carreira com uma escada só.

Duas trilhas com responsabilidades diferentes

A trilha técnica mede senioridade por amplitude de decisão: diagnosticar incidente em produção, revisar código com critério, definir padrões, orientar gente menos experiente, reconhecer dívida técnica antes que ela vire custo. A trilha de gestão mede outra coisa: priorização, orçamento, contratação, negociação com as áreas de negócio, desenvolvimento do time. As duas exigem comunicação. Muda o objeto.

  • Na trilha técnica, o resultado aparece na sustentabilidade do que fica em produção e na velocidade com que o time resolve problemas difíceis.
  • Na trilha de gestão, o resultado aparece na previsibilidade de entrega e na capacidade de manter o time inteiro produtivo.
  • Nenhuma das duas deveria ser o prêmio da outra.
  • Um engenheiro sênior que não quer gerenciar pessoas não é alguém sem ambição: é alguém que escolheu aprofundar um tipo de competência.

O exemplo da distribuidora

Uma distribuidora de autopeças com operação em três estados tinha no coordenador de TI a única pessoa que entendia as regras embutidas no sistema de faturamento: a tabela de desconto por cliente, a regra de bonificação por volume, o fechamento que rodava no último dia útil. Ele conhecia o código e o negócio. Quando foi promovido a gerente, o módulo ficou sem dono técnico. As decisões passaram a ser tomadas por um desenvolvedor recém-contratado, competente, mas sem o contexto de dez anos de exceções negociadas comercialmente.

O resultado não foi um desastre, foi algo mais silencioso: cada mudança naquele módulo passou a custar dias de investigação em histórico de chamados e conversas informais. O próprio gerente voltou a programar nas horas vagas, acumulando duas funções, porque era mais rápido resolver do que explicar. A empresa pagou duas vezes, pela promoção e pela ausência de sucessão.

Duas medidas simples teriam evitado o cenário: um papel formal de liderança técnica responsável pelo módulo, com autoridade para vetar mudanças de risco, e o registro das regras de negócio em um lugar onde o time pudesse consultar sem depender de memória. Nenhuma das duas é compra de ferramenta. É organização de carreira.

Na prática

Para quem mantém software rodando todos os dias, a discussão de trilha se traduz em decisões pequenas e recorrentes:

  • Escreva o que separa pleno de sênior na sua empresa. Se o critério for “resolve tudo sozinho”, você está premiando a concentração de conhecimento.
  • Mantenha um mapa de conhecimento crítico: para cada módulo em produção, quem sabe e quem mais poderia assumir. Onde houver um nome só, há um risco.
  • Quem entra na trilha de gestão deve sair da fila de revisão de código de forma planejada, não abrupta. Defina quem herda as revisões antes da promoção.
  • Liderança técnica precisa de tempo protegido na agenda. Se o papel existir apenas no organograma, a revisão volta a ser feita de madrugada.
  • Avalie gerentes também pela saúde do sistema e do time, não apenas pelo cumprimento de prazo.
  • Rotacione tarefas entre pessoas do time em módulos críticos. Sucessão se constrói em dia comum, não em emergência.

A pergunta que fecha a discussão é simples: se a pessoa mais experiente do seu time sair de férias por um mês, o que para de acontecer? A resposta indica onde a carreira e a operação ainda estão amarradas na mesma pessoa.