Esquecendo a Gestão
Como a indústria de software está deixando conhecimento essencial para trás
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Esse post faz parte de uma série sobre Criando Times Eficazes.
Acredito que tornamos a entrega de software mais complicada do que deveria ser. O que costumava ser uma indústria orientada por processos recentemente migrou para uma focada em pessoas. Embora essa mudança tenha melhorado muitas coisas, ela alterou alguns aspectos fundamentais para pior.
Precisamos entender por quê.
Engrenagem enferrujada
“Rusty cog” by grahnman is licensed under CC BY-NC-ND 2.0
Focando em processos
No início dos anos 2000, com o Manifesto Ágil, a indústria de tecnologia migrou para técnicas de gestão mais leves, valorizando software como uma categoria distinta de engenharia.
Foi altamente eficaz. Ciclos de feedback menores e planejamento mais sob demanda mudaram radicalmente como os times podiam entregar.
No entanto, esses times eram principalmente focados em processos. Se você olhar para as metodologias ágeis mais bem-sucedidas, como Scrum ou Kanban, verá que elas não dizem muito sobre a tecnologia em si. E dizem muito sobre gestão de processos.
A composição dos times na época também representava o mesmo pensamento. Gerentes de projeto (PMs) lideravam os times. Embora fossem tecnicamente conscientes, geralmente não eram engenheiros de software. Mas tinham amplo conhecimento em pensamento sistêmico e gestão de projetos tradicional. E a gestão de linha para engenheiros era papel de gestores que não estavam integrados a nenhum time.
Migrando para uma mentalidade de engenharia em primeiro lugar
No entanto, a indústria evoluiu. Vimos a ascensão de empresas tech-first, onde a tecnologia impulsiona o negócio. A liderança de times também precisava se adaptar, já que o gerente de projeto tradicional não era suficiente. Eles estavam gerenciando engenheiros altamente qualificados sem entender de engenharia.
Mais empresas tech-first também significaram que talento em engenharia se tornou escasso. Essa mudança forçou as empresas a mudar o foco para as pessoas. Para contratar e manter os melhores talentos, é preciso fazer os engenheiros se sentirem realizados. Isso significa dar autonomia e focar no crescimento de suas carreiras.
Nesse contexto, o papel de Engineering Manager (EM) é criado junto com a carreira em Y para engenheiros. A nova estrutura permitiu que engenheiros progredissem em suas carreiras continuando técnicos. E também ofereceu um caminho claro para gestão, tornando-se EMs, depois Diretores, VPs ou CTOs.
Essa mudança foi positiva, com engenheiros qualificados gerenciando times de engenharia. Porém, criou outro desafio. Engineering managers não têm experiência em gestão de projetos, e os times sentem falta dessa habilidade vital.
O artigo do NYT sobre o Projeto Oxygen do Google retrata bem essa cultura. O artigo resume o pensamento sobre gestão na época como
Deixe as pessoas em paz. Deixe os engenheiros fazerem suas coisas. Se ficarem travados, vão perguntar aos chefes, cuja profunda expertise técnica os impulsionou para a gestão.
Por que isso importa?
Gerenciar um time de software é mais do que deixar as pessoas em paz e resolver problemas reativamente. Também é mais do que apenas gerenciar a performance e a carreira dos indivíduos. Requer mais habilidades além de apenas entender de tecnologia e gestão de pessoas.
Na prática, porém, muitos Engineering Managers entram no papel sem muita experiência além de trabalhar como engenheiro. Sua única expertise é como contribuidor individual, e aprendem gestão cometendo erros.
Essa situação impacta negativamente os times com muita frequência. Embora esta não seja uma lista exaustiva, aqui estão alguns problemas que vi pessoalmente:
- Times gerenciados como um coletivo de contribuidores individuais que não colaboram de forma eficaz. A eficiência pessoal é alta, mas geralmente não resulta em entrega eficaz.
- Times onde a falta de processo dificulta que engenheiros aprendam com outros no trabalho. Seu principal processo educacional se torna comentários em pull requests.
- Times onde engenheiros têm sua performance questionada (e carreiras afetadas) porque os times são tão disfuncionais que os indivíduos não têm uma direção clara sobre o trabalho que precisam fazer.
- Times onde não há estrutura de decisão, criando um ambiente onde engenheiros seniores ficam decepcionados porque não conseguem liderar, e engenheiros juniores ficam frustrados porque precisam tomar decisões além de sua experiência.
Somando a tudo isso, evidências anedóticas e percepções se tornaram algumas das principais ferramentas usadas em engineering management. Perguntas simples sobre a eficácia de um time de software dependem principalmente de observação.
Em resumo, poderíamos fazer melhor.
O que é melhor?
Engineering management significa entender como o time funciona — criar um sistema que levará à melhor performance do grupo. Requer conhecimento da atividade de engenharia, das pessoas e de como todas as peças interagem para entregar o melhor resultado.
E não se pode esperar que os próprios contribuidores individuais melhorem seu processo. É muito difícil entender e melhorar o sistema quando você está dentro dele.
“Um sistema não pode entender a si mesmo sem ajuda de fora do sistema” — W. Edwards Deming
Engineering management precisa de engenheiros e de pensadores sistêmicos com profundo conhecimento do sistema de trabalho em si. Eles precisam ser tão apaixonados por como o trabalho funciona quanto são por escolhas de tecnologia.
Outras indústrias já fizeram isso. Os Sistemas de Produção Toyota/Lean usam a ideia de um gestor que é profundamente habilidoso no trabalho e no sistema. Em The Toyota Way to Lean Leadership, o autor fala sobre quatro níveis que precisam ser alcançados por um líder bem-sucedido:
- Comprometer-se com o Autodesenvolvimento
- Treinar e Desenvolver Outros
- Apoiar o Kaizen Diário (melhoria do sistema)
- Criar Visão e Alinhar Objetivos
Em tecnologia, o primeiro item acima é um requisito. Gestores são engenheiros que demonstram capacidade de se desenvolver. O segundo é frequentemente ensinado, já que empresas capacitam gestores em como gerenciar pessoas. No entanto, o terceiro e quarto níveis não são abordados e são deixados para os líderes aprenderem sozinhos.
As empresas deveriam apoiar melhor essa transição. A jornada em direção a engineering management precisa treinar engenheiros em processos, pensamento sistêmico e liderança. Precisamos deixar de pensar no engenheiro 10x para pensar no time 10x, encontrando sistemas de trabalho que permitam aos engenheiros entregar sua melhor performance enquanto trabalham como um time eficaz.
Não é simples. Frequentemente há desafios em criar harmonia: como pensar em sistemas no software? Como equilibrar necessidades individuais e do time? Como usar processos sem restringir indivíduos? Como usar a quantidade certa de métricas para inspirar sem restringir?
Essas são todas ideias que exploraremos nos próximos posts.