Um time de oito engenheiros contratou, por indicação do CTO, um sênior descrito como capaz de produzir por cinco. A descrição era precisa em uma dimensão: nos três primeiros meses, ele entregou, sozinho, mais features do que qualquer outro membro do time. A dimensão que a descrição omitia era o efeito do seu comportamento sobre os outros sete. Pull requests passaram a demorar mais porque o código dele era difícil de revisar e ele resistia a sugestões. Dois engenheiros pararam de propor designs em reuniões porque eram sistematicamente rebatidos com tom áspero. O onboarding de uma contratação do quarto mês travou porque ninguém queria explicar convenções que o novo sênior publicamente desprezava. No fim do segundo trimestre, enquanto o throughput individual dele continuava alto, o throughput do time tinha caído a ponto de duas pessoas já estarem em processo seletivo externo.
Pra mim, a figura do 10x engineer, como categoria de avaliação, descreve throughput individual medido em isolamento. O número original vem de um estudo publicado em 1968 por Sackman, Erikson e Grant, com amostra pequena e condições experimentais atípicas, e foi generalizado em décadas seguintes até virar vocabulário comum em decisões de contratação. A generalização sobrevive porque é conveniente: permite justificar salários desproporcionais, promoções rápidas e tolerância a comportamentos que, em outros contextos, seriam tratados como problema. O custo dessa conveniência aparece no atrito que o 10x produz em volta, e esse atrito raramente entra na conta de quem decidiu contratá-lo.
O trabalho de engenharia em organização média não é soma de contribuições individuais. É rede de dependências entre código e pessoas, e o throughput agregado depende da fluidez dessa rede. Um engenheiro que produz o dobro da média mas consome o tempo de três revisores e bloqueia decisões coletivas por insistência em padrões próprios, deixando código sem contexto compartilhável, opera como gargalo disfarçado de produtividade. A organização percebe, com atraso, que a saída do time estagnou apesar do esforço crescer, e que a pessoa identificada como motor é a mesma que está degradando a capacidade dos demais.
O multiplicador de time opera numa lógica diferente. A contribuição dele é menos visível em métricas individuais porque parte do seu trabalho é transferir contexto e desbloquear decisões paradas, tornando os pares mais capazes a cada ciclo. Um engenheiro que dedica uma hora por dia a pair programming, revisões substantivas e documentação leve de decisão entrega, nessa hora, menos código do que entregaria implementando sozinho, mas produz aumento marginal de velocidade em cinco ou seis pessoas em paralelo, e o efeito composto supera a contribuição individual em poucos ciclos. A métrica individual do multiplicador é medíocre quando comparada à do 10x; a métrica agregada do time com um multiplicador tende a ser superior, uma vez que o horizonte ultrapasse um ou dois trimestres.
A dificuldade prática é que sistemas de avaliação de desempenho e decisões de contratação são desenhados pra medir o que é fácil de observar no indivíduo, e o trabalho de multiplicação é, por natureza, distribuído entre os outros. A organização vê as entregas do 10x, atribui a ele e recompensa. Vê as entregas do time que convive com o multiplicador, atribui ao time e não sabe bem a quem recompensar. O viés de atribuição é estrutural e, depois de alguns ciclos, produz times nos quais o multiplicador some da calibração ou pede demissão, enquanto o 10x acumula capital político desproporcional à sua contribuição líquida. O relatório DORA de 2024 reforça o padrão: apesar do ganho individual com uso de IA, a pesquisa registrou queda de cerca de 1,5% em delivery throughput no agregado, mostrando que ganho individual não se traduz automaticamente em ganho organizacional.
Os trade-offs de priorizar multiplicadores são reais. Time composto majoritariamente por multiplicadores pode ter dificuldade em tarefa que exige imersão solitária prolongada, e pode operar abaixo do potencial se faltarem executores consistentes pra absorver o trabalho braçal. Faltar engenheiro com throughput individual alto é tão disfuncional quanto ter um 10x tóxico, e a composição que funciona depende do tipo de problema que o time enfrenta. Na minha avaliação, o erro organizacional recorrente é tratar throughput individual como proxy suficiente de contribuição, deixando de medir o efeito líquido de cada engenheiro sobre a capacidade dos demais.
Acompanhei recentemente uma engenharia de cerca de sessenta pessoas que passou a incluir, na avaliação de desempenho, uma pergunta dirigida aos pares próximos: em que medida a presença dessa pessoa tornou o seu trabalho mais fácil no último ciclo. A pergunta não substituiu a métrica individual, mas gerou um sinal paralelo que expôs descasamentos nítidos entre throughput e contribuição. Dois engenheiros tidos como top performers caíram na calibração com o sinal dos pares incorporado, e três historicamente subavaliados subiram. Seis meses depois, o efeito agregado foi redução visível de fricção em revisões e queda mensurável no tempo médio de onboarding, sem contratação nova.
A escolha entre caçar 10x engineers e cultivar multiplicadores não é preferência de estilo. É escolha sobre o que a organização aceita medir e, em consequência, o que passa a produzir. Enquanto o throughput individual for o sinal dominante, o individualismo será recompensado e a multiplicação tratada como subproduto opcional. Quando o efeito líquido sobre os pares entra na avaliação com peso compatível, o sistema passa a reter quem contribui em composição, e é essa composição que sustenta engenharia em escala.