Regras revisadas de liderança em engenharia

• Resumo das 5 principais regras de liderança em engenharia, redefinidas e validadas no último ano em um ambiente de transição para ferramentas de IA e crescimento rápido (hypergrowth), junto com casos reais de projetos que as sustentam
• Migrações agora podem ser conduzidas 95% por indivíduos, não por equipes, e concluídas em 10% do tempo anterior; quanto menor o custo inicial, maior se torna a influência do julgamento individual
• O código inicial é quase gratuito, mas o custo de um código que funciona bem depende de harnesses de desenvolvimento, como testes e CI/CD, portanto não é gratuito
• O caso padrão da maioria dos processos pode ser totalmente automatizado com agentes, e a primeira passada de code review feita por um bom harness é mais rápida e eficaz do que a humana
• Para realmente aproveitar os benefícios da IA, são pré-requisitos equipes contínuas com contexto de domínio e tomadas de decisão rápidas e robustas

---

Contexto

• Trabalhei em um ambiente de hypergrowth do início de 2014 ao fim de 2020; o maior valor do hypergrowth é que os erros aparecem no mês seguinte, não no ano seguinte (se você se move rápido, os problemas explodem em grande escala)
• O motivo de eu ter voltado a pensar recentemente em hypergrowth foi o rápido crescimento do negócio da Imprint, as contratações em larga escala do ano passado e a transição para ferramentas de IA, que mudou a velocidade com que o trabalho pode ser feito
• Este texto reúne as regras de liderança redefinidas e os projetos concretos do último ano que me levaram a acreditar nelas

Regras revisadas

1. Migrações podem ser feitas por indivíduos, não por equipes

• Mesmo mudanças grandes e complexas são 95% apropriadas por um indivíduo ou equipe que as lidera e concluídas em 10% do tempo em comparação com antes
• Quanto menor o custo inicial, maiores ficam as recompensas/penalidades pela qualidade de cada migração
  • Mesmo pequenos defeitos destroem o modelo mental de software dos colegas que também fazem manutenção
• A influência do julgamento individual sobre a empresa está maior do que nunca

2. O código inicial é quase gratuito, mas o custo do código funcional depende do harness de desenvolvimento

• Estamos em uma era em que todos devem escrever código, mas escrever código que funcione bem evitando edge cases confusos ainda é difícil
• Essa dificuldade é determinada por harnesses de desenvolvimento, como testes, CI/CD, ambientes de validação e pré-visualizações de mudanças
• Mesmo em uma empresa em que "todos programam", o ponto central não é a equipe de marketing reduzir a alocação de servidores, mas se existem fronteiras que permitam que ela participe com segurança (semelhante a produtos SaaS que permitem customização por meio da escrita de software)
• As coisas que eram mais valiosas para aumentar a velocidade da engenharia há dois anos continuam sendo as mais valiosas hoje

3. Otimize o caso padrão dos processos para agentes

• Com harnesses, controles e contexto de domínio adequados, além do bom julgamento do designer, é possível automatizar totalmente o caso padrão da maioria dos processos
• O caso padrão de code review humano é mais lento e menos eficaz do que o code review de um bom harness
  • Harnesses também deixam coisas passar, mas pessoas também deixam; na maioria das áreas, mudanças são relativamente seguras
  • Algumas áreas de alto risco, porém, são exceções; se essa distinção for bem capturada, você acelera sem risco; se falhar, surgem inúmeros problemas
• Como corolário, processos de planejamento como sprints semanais ou quinzenais operam em uma altitude baixa demais, e o planejamento conjunto entre pessoas deve acontecer em um nível mais alto

4. Equipes contínuas e de alto ownership, com contexto de domínio, são ainda mais importantes

• Lição aprendida na Uber: equipes contínuas e robustas acumulam contexto de domínio, constroem camaradagem e geram resultados quase mágicos por meio de um forte senso de ownership
• Mesmo em uma era em que o custo de execução ficou barato, ainda é preciso fazer a coisa certa, e isso ficou só um pouco mais fácil, não muito
  • Ex.: os dados necessários para otimização em produção simplesmente não eram coletados; a solução do harness era razoável, mas errada, e a única solução foi instrumentar as informações ausentes
• Discordo da noção comum de que empresas AI-first serão operadas por alguns engenheiros geniais; mesmo indivíduos com grande capacidade de julgamento esbarram na falta de contexto de domínio, portanto equipes contínuas são a unidade fundamental

5. Decisões rápidas, boas e robustas são pré-requisito para colher benefícios da IA

• Para substituir a revisão jurídica por automação, o time Jurídico precisa poder se comprometer com essa mudança, e isso depende de um design cuidadoso e da disposição das equipes para colaborar
• Os benefícios de uma execução mais rápida só são possíveis quando se consegue tomar decisões rápidas, robustas e boas
• Esse é o principal motivo pelo qual o papel médio de CTO ficou muito mais técnico e menos burocrático do que era há um ano
  • Muitas vezes, ele é a única pessoa capaz de tomar uma decisão vinculante quando há divergência entre equipes, então passa o tempo todo decidindo para manter a velocidade
  • Não se trata de afirmar que executivos tomam decisões melhores, mas, desde que estejam alinhados entre si e respeitem as decisões, uma decisão executiva vinculante é singularmente poderosa

Casos reais de aplicação

Migrações

• Há um ano, fazíamos deploy manual cerca de 6 vezes por semana → hoje fazemos 200 a 400 deploys por semana; embora o número de engenheiros tenha dobrado, isso representa um aumento de 20 a 30 vezes ano contra ano, e 2 pessoas da equipe de infraestrutura fizeram 90% da reformulação completa da operação de deploys e migrações em dois meses
• Em 1º de janeiro, cerca de 25% usavam Claude Code ou Cursor todos os dias → no fim de fevereiro, 100%; sem ordem top-down, removemos atritos melhorando a qualidade das ferramentas e conversando com quem não as adotava; hoje, quase todos os PRs têm a primeira versão escrita pelo harness
• Consolidamos várias formas de configuração em dois mecanismos de configuração (um para constantes cliente/servidor que quase não mudam e outro para valores por produto e que mudam com frequência), como projetos independentes de engenheiros individuais
  • Uma pessoa organizou a arquitetura → outra implementou a arquitetura de referência → várias aplicaram em outras áreas; no passado, isso teria sido um projeto de vários anos, mas foi concluído em menos de um trimestre, incluindo ferramentas internas para equipes de engenharia e não engenharia gerenciarem valores
• Unificamos front-ends em múltiplos repositórios em uma arquitetura de monorepo em cerca de um mês; 95% foi liderado por uma engenheira de front-end, garantindo um harness de front-end compartilhado e eliminando completamente a hospedagem de pacotes npm, que era uma fonte de atrito
• Tornamos totalmente tipado estaticamente o código de front-end que, em sua maior parte, não tinha tipos; um engenheiro fez isso ao longo de algumas semanas usando uma grande quantidade de tokens
• Para melhores padrões de segurança e deploys mais rápidos, fizemos a transição de npm para pnpm; um engenheiro trabalhou nisso por alguns dias, algumas horas por dia

O custo do código funcional depende do harness de desenvolvimento

• A prática de "jogar por cima do muro" documentos de design ou PRs para engenheiros de outras equipes não gera resultado; PRs e documentos de design ruins (slop) são baratos, mas acabam sendo prejudiciais
  • Eles exigem limpeza e correção, e esse contexto contamina o LLM, levando a resultados piores do que começar do zero
• Quando um gerente valida diretamente uma mudança, verifica dashboards após o deploy e resolve os problemas que surgem, a contribuição de código do gerente é um grande sucesso; caso contrário, não há efeito positivo

Otimização do caso padrão dos processos para agentes

• Todos os issues recebidos pela equipe de operações de clientes são triados por um harness que conhece as equipes e tickets abertos e tem acesso limitado ao data warehouse para estimar impacto, processando mais rapidamente um trabalho complexo e de alta habilidade, mas pouco interessante
  • Edge cases ainda são triados por pessoas, e apenas algumas etapas são automatizadas dentro do mesmo fluxo, sem mudar o workflow humano
• A primeira passada de code review é feita pelo mesmo harness que implementou a mudança, mas com o contexto de escrita esvaziado; pessoas se concentram em feedback de maior valor
• No último trimestre, implantamos Claude Code e Cowork em toda a empresa; a equipe de fraud, em especial, substituiu de forma agressiva trabalho manual por automação de primeira linha, automatizando a investigação inicial de possíveis ataques (incluindo atribuição baseada nos próprios dados)
• Migramos do Jira para o Linear, fortalecendo a infraestrutura de workflows agent-first com MCP mais poderoso e melhor integração com Slack; o alpha test de um harness interno que busca issues no Linear e os resolve automaticamente está quase concluído

Equipes contínuas e de alto ownership, com contexto de domínio

• Quando entrei, pessoas talentosas alternavam rapidamente entre áreas por projeto, tornando a organização muito reativa; hoje, todas as áreas importantes têm pequenas equipes dedicadas fazendo investimento contínuo, e essas equipes usam diretamente novas técnicas de IA
• Após o lançamento do SierraAI, a equipe o melhorou continuamente até um nível verdadeiramente excepcional; um resultado que teria sido impossível sem uma equipe dedicada e focada

Decisões rápidas, boas e robustas

• A mudança na forma de configuração foi polêmica, exigindo explicar repetidamente a abordagem; o impacto variava por equipe e os benefícios só apareciam no nível do ecossistema (uma pessoa configurar tudo para todas as equipes), então era difícil fazer de baixo para cima
• A reformulação do pipeline de CI/CD também foi polêmica por mudar o modelo mental de deploy e release, forçando a separação explícita entre deploy e release por meio de feature flags
• A unificação do monorepo web também foi uma decisão polêmica e dividida, em que o benefício de uma decisão unificada foi grande
• A adoção do SierraAI envolveu discussões difíceis com concorrentes e com a opção de não adoção, exigindo aprovação executiva para encerrar debates cross-funcionais

Conclusão

• Os casos acima são apenas alguns exemplos representativos; muitos outros também foram realizados, e o escopo do que é possível continua se expandindo a cada mês
• Os fatores que nos atrasam não mudaram muito: desalinhamento organizacional, falta de clareza e arquitetura técnica ruim