Em louvor aos engenheiros "comuns"

• O “engenheiro 10x” parece plausível intuitivamente, mas é muito difícil medir produtividade de forma objetiva, e também é uma abordagem equivocada tratá-la como uma característica pessoal imutável
• A propriedade real e os resultados do software são determinados pela colaboração e pela capacidade da equipe de engenharia
• Organizações realmente excelentes não são aquelas com apenas pessoas excepcionalmente brilhantes, mas as que criam um ambiente em que engenheiros comuns entregam bons resultados de forma consistente
• Os sistemas devem ser projetados considerando que pessoas comuns podem errar ou se cansar, e o foco deve estar em criar uma “equipe 10x”
  • O design de sistemas de software e a cultura devem se basear nas características, na diversidade e no potencial de crescimento de “pessoas comuns”
• No fim, o principal indicador de produtividade é o impacto no negócio, e o importante é contratar e montar times com as pessoas certas, não com “os melhores talentos”

---

Em louvor aos “engenheiros comuns”

• Este texto critica o conceito de “engenheiro 10x” e explica a importância de organizações em que engenheiros comuns conseguem gerar um desempenho de equipe excepcional

O mito do “engenheiro 10x” e seus limites

• Todo mundo já encontrou na carreira algum engenheiro extraordinário que parecia quase um mago
• Disso surgiu o conceito de “engenheiro 10x”, mas ele tem base frágil e também reforça preconceitos
• É quase impossível definir uma métrica única de produtividade
  • Há infinitas combinações de variáveis, como stack tecnológica, domínio, estágio de desenvolvimento, contexto de mercado e experiência
  • Uma pessoa pode ser um engenheiro 10x em uma área específica, mas ser comum ou até abaixo da média na maior parte das outras
• Alguém que já foi um excelente DBRE pode, com o tempo, se tornar apenas mediano nessa área
• No fim, ninguém consegue ser 10 vezes melhor em todas as áreas, o tempo todo

Propriedade de software centrada no time

• Software é algo que equipes possuem e administram, não indivíduos
• Entrega, manutenção, melhoria, expansão e refatoração de software: tudo isso acontece em nível de equipe
• Um sistema que pertence a uma única pessoa vira um ponto único de falha (SPOF) quando ela sai de férias, muda de emprego ou se ausenta, tornando-se uma vulnerabilidade para a organização
• Em startups, a propriedade individual pode ser inevitável no começo, mas, conforme a organização cresce, ela precisa ser convertida em propriedade de equipe
• A principal missão de líderes de engenharia deve ser formar times de alta performance; mais importante do que um “engenheiro 10x” é criar um time 10x

As condições de uma organização realmente de alto desempenho

• Muitas empresas preferem montar equipes com gente vinda de FAANG, universidades de elite ou focadas em Staff Engineer
• Mas uma organização realmente boa é aquela em que engenheiros comuns conseguem gerar impacto real com estabilidade
• Em vez de uma organização em que só os “melhores” conseguem entregar resultado, a maior vantagem competitiva está em criar um sistema em que desenvolvedores comuns também cresçam com autonomia e impactem positivamente o produto e o negócio
• Paradoxalmente, esse tipo de organização forma mais engenheiros de classe mundial

Redefinindo o significado de “comum”

• A indústria de software está cheia de uma mentalidade elitista, com ideias como “top 10%” e “top .1%”
• Mas é importante reconhecer que a maioria dos engenheiros são pessoas comuns que cresceram por meio de experiências diversas e prática
• Ninguém nasce sendo um “engenheiro brilhante”
• Grandes engenheiros são formados — qualquer pessoa pode se tornar excelente por meio de aprendizado e experiência

Projetando sistemas para pessoas comuns

• Na contratação, faz sentido observar forças excepcionais, mas, ao projetar sistemas, é preciso considerar a realidade de que as pessoas comuns erram, se cansam e se apoiam no que lhes é familiar
• Engenheiros comuns são afetados por vieses cognitivos, fadiga e oscilações emocionais
• Quando o sistema é projetado não para uma minoria genial, mas do ponto de vista de engenheiros comuns, o talento criativo das pessoas mais brilhantes pode se concentrar no próprio produto

Como criar um “time 10x”

• Reduzir ao máximo o intervalo entre escrever código e colocá-lo em produção
  • Ciclos rápidos de deploy reduzem a carga cognitiva e permitem experimentação e feedback mais rápidos
  • Quanto mais lento o deploy, mais mudanças se acumulam de uma vez, tornando mais difícil rastrear problemas e fazer rollback
• Tornar fácil a recuperação de erros e o rollback
  • Desenvolvedores devem conseguir implantar código por conta própria e, se encontrarem um problema, restaurar rapidamente
• Tornar o comportamento certo fácil e o comportamento errado difícil
  • Trabalhar com designers e engenheiros de plataforma para construir guardrails e sistemas de self-service
• Investir ativamente em observabilidade e ferramentas de instrumentação
  • Visualizar como o código realmente se comporta para que todos os engenheiros consigam entender e depurar o sistema com facilidade
• Investir recursos de engenharia em ferramentas internas e aumento de produtividade
  • Esses sistemas exigem ownership dedicado e precisam ser uma prioridade em toda a empresa
• Criar uma cultura inclusiva
  • Um ambiente em que qualquer pessoa possa perguntar, errar e explorar
  • Equipes com diferentes origens, habilidades e níveis de experiência são mais resilientes e mais fortes diante de mudanças
• Montar equipes com engenheiros de todos os níveis
  • De júnior a sênior, todos aprendem, ensinam e crescem juntos
  • Esses sistemas também podem ser reaproveitados para onboarding de novos membros e movimentações entre equipes

A verdadeira métrica de produtividade: "impacto no negócio"

• Em última instância, a métrica de produtividade em engenharia de software é o impacto no negócio
• A essência não está em escrever muito código, mas em resolver problemas e criar valor
• Na prática, quem move a indústria não são engenheiros Staff+, mas engenheiros sênior e de nível pleno
  • São eles que formam a base das organizações e fazem o negócio avançar continuamente
  • Se só pessoas de nível Staff+ conseguem gerar impacto, isso é um sinal de que há um problema na organização

Organizações que formam engenheiros de classe mundial

• Uma organização realmente boa é aquela em que qualquer pessoa consegue gerar impacto, mesmo sem já ser um engenheiro excepcional
• As melhores organizações não precisam necessariamente contratar separadamente os melhores talentos do mundo; nelas, engenheiros de classe mundial surgem naturalmente em maior número
• Talentos se reúnem em lugares onde engenheiros podem se concentrar em resolver problemas, crescer e gerar impacto, e a própria experiência de “trabalhar feliz e evoluir” alimenta um ciclo virtuoso
• Líderes não devem depender da capacidade individual de pessoas brilhantes, mas conectar isso ao crescimento de toda a organização e ao valor entregue ao cliente

Contratar “a pessoa certa”, não “o melhor talento”

• A indústria vive procurando “os melhores”, mas o que realmente importa é o sistema e o ambiente
• Mais do que “o melhor talento”, a verdadeira vantagem competitiva está em encontrar a pessoa certa para o time e para a organização
• Em vez de montar times com pessoas sem pontos fracos, é mais eficiente compor a equipe com talentos adequados que tenham forças próprias e ampliem a diversidade e a harmonia da organização
• Equipes inclusivas e diversas geram, na prática, desempenho, crescimento e sucesso de longo prazo
• Lugares em que todos gostam do trabalho, crescem e entregam resultados significativos são as verdadeiras organizações de classe mundial, e é numa cultura em que se pode aprender com falhas e erros que tanto engenheiros quanto organizações evoluem
• São justamente essas organizações que atraem a próxima geração de engenheiros e também fazem com que talentos já excelentes queiram permanecer

[GN⁺]

Comentários do Hacker News

• Concordo com a ideia de que a equipe de engenharia é a menor unidade de propriedade e entrega de software, mas ainda assim isso me deixa um pouco insatisfeito. Essa estrutura se conecta a uma cultura em que engenheiros viram cidadãos de segunda classe em comparação com gerentes ou com a área de produto. Temos responsabilidade apenas pela entrega, mas não podemos tomar decisões realmente significativas de forma independente além de um escopo muito pequeno da equipe. Nas melhores equipes, o horizonte de autonomia chega a meses, ou até anos, mas na maioria das equipes ele encolhe para dias ou semanas. Na prática, porém, é perfeitamente possível que engenheiros tenham propriedade real e que a estrutura dure por muito tempo sem que o sistema quebre ou fique arriscado. O segredo é garantir folga (slack), incentivar trabalho de qualidade e dar liberdade suficiente para que qualquer integrante possa mudar de função com flexibilidade. Com cada um tendo propriedade e tomando decisões de longo prazo, mas também colaborando ad hoc e compartilhando conhecimento tácito, fica natural o cenário em que alguém entra de repente para ajudar ou até assume completamente o trabalho. Pela minha experiência, essas equipes fazem mais reescritas do que as equipes comuns, mas no geral são muito mais produtivas. Reescrever o sistema gradualmente em pequenos blocos é muito eficaz tanto para a evolução do design quanto para o acúmulo de conhecimento e capacidade dentro da organização. Por fora pode parecer desperdício, mas é uma folga essencial para tornar a organização inteira mais flexível e resiliente. Na verdade, tenho cada vez mais convicção de que muitos processos top-down que tentam reduzir o chamado desperdício acabam eliminando uma slack importante

  • Pessoas de fora da engenharia muitas vezes não conseguem avaliar imediatamente as decisões de longo prazo tomadas pelos engenheiros, nem sabem como recompensá-las. Isso vale até mesmo fora da própria equipe de engenharia. Elas não têm capacidade de avaliar diretamente se um trabalho de longo prazo com valor interno realmente tem valor ou não. Se você confia na sua capacidade de tomar decisões de longo prazo e usar bem o tempo de folga, então não tem problema ser recompensado pela entrega (delivery). Em algum momento, esse trabalho de longo prazo vai voltar em forma de resultados melhores

  • Acho que reescritas de software têm um papel importante no processo de desenvolvimento. O verdadeiro “agile” é criar protótipos rapidamente sem se preocupar demais com a primeira arquitetura, respondendo com flexibilidade às mudanças de requisitos. Programar é parecido com escrever: mesmo que o primeiro rascunho seja bruto, é muito mais eficiente simplesmente ir escrevendo e melhorar na segunda versão. O objetivo do primeiro rascunho não é ser bom, mas criar algo rapidamente, explorar o domínio do problema e descobrir os edge cases. Esse jeito de trabalhar não costuma convencer a gerência. No momento em que você mostra um protótipo funcionando, a reação é “vamos lançar isso agora”, sem te dar tempo para reescrever. Uma solução seria achatar a hierarquia da organização e devolver de fato a propriedade do código aos engenheiros. É desejável uma estrutura em que engenheiros e product owners tomem decisões juntos de forma democrática

  • Eu também já valorizei muito a “propriedade individual” e ainda acho que engenheiros podem ter propriedade, mas reconheço que na prática muitos engenheiros não querem isso. A maioria aceita bem a propriedade no nível da equipe, mas não se interessa tanto por propriedade no nível do indivíduo. É só o trabalho deles. Se isso for deixado para cada pessoa, tende a gerar desconfiança dentro da equipe ou a excluir membros sem perfil de liderança, e no fim é fácil cair numa situação em que ninguém tem autonomia real. Dar propriedade e autonomia no nível da equipe é muito mais simples e eficaz. É também uma dinâmica possibilitada pela existência de um líder de equipe ou gerente. Colocar a propriedade do software em indivíduos cria risco demais de fracasso por causa de mudanças de pessoal, estabilidade, carreira e outras variáveis. Por mais saudável que a organização seja, sempre haverá problemas grandes e pequenos, e nessa estrutura o caminho até a falha fica mais curto. Pensando numa caixa de câmbio, fica fácil entender: se há só uma engrenagem e ela quebra, você para; se há várias engrenagens, mesmo que seja desconfortável, você continua andando mesmo que uma quebre na hora

  • Acho que uma propriedade individual realmente substancial é possível. Na verdade, vejo isso como a única forma de ser realmente “produtivo”. Mas esse não é o ponto essencial. Indivíduos são insubstituíveis, mas membros de equipe são até certo ponto substituíveis dependendo da estrutura. Quanto maior a organização, mais ela quer previsibilidade no nível do time, e para isso precisa garantir substituibilidade dos membros, ou seja, redundância. Na engenharia também se usa redundância pela confiabilidade (resiliência), e eficiência é basicamente o trade-off de reduzir essa redundância

  • Trabalhamos em estruturas nas quais temos responsabilidade apenas pela “entrega”, e a tal propriedade só aumentava a carga, sem qualquer recompensa real. O trabalho acaba se limitando a pendurar funcionalidades na página. Se houver responsabilidade adicional, a compensação adicional também é justa. Gerentes e executivos são recompensados conforme o número de pessoas sob sua responsabilidade; com desenvolvedores deveria ser igual

• Tenho convicção de que as melhores equipes são as que têm uma cultura que permite que engenheiros comuns entreguem resultados extraordinários. Mais do que a chamada “qualidade de engenharia” ou o recrutamento de talentos, cultura, confiança, sistemas e processos são muito mais importantes. Existe esse discurso de que “qualquer um pode montar uma organização com os melhores engenheiros”, mas na prática são pouquíssimas as organizações que realmente criaram equipes assim. Quase todas são empresas de trading ou organizações especiais/de pesquisa. Fico me perguntando por que quase ninguém consegue. No fim, o próprio conceito de “produtividade” é nebuloso. Existem até sistemas de avaliação que na prática medem a capacidade de suportar e atravessar as disfunções da organização, mas não acho que isso seja o verdadeiro significado de ser um “engenheiro de ponta”

  • A oferta de engenheiros realmente excepcionais é limitada, então no fim as empresas maiores acabam levando esse mesmo talento oferecendo trabalho mais interessante ou salários mais altos

  • Além da questão do dinheiro, que outras pessoas já mencionaram, o “tempo” também pesa muito. As empresas não têm folga para esperar até aparecer o talento “unicórnio” perfeito e acabam tendo de contratar com urgência quem está disponível agora. Em algumas empresas, especialmente em áreas como finanças quantitativas, um único superengenheiro que reúna programação de sistemas, matemática e conhecimento de mercados financeiros pode gerar muito mais valor do que uma equipe com três especialistas separados. Mas encontrar alguém assim leva tempo demais. Mesmo olhando só para desenvolvimento web, são raríssimos os desenvolvedores “full stack de verdade” que entendem de tudo, de protocolos de rede a administração de sistemas, sistemas distribuídos, bancos de dados e frontend. Só organizações com tempo e dinheiro suficientes conseguem reunir esse tipo de talento e construir o melhor produto possível. Claro, se o produto realmente precisa desse nível de qualidade já é outra pergunta

  • No fundo, a oferta global dos “melhores engenheiros” é extremamente limitada. Se você pode pagar salários no top 10% e ainda atrair e reter pessoas desse nível, ótimo. Na verdade, não é algo que “qualquer um” consiga fazer; é preciso uma liderança capaz de desenhar um sistema sociotécnico focado em aprendizado e crescimento por parte da gestão. Isso por si só já é um grande feito

  • O maior problema é que a maioria dos executivos de primeira e segunda linha não é tão boa assim. Falta capacidade de criar e manter ambientes produtivos. A solução fundamental acaba sendo pagar muito dinheiro. Quando a remuneração é alta, a maioria das condições difíceis se torna tolerável

  • Independentemente da questão de orçamento, um engenheiro realmente brilhante pode até não ser bom para trabalho em equipe. Uma mente excepcional às vezes pode atrapalhar compromissos necessários ou tarefas chatas, mas indispensáveis

• Não concordo muito com a ideia de que “impacto de negócio é a única métrica de produtividade”. Essa visão desloca o foco para mudanças mensuráveis e resultados de curto prazo, e faz perder o verdadeiro valor dos engenheiros experientes. A verdadeira habilidade está em evitar de antemão os riscos (landmines) que quase fariam um projeto ou uma empresa fracassar. Mas esse tipo de “risco eliminado” é difícil de medir e quase impossível de comunicar sem soar banal

  • “Impacto” não precisa ser necessariamente uma perspectiva de curto prazo. As pessoas que causam o maior impacto na organização agem com visão de longo prazo

  • Eu falo de “produtividade” ou “impacto” de propósito como expressões vagas. Algo como “pensando no conjunto, X fez um trabalho realmente excelente”. Isso é difícil de quantificar e de definir com precisão, mas em organizações complexas e criativas o insight e o julgamento humano são naturalmente mais importantes. Tentar transformar gestão em algo totalmente quantificável é, no fundo, míope

  • Não concordo em medir o valor de um engenheiro apenas por gestão de projeto ou prevenção de risco, mas também me incomoda reduzir tudo a “impacto de negócio”. Há muitas coisas significativas para indivíduos, para a humanidade e para o mundo que não têm relação com dinheiro. Os engenheiros que mais respeito não são as figuras mitológicas do Vale do Silício pós-2001, mas John von Neumann, Robert Oppenheimer, Nikola Tesla, Leonardo da Vinci, alguém que construiu os aquedutos romanos e as pirâmides egípcias, astrônomos da Babilônia e da Mesoamérica, entre outros. Eles deixaram impacto de negócio? Mesmo que Tesla tenha gerado lucro para a Westinghouse em algum momento, isso não explica sua realização. Na verdade, em termos de negócios ele foi bastante comum. O mesmo vale para gigantes da indústria de computação recente. Parte do enorme sucesso da Nvidia ou de Geoff Hinton também teve a ver com a “sorte” de a internet ter se transformado em um meio publicitário e os dados terem explodido. Há muitos casos de gente realmente brilhante que desapareceu sem reconhecimento. Até alguém como Doug Lenat, um grande nome da IA, acabou não sendo revelado pela corrente da história. O sucesso ou fracasso muitas vezes independe do esforço individual

  • Ou você constrói um sistema eficiente, ou constrói um sistema que minimiza a possibilidade de desastre. É difícil até provar qual desastre foi evitado na prática, e como o impacto negativo é um “evento que não aconteceu”, também é difícil mostrá-lo como resultado

  • As empresas deveriam se esforçar para quantificar melhor, de alguma forma, o risco do “desconhecido”

• Tive a sorte de trabalhar até hoje em várias equipes excelentes e atualmente também lidero uma. Ao contrário do que o artigo sugere, quanto melhores essas equipes são, mais difícil costuma ser administrá-las como organização. Organizações grandes focam tanto em padronização que engenheiros excelentes muitas vezes não conseguem mostrar suas capacidades e acabam perdendo motivação. Não concordo com a visão pessimista de que não dá para formar todo mundo como ótimo engenheiro. Na prática, com investimento consistente, é possível formar excelentes engenheiros, e acredito que no longo prazo os ganhos de ter um grupo muito maior de pessoas talentosas superam com folga o custo desse investimento

• O fato de algo não poder ser medido de forma eficaz não significa que esse algo não exista. Produtividade individual, isto é, desempenho individual no trabalho, claramente existe. Talvez só seja mais fácil medir a produtividade em nível de grupo. “Impacto de negócio” é, na verdade, muito mais arbitrário, e com esse tipo de métrica fica difícil reter pessoas realmente produtivas. Avaliar conhecimento especializado é muito difícil sem experiência equivalente; você pode até dar conselhos, mas é outra questão saber se a outra parte tem abertura intelectual para aceitá-los. Como saber se sou um gênio ou apenas alguém excessivamente confiante?

  • O problema não é que não se possa “medir” produtividade, mas que nem mesmo se consegue “defini-la” de forma abstrata. Mesmo que você meça o quanto alguém contribuiu além de um “replacement”, isso não explica exatamente como esse resultado foi produzido. Na prática, o impacto individual é determinado pelo contexto e pela organização como um todo. Mesmo se você tentar dar uma definição mais direta, a resposta varia enormemente conforme a organização e a situação. Vale muito a pena refletir sobre isso, mas também é questionável se o próprio critério de engenheiro “Top 1%” realmente faz sentido

  • Um verdadeiro gênio consegue explicar seus resultados com clareza e etiqueta. Por isso, acho que a diferença é distinguível sim

• Gosto muito da frase “a melhor organização é aquela que permite que engenheiros normais façam um trabalho grandioso”. Nem todo integrante da equipe precisa ser uma superstar. O que realmente importa é quão bem a organização dá suporte para que um desenvolvedor mediano consiga entregar um trabalho suficientemente bom e confiável

  • Todo grande engenheiro também começou sendo apenas um bom engenheiro. Uma organização saudável ajuda seus membros a seguir esse caminho de crescimento

• O princípio de “tornar o certo fácil e o errado difícil” é igual ao slogan central de todas as equipes de plataforma que já conheci. O objetivo é projetar sistemas em que a “resposta certa” para os problemas enfrentados pelos engenheiros apareça naturalmente e seja fácil de implementar. Se você oferece confiabilidade e facilidade de gestão e, de forma natural, desenvolve esse “músculo” de engenharia nessa direção, a organização inteira se beneficia. Essa verdade continuará válida no futuro

  • Por coincidência, Charity Majors escreveu um excelente ensaio sobre isso. A ideia é começar formando um pequeno comitê de engenheiros seniores confiáveis para montar uma lista recomendada de componentes-base para novos serviços. Isso vira justamente o “golden path”. A organização dá suporte total apenas aos componentes do golden path e prepara como ouro toda a infraestrutura de upgrades, patches, backups, deploy, ambientes, on-call etc. Não é obrigatório usar, mas escolhas fora do golden path significam que você assume tudo por conta própria

• Sempre tive a sensação, toda vez que aparecem linguagens e frameworks como golang, python, COBOL, lisp, perl, React e brainfuck, de que existe uma tendência a confundir React com todo o ecossistema de frontend. Na realidade, existe um mundo de frontend muito diverso além de React, mas parece que muita gente acha que React é tudo

• Na nossa empresa, sempre preferimos contratar engenheiros medianos com boa atitude. Pessoas com ótimas credenciais, mas atitude ruim, costumam ser boas em construir reputação e rapidamente ganham a confiança da liderança; depois disso, tornam-se intocáveis. Quando uma pessoa assim se estabelece, quem está em volta pode até se indignar, mas fica difícil levantar o problema. A liderança também tende a ignorar facilmente dados que contradizem sua percepção. É muito mais fácil se apoiar na percepção do que em dados objetivos

• Concordo muito com a afirmação de que “qualquer um pode montar uma organização com os melhores engenheiros, e o foco na capacidade individual obscurece o verdadeiro papel da liderança. Construir sistemas que permitam que engenheiros menos experientes apliquem sua capacidade e gerem resultados é uma vantagem competitiva enorme”. Eu não sou um engenheiro 10x, mas olhando para minhas experiências recentes, quando há muita gente com pouca experiência ou habilidade no time, eu acabava ficando sozinho com os tickets mais complexos. Quando esse padrão se repete, eu passo a fazer a maior parte do trabalho sozinho, e esse papel de fato é desgastante e parece injusto. Sinceramente, acho que um bom SRE precisa até ter uma leve tendência à preguiça, então eu queria muito que a equipe dividisse mais esse trabalho. Por isso, trabalhei pesado por algumas semanas e introduzi várias abstrações nas partes mais complexas (eu lido principalmente com IaC; em software o padrão é parecido). A partir daí, engenheiros com menos habilidade ou experiência passaram a conseguir assumir parte do meu papel, e meu tempo ficou livre para problemas mais interessantes. Foi a primeira vez que fiz uma tentativa assim sem ninguém mandar. No cenário oposto, sem essa estrutura, se eu agir sozinho como um herói, a equipe inteira acaba vindo atrás para corrigir erros e apagar incêndios, e no fim o time se torna realmente ineficiente