Por que engenheiros sêniores deixam projetos ruins seguirem adiante

• Engenheiros sêniores priorizam “agir de forma eficaz” mais do que “estar certo” e não tentam impedir todos os projetos errados
• “Projetos ruins” incluem problemas técnicos, políticos e de UX, e muitas vezes variam conforme julgamento subjetivo
• A influência deve ser gerida como uma conta bancária; se você se opõe com frequência, perde credibilidade e pode cair em um estado de “falência política”
• A decisão de intervir depende da proximidade do projeto, impacto na equipe e escala do dano para a empresa
• Em vez de tentar resolver todos os problemas, é preciso escolher estrategicamente quando intervir; no restante, observar e se preparar

---

Definição e exemplos de projetos ruins

• “Projetos ruins” aparecem de várias formas, como resolver problemas desnecessários, designs complexos e motivações políticas
  • Do ponto de vista de UX, podem tentar resolver um problema que não existe ou quebrar um fluxo já estabelecido
  • Tecnicamente, envolvem complexidade excessiva, escolha errada de biblioteca e arquitetura ineficiente
  • Politicamente, são projetos feitos para promoção ou para seguir modismos
• O que é bom ou ruim em um projeto é um julgamento subjetivo que só fica claro com o tempo, e no início raramente é evidente
• Em um caso no Google, um projeto em que a equipe de plataforma tentou transferir um fluxo central de usuários para outra equipe fracassou por motivos políticos
  • Tecnicamente era excelente, mas foi descartado dois anos depois por questões de autoridade entre organizações
  • A lição foi: “política e precisão na definição do problema são tão importantes quanto a qualidade técnica”

Por que não dá para impedir todos os projetos ruins

• Empresas de software têm um forte viés de “executar rápido”, então levantar preocupações costuma ser visto como algo que atrasa o andamento
  • Por isso, se não for percebido como um grande problema, é muito provável que seja ignorado
• Oposição repetida faz a pessoa ser rotulada como “negativa”, e falhas evitadas não costumam ser reconhecidas
• Se opor pode afetar a promoção de outras pessoas ou projetos de executivos, trazendo risco político
• A capacidade de atenção que um único engenheiro consegue sustentar é limitada, e intervir em tudo leva ao cinismo

Gerindo a influência como uma “conta bancária”

• Influência é um ativo acumulado por resultados e colaboração, e cada oposição representa um saque
  • Cheque de $5: apontamento pequeno no nível de code review
  • Cheque de $500: contestar uma decisão de arquitetura ou cronograma
  • Cheque de $50,000: tentar interromper um projeto de nível executivo
• Intervir repetidamente em problemas menores faz você perder capacidade de reagir em questões grandes
• Quando a influência se esgota, a pessoa cai em “falência política”, sendo excluída de reuniões ou tendo suas opiniões ignoradas

Critérios para decidir quando intervir

• Validação da expertise: verificar se seu julgamento está suficientemente bem fundamentado
• Reconhecer os limites da fala: apresentar uma opinião não é “dar ordens”, mas “compartilhar uma perspectiva”
• Três fatores de avaliação
  • Proximidade (Proximity): quanto mais perto do seu time, menor o custo de intervir
  • Impacto na equipe (Team Impact): se a falha pode causar dano direto ao time, vale mais a pena intervir
  • Escala na empresa (Company Scale): se o fracasso afeta toda a organização, a intervenção se torna mais necessária

Formas de responder a projetos ruins

• Intervenção direta: pedir a interrupção do projeto ou enviar um documento formal com fortes preocupações
  • Exige convicção e disposição para assumir riscos
• Intervenção parcial: ajustar a direção do design ou conduzir a equipe para uma solução melhor
  • Com uma postura colaborativa, é possível ser visto como “alguém que ajuda”
• Não intervir: quando a inércia política ou o limite de influência tornam a intervenção pouco valiosa
  • Se a equipe estiver envolvida, é preciso preparar medidas de proteção, como reduzir dependências ou construir alternativas
  • Se não houver relação direta, o melhor é observar em silêncio e compartilhar a opinião apenas internamente
• Gestão da equipe: compartilhar a realidade com franqueza, mas sem expor detalhes políticos desnecessários

Conclusão

• A percepção central é que “estar certo e ser eficaz são coisas diferentes”
• Em grandes empresas, política e contexto pesam mais do que lógica, e nem todo erro pode ser corrigido
• É preciso usar influência e confiança de forma estratégica para focar nos momentos em que mudanças reais são possíveis
• Nos demais casos, o melhor é compartilhar com colegas, se preparar e aprender por meio da observação
• Mesmo sem resolver tudo perfeitamente, essa é uma abordagem sustentável

[GN⁺]

Comentários do Hacker News

• Lembrei de um gerente que certa vez disse: “às vezes é preciso deixar as pessoas falharem”
  Estava consumindo energia demais ficar sustentando certas pessoas o tempo todo. Eu esperava que, em algum momento, elas nadassem sozinhas, mas às vezes esse esforço era melhor empregado em outro lugar
  Houve um projeto que seguiu sem a minha participação e que jamais poderia ter dado certo sem o meu conhecimento. A equipe era tão ruim que misturava perguntas no meio do trabalho como se isso fosse rotina
  Além disso, quando descobri que a liderança estava rebaixando a minha equipe e elogiando eles, senti uma verdadeira humilhação. A implementação deles era horrível

  • Eu costumo dizer: “às vezes é preciso deixar o gerente falhar”
    Alguns gerentes odeiam ouvir que a ideia deles não vai funcionar. Se você retruca, vira o culpado pelo fracasso
    Então eu sigo com o trabalho, mas compartilho o andamento com frequência. Assim, eles veem com os próprios olhos a falha que já era previsível, e isso me dissocia do fracasso
  • Quando a liderança falha, não fica culpando uns aos outros. Em vez disso, chamam consultores e demitem engenheiros seniores
  • Já ouvi a frase: “as pessoas precisam coletar seus próprios dados”. No fim, só se aprende batendo de frente
  • Acho que o fracasso de uma pessoa e o fracasso de um projeto são coisas diferentes
    O fracasso individual tem custo baixo e é educativo. Às vezes, a abordagem delas até funciona, e a organização acaba ganhando um novo ativo de conhecimento
  • Deixar as pessoas aprenderem sozinhas é arriscado. Você precisa confiar que elas têm autopercepção e que não estão apenas se apoiando na sua ajuda
    Elas podem falhar e não aprender nada. Mas, se você fez o seu melhor, pelo menos pode ficar com a consciência tranquila

• O fato de um projeto ser “ruim” é, durante a maior parte do seu ciclo de vida, algo subjetivo
  Já houve gente de fora tentando barrar um projeto por ser contra, mas quando ele foi lançado e deu certo, a credibilidade deles desmoronou
  É preciso ter cuidado com onde você gasta sua reputação

  • Passei por algo parecido. Foi a primeira vez que vi um egoísmo tão escancarado em uma organização voltada para colaboração
    Eu sei que o mundo nem sempre é feito de sol e arco-íris, mas aquilo foi realmente decepcionante

• Como diz a expressão “não é meu macaco, não é meu circo”, eu não me meto no que não é minha responsabilidade
  Mesmo trabalhando como arquiteto, não dava conselhos desnecessários sobre UI ou lógica de negócio fora da minha área
  Em decisões tomadas por gerentes acima de mim, eu simplesmente seguia. Como consultor, mantive o mesmo princípio
  Só interfiro com cautela na minha área de especialidade. E isso apenas com aprovação da C-suite

• Esse conselho é bastante adequado para pequenas e médias empresas. Mas, em grandes empresas, quase não faz sentido se opor a um projeto
  Se der certo, você parece um idiota; se der errado, ninguém vai lembrar
  O verdadeiro ROI aparece quando você apresenta a solução depois do fracasso. As pessoas gostam de “resolvedores de problemas”
  Uma vez propus testes E2E automatizados e fui rejeitado; depois, quando o problema explodiu, trouxeram aquela framework de volta e eu fui tratado como herói

  • Quanto mais você sobe dentro da empresa, mais precisa assumir responsabilidade pelos erros dos outros e menos recompensa recebe
    Às vezes parece mais sensato ficar em um cargo mais baixo e viver sem tanto estresse
  • Em startups, basta alguns engenheiros dizerem “isso não faz sentido” para evitar um desastre
    Já em grandes empresas, a política faz com que anos e milhões de dólares sejam desperdiçados

• Eu sou da opinião de que “não se deve ignorar o problema”
  Se você está em posição de ajudar, deve ao menos sugerir discretamente uma abordagem diferente. Não precisa reagir emocionalmente

  • A condição “estar em posição de ajudar” é o ponto central
    Em organizações pequenas, boas ideias são facilmente incorporadas, mas em organizações grandes o risco político é muito maior
    Na prática, a chance de perder reputação é maior do que a chance de realmente ajudar. Por isso é importante escolher as batalhas
  • Em organizações pequenas, intervir cedo pode até ser uma obrigação
    Mas, em organizações grandes, mudar um projeto que já está em andamento exige tempo e energia enormes
  • A expressão “deixar um projeto ruim seguir” pode induzir ao erro
    Na verdade, muitas vezes não temos controle sobre esse projeto. “Não sei por que a outra equipe está fazendo isso” seria um título mais preciso
  • Quando prevejo fracasso, também deixo minha opinião registrada em documento e encerro ali
    Profissionalismo é falar quando se deve falar. Mas, pela minha experiência, quase nada muda
  • Se você sabe, fale, mas depois não carregue o peso emocional disso. Se ignoraram seu conselho, esse não é mais o seu problema

• Estou vendo exatamente isso acontecer agora
  O dono do negócio escolheu uma plataforma low-code por custo e velocidade, mas isso acabou exigindo uma customização gigantesca, em nível de gambiarra
  Minha equipe faz deploy várias vezes por dia com TypeScript, enquanto a outra faz deploy uma vez por mês e fica fazendo coisas bizarras com curl

• Esse conselho é excelente dentro da realidade política das big techs, mas no fim parece uma espécie de pacifismo corporativo
  Em outros ambientes, não existe essa folga para torrar dinheiro e motivação
  (Ainda assim, Lalit conseguiu condensar bem dinâmicas organizacionais complexas em um texto curto)

  • Nunca trabalhei em big tech, mas já vi o mesmo fenômeno em organizações pequenas
    Quem vive apontando problema acaba rotulado como pessoa negativa
    No fim, o conselho principal é guardar energia para os momentos importantes. Nem todo problema determina a sobrevivência da empresa
  • Pacifismo não é inação. Pelo contrário, é a ação política mais ativa e eficaz

• Engenheiros não têm autoridade para “deixar um projeto ruim falhar” por motivos políticos
  Isso é responsabilidade da liderança. O papel do engenheiro é apenas dar aconselhamento técnico
  Ainda assim, entender essas dinâmicas evita prejuízo para a carreira
  A disputa de território entre equipes de produto e de plataforma existe por falta de liderança clara
  Se você quer entender por que isso acontece com tanta frequência, vale ver este post sobre o Google

• Esse modo de pensar é comum em organizações grandes, especialmente em órgãos públicos
  Os custos recaem sobre outro departamento, e o poder é medido pelo número de pessoas sob gestão
  Para impedir essa necrose organizacional, líderes precisam estabelecer métricas claras e mecanismos de prevenção

  • Seres humanos gostam instintivamente de gente positiva e desgostam de gente negativa
    Ignorar o capital político não faz com que ele desapareça

• É uma boa analogia
  Quando você constrói liderança e confiança, surge o espaço para dizer “você está errado”
  Mas um dos motivos de líderes nem sempre confiarem nos engenheiros é que, às vezes, os engenheiros estão errados
  Engenheiros são ótimos em encontrar falhas, mas fracos em entender contexto de negócio
  Por isso, até uma “ideia que parece estúpida” deve ser julgada depois de se entender o contexto
  Quando você consegue distinguir entre uma ideia que realmente precisa ser eliminada e uma ideia apenas defeituosa, conquista a confiança dentro da organização