O que Engineering Managers deveriam fazer?

Visões sobre um papel que é mais arte do que ciência

15 de julho de 2020

Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.

O modelo Spotify tem sido um padrão de fato de estrutura organizacional na indústria de tecnologia durante a maior parte da última década. E recentemente um artigo descrevendo suas falhas recebeu muita atenção. Ele ilumina um modelo que ninguém entendeu, mas todo mundo tentou copiar.

Embora eu não queira dissecar tudo o que foi dito sobre ele (leia, é excelente), quero aprofundar em um tema que está na minha cabeça há um tempo: o que Engineering Managers deveriam fazer?

Na descrição do Modelo Spotify, Jeremiah escreve:

Engineering managers neste modelo tinham pouca responsabilidade além do desenvolvimento de carreira das pessoas que gerenciavam. Mesmo assim, sua capacidade de ajudar com habilidades interpessoais era limitada. Um engineering manager não gerenciava pessoas suficientes do time ou estava envolvido o bastante no contexto diário para avaliar independentemente conflitos dentro do time.

A descrição acima ressoa com minha experiência recente em gestão de engenharia, especialmente em uma das minhas últimas empresas. Quando a atenção do gestor está espalhada entre diferentes pessoas em diferentes times, a falta de contexto torna o gestor menos eficaz.

O Modelo “Spotify”

No meu período nessa empresa, tínhamos mudado de um modelo de gestor-por-disciplina (o gerente de desenvolvimento web) para um modelo de gestor-por-time, pela razão descrita acima. Embora eu acredite que a mudança foi positiva, tivemos dificuldade em definir o novo papel em toda a organização. No final, alguns engineering managers eram principalmente gestores de pessoas, alguns eram tech leads de alto nível, e alguns focavam na entrega do time.

Houve múltiplas rodadas de discussão aberta, e não conseguimos chegar a um consenso. A falta de alinhamento geral mesmo nos objetivos primários desse papel reflete o estado da indústria em geral, pelo que posso observar.

Um Ato de Equilíbrio

Gestão de engenharia vem em muitos sabores hoje em dia. É um papel relativamente novo na indústria, e também precisa se adaptar à situação de cada empresa. É um papel que geralmente preenche diferentes lacunas dependendo do contexto, o que torna difícil descrevê-lo.

Pat Kua fez recentemente um ótimo trabalho ao dissecar o papel, usando quatro áreas de habilidades diferentes para definir diferentes arquétipos: técnico, time, processo e produto.

Áreas de habilidade de Engineering Management

Pessoas estão desempenhando esse papel em um nível excelente de muitas formas, e isso precisa ser respeitado. Empresas e times são diferentes, e existem múltiplas formas de criar uma organização de alta performance.

Mas podemos escolher um lado. Pelo menos eu posso. Meu objetivo aqui não é analisar múltiplas opções, mas inverter a pergunta: como você deveria enquadrar o papel do Engineering Manager na sua organização?

Antes disso, porém, vamos olhar um contexto relevante.

Dando um Passo Atrás

Em 2001, o Manifesto Ágil nasceu. Ele propôs uma forma refinada e mais interativa de entregar produtos de software, em contraste com estruturas de gestão anteriores menos flexíveis que eram inspiradas em outras disciplinas de engenharia.

Ele tomou a indústria de assalto. A ideia de desenvolvimento iterativo de software e produto, trabalhando em colaboração próxima com todo o time e clientes, provou ser muito mais útil do que os métodos existentes na época e se tornou um padrão de fato da indústria.

Ágil não foi criado no vácuo. Ele se inspirou significativamente nos Sistemas de Produção Lean/Toyota. Ambos eram baseados no princípio de que planejar (ou construir) demais com antecedência é desperdício, e a melhor abordagem é reduzir o lote de trabalho ao seu tamanho mínimo. Embora existam investimentos a serem feitos para tornar essa redução possível, eles são rapidamente compensados pelos erros que você não cometeu ao tentar prever o futuro.

Ambos também investiam fortemente no processo. Para o ágil funcionar, existem práticas de engenharia, projeto e produto que precisam estar implementadas para que lotes pequenos sejam possíveis. Pense em CI/CD e testes automatizados no lado técnico, mas também em escrever user stories que são iterativas no lado do produto, entre muitas outras.

Principalmente, eles se baseavam na ideia de que o processo, e não apenas o talento individual, impulsiona a produtividade. Métodos iterativos propõem que o processo certo vai potencializar o desempenho individual enquanto otimiza o fluxo de trabalho do grupo.

Se você não consegue descrever o que está fazendo como um processo, você não sabe o que está fazendo. — W. Edwards Deming

Ágil agora é mainstream. A maioria das empresas hoje usa alguma forma dele para gerenciar seus projetos. Mas muitos dos seus princípios, que permitiam que a ideia funcionasse efetivamente, decaíram na minha experiência. Especialmente a parte de colaboração.

Essa situação pode ser explicada pela forma como a indústria evoluiu. Empresas de tecnologia precisaram escalar, e talento de engenharia é escasso. Com isso, gestão e processo em engenharia migraram para encontrar estrelas individuais: a ascensão dos rockstars e engenheiros 10x. Nesse contexto, de financiamento de venture capital, empresas de tecnologia escalando e talento difícil de encontrar, o papel de engineering manager foi formado.

Qual é o problema com isso?

A gestão de engenharia se tornou muito focada em pessoas e em mentorar carreiras, mais do que em processo, ou em como tornar times produtivos. E gerenciar como o trabalho funciona perdeu relevância.

Com isso, times de engenharia são menos eficientes. Faz sentido criar formas de trabalho assíncronas e mais individuais se você precisa rapidamente integrar e gerenciar milhares de engenheiros (e financiamento não é um problema). Qualquer estilo de gestão pode funcionar bem em um mercado em expansão.

Mas isso não funciona para a maioria das empresas. Para a realidade de times em startups e organizações menores, onde você conta engenheiros nas dezenas e não milhares e onde o quanto você gasta ainda é uma preocupação, focar na produtividade do time ainda é a melhor aposta.

Exemplos dessa mudança em direção a contribuições individuais estão ao nosso redor. Da aversão ao pair programming, que torna difícil disseminar conhecimento em um time, aos modelos de GitFlow, que atrasam a entrega em favor de não interromper o fluxo dos indivíduos.

Como empresas gerenciam engenharia é um aspecto crucial para viabilizar essa mudança.

O papel do engineering manager

Existem muitas decisões a serem tomadas ao moldar uma organização de tecnologia de alta performance. E o papel do Engineering Manager oferece alavancagem significativa quando se busca esse objetivo.

Se a sua empresa tem times multidisciplinares de engenharia de produto e busca excelência na execução, o papel do EM deveria focar em pessoas e execução de entrega. Se o grupo não está performando bem, ou o trabalho não é gratificante para os engenheiros, deveria ser responsabilidade do EM.

Isso não quer dizer que o EM não deveria estar envolvido em decisões técnicas e de produto, mas essas não deveriam ser aquilo pelo qual ele é responsabilizado. Eis o porquê:

• Gestores que gerenciam como o time trabalha podem ser responsabilizados pela entrega. Ao definir o processo e como o time de engenharia está trabalhando, o gestor tem alavancagem significativa no desempenho do time.

• Gestores que gerenciam os engenheiros e o processo de um time podem ter um impacto mais amplo na carreira de um indivíduo. Ao ter mais controle do ambiente onde o engenheiro trabalha e que tipo de trabalho ele faz, o gestor pode mais facilmente adaptar o trabalho para focar em interesses individuais.

• Gestores que gerenciam toda a engenharia de um time entendem melhor o trabalho. Ao gerenciar todos os engenheiros, o gestor tem um melhor entendimento do trabalho sendo executado. E mais capacidade de ajustar.

• Gestores que são responsáveis por resultados e pela satisfação profissional das pessoas ao mesmo tempo serão capazes de fazer os melhores trade-offs. Objetivos do time e do negócio nem sempre estão em sincronia com metas individuais. Tornar os gestores responsáveis por ambos os lados permitirá que eles tomem as melhores decisões nessa área.

Já que sucesso significa dizer não à maioria das coisas, aqui estão as razões pelas quais EMs não deveriam gastar a maior parte do seu tempo em outras atividades.

• EMs não deveriam ser o principal tomador de decisões técnicas em projetos de engenharia. Gestores trabalham em uma agenda de gestor, o que torna muito difícil ter tempo suficiente para compreender todos os detalhes técnicos de um sistema. Embora EMs devam ajudar a conduzir decisões em tecnologia, depender deles para tomá-las geralmente leva a situações de arquitetura de torre de marfim. Se o time é grande o suficiente para precisar de orientação técnica, o papel de tech lead é apropriado para isso.

• EMs não deveriam ser responsáveis por decisões de produto. Embora EMs e engenheiros devam trabalhar de perto com produto e design, geralmente há de 4 a 8 engenheiros para uma pessoa de produto em um time. Não investir em como os engenheiros trabalham juntos em favor de outras disciplinas significa não investir na área de maior alavancagem (e custo) de um grupo.

Essas são diretrizes e não regras rígidas. Tudo é contextual quando se trata de organizações. Mas lembre-se de que você deveria estar em busca do time 10x, não do engenheiro 10x. Ser intencional sobre a gestão dos seus times é o caminho mais curto para chegar lá.