Anti-padrões para líderes de engenharia

• Ao conversar com CTOs ou líderes de engenharia, o tema que surge com mais frequência é a pressão do CEO para "aumentar a velocidade da engenharia"
• Ao contrário de vendas ou contratação, a engenharia não tem indicadores de desempenho claramente definidos
• Do ponto de vista do líder de engenharia, é difícil dizer ao CEO que "engenharia é uma arte, então é difícil prever resultados"
• Causas das divergências entre líderes de engenharia e executivos
  • Líderes de engenharia tendem a seguir conselhos convencionais de liderança de forma rígida demais
  • Quando se generaliza que certa prática é útil ou não, fica difícil aplicá-la de acordo com o contexto da organização
  • O ponto central de uma liderança de engenharia eficaz é decidir, conforme a situação, se vale seguir uma prática estabelecida ou tentar uma nova abordagem
• Texto que resume o que o CTO da Carta, Will Larson, falou em um podcast

3 anti-padrões da liderança em engenharia

1. Evitar micromanagement
2. Evitar medir indicadores imperfeitos
3. O líder virar um guarda-chuva para o time

[Anti-padrão #1: evitar micromanagement]

Três papéis contraditórios para se tornar um grande executivo de engenharia

• Um executivo de engenharia precisa desempenhar três papéis conflitantes entre si, e os melhores conseguem transitar habilmente entre eles
  • Papel como membro da liderança executiva: buscar formas de fazer o negócio avançar
    • Às vezes isso pode significar tomar decisões "ruins para a engenharia como um todo", como cortar orçamento de engenharia
    • Isso também pode incluir migrar para um modelo de unidade de negócios em que a voz da engenharia tem menos peso em determinados temas
  • Papel como gestor de engenharia
    • Entender a estrutura de políticas necessária para operar a organização de engenharia e buscar formas de se tornar um líder de pessoas eficaz
  • Papel como engenheiro
    • Assumir responsabilidade pela excelência técnica e pela execução de engenharia, apesar dos fatores externos de pressão
    • É preciso manter um padrão alto de excelência técnica
• Muitos executivos tendem a se inclinar demais para apenas um desses três papéis
• Independentemente do papel que estejam exercendo, líderes cometem erros quando insistem em práticas de gestão que já não ajudam mais
• Quando alguém de repente se torna gerente de um time, passa a ter mais contexto técnico sobre tudo o que o time faz, mas ao mesmo tempo se torna gestor de pessoas
• Nesse momento, essa pessoa continua ouvindo conselhos para se afastar dos detalhes
• Novos gerentes de engenharia costumam ouvir conselhos como "saia do código"
• Ele reconhece que esse conselho pode ajudar algumas pessoas
• Mas executivos altamente competentes mantêm certo nível de entendimento detalhado sobre o domínio que operam
• Se você se afasta demais dos detalhes, vira apenas um burocrata — e esse é um dos motivos pelos quais tantos gerentes de engenharia acabam se tornando burocratas

Cultivar estilos de liderança

• Larson recomenda que executivos de engenharia esqueçam completamente o termo micromanagement e, em vez disso, foquem em cultivar diferentes estilos de liderança para escolher entre eles
• Quando não há um caminho claro à frente, ou quando pessoas com contexto sobre o rumo a seguir discordam intensamente, pode ser útil mergulhar nos detalhes e tomar a decisão por conta própria
• Isso ajuda a entender quais alavancas realmente podem mudar o negócio, quais resultados o time precisa alcançar, em que prazo e como atender melhor os usuários
• Desenvolver maior convicção para tomar decisões é algo que exige prática ao longo da vida, e o próprio Larson diz que ainda está trabalhando nisso
• Fazer perguntas mensalmente ou trimestralmente como "O que estamos fazendo?", "Por que estamos fazendo isso?", "Quais são os dados?" e "Onde está a fonte real desses dados?" ajuda a aprofundar o entendimento dos detalhes

Duas táticas para se aproximar dos detalhes

1. Entender o contexto por meio de "mineração de conflitos"

   • Em um novo ambiente, deixar passar pequenas diferenças de contexto pode comprometer o sucesso operacional
   • Mesmo que leve tempo, é importante conversar com pessoas que têm pontos de vista opostos para encontrar as "sementes do conflito"
   • Líderes bem-sucedidos perguntam "como eu devo mudar para me adaptar à organização?", e não "como devo mudar a organização para que ela se adapte ao meu jeito?"

2. Documentar os detalhes

   • Estratégia existe em todo lugar, mas quase nunca está documentada
   • Muitas vezes, a base de decisões importantes não está registrada
   • Construir uma cultura de documentação é a chave para uma organização de engenharia que se move rápido
   • Novos líderes devem investigar tudo o que já existe antes de criar sua própria estratégia e usar casos de sucesso de outras empresas como benchmark
   • Ao escrever documentos de estratégia, ele recomenda usar o framework de "Good Strategy, Bad Strategy", de Richard Rumelt
   • Por pior que uma estratégia seja escrita, o simples fato de documentá-la já pode melhorá-la de um dia para o outro

[Anti-padrão #2: evitar medir indicadores imperfeitos]

• Anti-padrões são abundantes quando o assunto é medição
• Idealmente, seria possível dizer de forma pura e simples "não deveríamos medir isso", mas fazer isso apenas desacelera o aprendizado da organização ao redor
• Uma das coisas mais valiosas que um executivo de engenharia pode fazer é ensinar aos outros executivos como a engenharia funciona

Focar em melhorar modelos mentais

• Esperamos que indicadores mostrem a realidade, mas eles não servem apenas para revelar a verdade — também servem para educar as pessoas
• Você deveria se preocupar mais em informar o modelo mental do conselho ou do CEO do que em proteger o seu próprio modelo mental de ser ofendido

Trazer o CEO para os detalhes

• Em vez de dizer "esse é um jeito terrível de medir isso", é melhor dizer "vamos começar por aqui e aprofundar até entendermos as limitações de medir dessa forma"
• Forçar as pessoas a se afastarem dos detalhes nunca é uma boa abordagem. É preciso trazê-las para dentro dos detalhes e educá-las ali

[Anti-padrão #3: virar um guarda-chuva para o time]

• No passado, ele acreditava em agir como um "guarda-chuva" para proteger o time
• Mas proteger o time da realidade acaba prejudicando-o no longo prazo
• Tanto gerentes quanto engenheiros devem poder participar de conversas importantes

Uma nova perspectiva para decisões estratégicas

1. Estratégia Bottom-Up
   • Vantagens: permite que o time se mova rápido e controle suas ferramentas
   • Desvantagens: falta capacidade de investimento técnico concentrado, e as informações chegam com algum atraso
2. Estratégia Top-Down
   • Desvantagem: é ineficiente quando o CTO ou um grupo de arquitetura toma todas as decisões
   • Raramente um comitê toma a melhor decisão

Usar "navegadores" para acelerar a tomada de decisão

• Colocar "navegadores" em cada unidade de negócio, atuando como uma espécie de "mini CTO", acelera a velocidade das decisões
• Isso permite que as pessoas com mais contexto no campo tomem as decisões mais adequadas sobre a stack tecnológica
• Lições para o sucesso:
  1. Não deixar de documentar
  2. Fazer revisão posterior
  3. Ser extremamente criterioso ao escolher em quem confiar
• A organização é o acúmulo da capacidade de julgamento de um pequeno número de pessoas, e não há como escapar disso

Encerramento

• O perigo de seguir regras rigidamente demais
  • Quando o time de engenharia começa a crescer junto com a empresa, líderes não devem esquecer aquilo que antes colocou muitos executivos bem-intencionados em apuros
  • O objetivo final é criar mecanismos de alta qualidade para que as pessoas mantenham a curiosidade e procurem exceções
• Círculo de Aprendizado (Learning Circle)
  • Larson realiza um "círculo de aprendizado" a cada duas semanas há três anos e meio
    • De 6 a 10 CTOs, VPs of Engineering ou outros executivos seniores de engenharia de empresas de tecnologia se reúnem para compartilhar atualizações e trocar questões táticas e de processo
    • Cada encontro começa com um rodízio de 1 minuto por pessoa, em que todos falam no que estão focando naquela semana e sobre o que gostariam de discutir
    • Depois de cerca de 5 minutos falando sobre os temas, o grupo escolhe um deles e passa os 20 minutos seguintes aprofundando-o
    • Os temas vão desde "esse projeto está me colocando em uma situação difícil" até "contratamos uma pessoa nova realmente excelente e estou animado"
• Aprender pela prática
  • Pessoas que aprendem pela prática podem recorrer a reflexões regulares, como círculos de aprendizado ou reflexão pessoal, para forçar a autoanálise necessária ao ajuste fino das regras
  • Larson diz: "Aprendi com as lições de outras pessoas que cometeram erros parecidos com os meus e me tornei um líder melhor"

[geniuskey]

Fiquei um pouco constrangido com a parte final, algo como “Larson disse: ‘eu me tornei um líder melhor...’”. Teria sido mais confortável de ler se fosse uma formulação do tipo “um líder deve se esforçar continuamente para... Eu ainda tenho muito a melhorar e continuo tentando evoluir”. Será que isso é uma visão coreana demais? ^^;;

[savvykang]

Pelo jeito, ao perguntar se isso é uma perspectiva coreana, você parece conhecer bem o assunto. Na minha visão, a pessoa que fala nem está demonstrando narcisismo, então essa reação me parece um tanto estranha.

[tofumaker]

Focar na atitude de quem fala, em vez da essência ou do conteúdo do seu texto, é algo bem coreano.

[savvykang]

É "Antipadrão #1: evitar microgerenciamento", mas dizer para esquecer o microgerenciamento deixa o desenvolvimento do conteúdo estranho.

[frog08]

Considerar a micromanutenção como algo ruim, algo que não se deve fazer, e evitá-la incondicionalmente é que é um antipadrão. Em vez de julgar se é ou não micromanutenção, a ideia é cuidar dos detalhes conforme a necessidade.

[savvykang]

No mínimo, se tivesse sido algo como "anti-padrão: considerar micromanagement como uma opção" ou então "achar que cuidar dos detalhes e fazer micromanagement são a mesma coisa", o contexto teria ficado mais fluido. Entendo a intenção do texto, mas, no fim, a mensagem que ele quer passar é que, em vez de fazer micromanagement, o gestor deve cuidar dos detalhes, certo?

[kandk]

O assunto de conversa mais frequente com CTOs e líderes de engenharia é a pressão do CEO para "aumentar a velocidade da engenharia"
Ao contrário de vendas ou recrutamento, não há métricas de desempenho claras em engenharia
Do ponto de vista de um líder de engenharia, é difícil dizer ao CEO que "engenharia é uma arte e é difícil prever resultados"

[xguru]

Confira também as opiniões no Hacker News sobre este texto.

• Opinião de que a metodologia de Will Larson, aplicada em várias organizações, não tem sido tão eficaz. A metodologia dele gera conflitos entre engenharia e negócio.
• Recomendação do livro de Ron Jeffries: recomenda o livro "The Nature of Software Development", destacando valor incremental, protagonismo dos engenheiros, feedback contínuo e flexibilidade.
• Há um ponto positivo em Larson por sua capacidade de autorreflexão e de aceitar críticas. Os textos dele nem sempre estão certos ou errados, mas mostram um envolvimento profundo com a resolução de problemas.
• Pela natureza dos produtos baseados na web, erros não são fatais, e mudanças frequentes costumam acontecer por motivos de marketing. Por isso, forma-se uma cultura de agir rápido e tolerar erros.
• O lado positivo do microgerenciamento: bons líderes de engenharia entendem bem os detalhes e conseguem se comunicar com a equipe. Isso é diferente de microgerenciamento.
• Há gente demais em funções técnicas, o que acaba gerando problemas. Com ferramentas melhores, equipes menores provavelmente conseguiriam dar conta do trabalho.
• O problema não é a medição em si, mas tirar conclusões erradas a partir dos resultados. Métricas devem ser usadas como ferramenta para levantar perguntas.
• Em desenvolvimento de software em larga escala, colaboração é o elemento central. O colapso da comunidade é uma das principais causas da lentidão dos projetos.
• Quando os papéis e as expectativas de cada um no pipeline de desenvolvimento não estão claros, surgem problemas. Cabe aos gestores resolver essa situação.
• É um bom texto, mas há a opinião de que ficaria melhor se tivesse 25% menos conteúdo.