Em muitos times de engenharia no Brasil, a promoção ainda é decidida por tempo de casa, simpatia e visibilidade em reunião. O resultado aparece depois: pessoas promovidas a sênior que não conseguem assumir decisões ambíguas, e engenheiros competentes que pedem demissão porque a única forma de crescer era virar gestor ou trocar de empresa.

Avaliar senioridade de verdade exige critérios escritos e evidências coletadas na rotina, não em uma conversa de fim de ano. É disso que trata este texto: como estruturar a progressão técnica em times que mantêm software em produção.

Senioridade se mede por responsabilidade, não por volume de código

O primeiro erro é confundir volume de entrega com nível. Um desenvolvedor pleno entrega bem tarefas bem definidas. Um sênior define o problema antes de codificar, decide com informação incompleta, antecipa o custo de manutenção e assume as consequências quando erra. São níveis de responsabilidade diferentes, não de velocidade.

Isso muda o que a avaliação precisa observar. Em vez de contar pull requests, olhe para o escopo das decisões que a pessoa toma sem supervisão e para o que acontece quando o sistema quebra. Quem sustenta produção desenvolve um tipo de julgamento que não aparece em tarefa fechada: priorizar o que corrigir primeiro, negociar prazo com a área de negócio, saber a hora de parar de investigar e mitigar o impacto.

Como transformar a prática diária em evidência

Critério sem evidência vira opinião. A saída é definir, para cada nível, comportamentos observáveis e registrar o que acontece ao longo do ciclo. Sinais que servem como evidência:

  • Condução de incidentes: quem lidera o diagnóstico, escreve o postmortem e evita que o mesmo erro volte.
  • Revisão de código: qualidade do comentário, capacidade de explicar o porquê e disposição para ser revisado.
  • Decisões registradas: documentos curtos com alternativas, trade-offs e o que se espera dali para frente.
  • Impacto fora do próprio time: contratos de API, integrações e documentação que outros usam sem precisar perguntar.
  • Mentoria verificável: quantas pessoas dependem menos dessa pessoa hoje do que dependiam no ano passado.
  • Custo de manutenção: o sistema ficou mais barato ou mais caro de evoluir depois dessa entrega.

Exemplo concreto: uma distribuidora de médio porte promovia por tempo de casa e tinha uma única pessoa capaz de operar a integração de faturamento. Quando ela saiu, o fechamento do mês seguinte virou uma corrida manual, com a equipe lendo logs para descobrir o que o sistema fazia. O problema não era a saída, era a ausência de critérios que tivessem forçado a distribuição desse conhecimento antes.

Trilha técnica e trilha de gestão: mesma régua, remuneração comparável

Se a única forma de ganhar mais é virar gestor, você vai perder seus melhores engenheiros ou promover quem não quer gerenciar pessoas. A trilha dupla resolve isso: dois caminhos paralelos, com escopos e faixas salariais equivalentes no mesmo patamar de senioridade. O sênior técnico e o gestor de time podem ocupar o mesmo nível de carreira, com responsabilidades diferentes.

Na prática, isso exige definir o que se espera em cada trilha. A técnica pesa decisão de arquitetura, sustentação em produção, mentoria e redução de risco operacional. A de gestão pesa desenvolvimento de pessoas, priorização, negociação com o negócio e saúde do time. Ninguém precisa ser promovido para fora do que faz bem.

Na prática

Para quem mantém software em produção, a progressão técnica precisa entrar na rotina, não na exceção:

  1. Escreva as expectativas de cada nível em comportamentos observáveis. "Ser proativo" não serve como critério; "assume a investigação de incidentes do domínio que conhece" serve.
  2. Colete evidências durante o ciclo. Anote quem liderou incidentes, quem registrou decisões e quem formou outras pessoas. Avaliação sem registro vira memória recente.
  3. Proteja tempo para manutenção e documentação. Se dívida técnica só se resolve fora do horário, a empresa está dizendo que isso não conta para carreira.
  4. Rotacione responsabilidades críticas. Plantão, acesso a produção e conhecimento de integrações devem circular. Dependência de uma pessoa é risco operacional e trava de carreira.
  5. Trate mentoria como trabalho. Ensinar alguém a sustentar um sistema é entrega, não favor.

No fim, avaliar senioridade é avaliar o que a pessoa deixa sustentável atrás de si. Times que fazem isso com critério promovem sem apagar incêndio e mantêm engenheiros que, de outro modo, sairiam para crescer em outro lugar.