Escrever ou Não Escrever (Código)?
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Robot Thinker, por MidJourney
Um tema recorrente em liderança de engenharia é a necessidade de Engineering Managers (EMs) técnicos. Eles precisam programar ou não? Qual deveria ser a contribuição técnica deles?
Embora os contextos variem e não existam respostas certas ou erradas para esse tema, minha experiência em desenvolvimento de software de produto é que EMs técnicos terão uma vantagem. No entanto, o que significa ser técnico vai depender da situação. Em outras palavras, EMs idealmente deveriam ter experiência em engenharia de software* se o trabalho que estão gerenciando é engenharia de software.
Por que contribuições e conhecimento técnico são importantes, e como isso impacta um time de software? Para entender isso, precisamos olhar para o cenário mais amplo.
*Experiência em engenharia de software não significa necessariamente vir de uma formação tradicional em engenharia de software. Uma das vantagens do desenvolvimento de software é que qualquer pessoa pode aprender.
O Desafio da Entrega de Software
Para entender quais habilidades um gestor precisa, devemos olhar para o que o time dele está tentando alcançar. Afinal, o gestor está ali para liderar o time em direção a resultados. Times de software visam transformar ideias em software funcionando, resolvendo problemas para os clientes do time. Embora geralmente sejam multidisciplinares, EMs atuam em todo esse espectro, sendo responsáveis pela execução da entrega de software, mas também influenciando todos os aspectos do seu ciclo.
O EM atuará em todo o ciclo de desenvolvimento de software.
O EM deve trabalhar em direção a dois objetivos principais dentro desse contexto. Ele vai tornar o time produtivo, entregando os resultados esperados, e criar um ambiente estável que permita que os engenheiros performem e cresçam em suas carreiras.
Em quais atividades ele estará envolvido para alcançar esses objetivos? Muitas, mas aqui estão alguns exemplos comuns de onde ele vai gerenciar para cima, para os lados e para baixo.
Para cima, o EM estará envolvido e provavelmente será responsável por conduzir a estratégia do seu time. Ele vai colaborar com a liderança da empresa e de engenharia para estabelecer roadmaps de alto nível e a estratégia técnica do time.
No seu nível, EMs vão colaborar com Product Managers e Designers para estabelecer planos do time, e com seus pares e engenheiros de outros times. Essa colaboração frequentemente será em torno da entrega de projetos, com times precisando de apoio para alcançar seus objetivos.
Para baixo, EMs vão trabalhar com seus liderados. Isso será na execução do dia a dia, planejamento de projetos, code reviews, suporte operacional e possivelmente programação. E também na definição de objetivos de longo prazo para os indivíduos, ajudando-os a crescer em suas carreiras.
O Caminho Não Técnico
A maioria das atividades acima são de alto nível, e alguém poderia argumentar que ser técnico não é essencial para elas. Afinal, a maioria das melhorias está no sistema. Se um gestor consegue coordenar bem o time, por que ser técnico importa?
A resposta é que o sistema é técnico, e embora a coordenação seja possível sem um entendimento profundo, conhecer o trabalho, que é engenharia de software, provavelmente levará a melhores resultados. Vamos olhar alguns exemplos.
Roadmap e Planejamento de Projetos — Uma atividade comum para EMs é ajudar com o planejamento de projetos e roadmap. Esse planejamento pode fazer parte da definição de metas, como quais projetos vamos entregar no próximo trimestre, ou na definição do escopo de complexidade do trabalho e na estimativa de quanto tempo uma solução levaria para ser entregue.
Embora os engenheiros devam ser responsáveis por estimar o trabalho, ter um melhor entendimento técnico da ownership técnica do time permite que o EM tanto forneça estimativas rápidas quanto ajude a validar as premissas dos engenheiros ao estimar.
Por exemplo, em uma situação passada, um dos meus times foi solicitado a estimar um projeto para que pudéssemos considerar se valia a pena implementá-lo ou não. Um engenheiro assumiu a tarefa e voltou com uma estimativa significativamente diferente do que eu teria imaginado. Esse foi o gatilho para iniciar uma conversa onde descobrimos que algumas das premissas dele estavam erradas. Um EM não técnico poderia ter aceitado a estimativa, repassando-a e levando a uma decisão de negócio equivocada.
Estratégia Técnica — Outra atividade importante para times de software é ser capaz de definir uma estratégia técnica. Sem ela, um time pode facilmente cair no padrão de feature factory, entregando continuamente funcionalidades de produto sem considerar melhorias técnicas para reduzir débito técnico ou melhorar a capacidade do time de entregar de forma eficaz.
Esta é outra área onde os engenheiros devem estar envolvidos e liderar o pensamento sobre o caminho a seguir. No entanto, abordar isso inteiramente de uma perspectiva bottom-up levará a resultados subótimos. Primeiro, um time tem muitos engenheiros. Sem uma voz orientadora, a estratégia pode se tornar uma colcha de retalhos de ideias que não se alinham ou se complementam. Além disso, estratégias técnicas não existem isoladamente, e ter uma visão mais ampla dos objetivos organizacionais e de produto ajudará a criar um plano que se alinhe com metas de longo prazo.
Um EM não técnico terá uma visão limitada dos desafios arquiteturais e das decisões discutidas dentro do time e da empresa, assim como das oportunidades de melhoria técnica que complementam o pensamento de produto do time.
Suporte Operacional — Um time de engenharia de software geralmente tem responsabilidades operacionais, dando suporte ao seu produto em produção e à sua infraestrutura em algum nível. Esse suporte provavelmente significa que os engenheiros de software participarão de uma rotação de plantão (on-call) e atenderão a problemas operacionais e incidentes, fazendo debug e colaborando na resolução deles. Um EM não técnico não será capaz de participar e contribuir nessas atividades.
Será difícil para um gestor não técnico entender e ter uma visão prática desse trabalho. Sem isso, EMs têm dificuldade em melhorá-lo, com o risco de isso se tornar um ponto cego para eles. Como qualquer pessoa que já deu suporte a software em produção provavelmente pode dizer, não há outra forma de vivenciar a resolução de um incidente além de realmente resolver um incidente. Isso também torna difícil para os gestores apoiarem os engenheiros de forma eficaz durante situações críticas, que são de alto estresse e onde o apoio pode ser crucial.
Além disso, rotações de plantão e gerenciamento de incidentes são provavelmente as atividades mais incômodas em que um engenheiro precisa se envolver. Estar disponível 24 horas por dia e responder a chamadas em horários inconvenientes não é a melhor parte do trabalho. Ter um EM que não participa delas em nenhum nível pode corroer a confiança com os engenheiros do time. Não é o melhor padrão de liderança pedir às pessoas que você gerencia para fazerem algo que você não está disposto a fazer.
Coaching e Apoio ao Time — Uma parte fundamental de ser um EM é fornecer coaching e caminhos de crescimento para os engenheiros sob sua liderança. Isso pode tomar diferentes formas. Eles podem dar feedback sobre trabalho técnico, tanto código quanto documentos de design. Podem também apoiar o trabalho de um engenheiro em um ambiente com ideias e opiniões divergentes. Por fim, podem fornecer um caminho de crescimento técnico para que os engenheiros alcancem o próximo nível de carreira.
Um EM não técnico terá uma perspectiva e capacidade limitadas para ajudar em todas essas situações. Embora existam alternativas possíveis, como uma configuração de mentoria com outro engenheiro, essas precisarão incluir uma terceira pessoa no esforço, provavelmente levando a resultados menos diretos e eficazes.
Por exemplo, em um time passado, um engenheiro me deu feedback sobre outra pessoa, alegando que as revisões de Pull Request (PR) dessa pessoa não estavam agregando valor e estavam dificultando seu trabalho. Nesse caso, pedi exemplos de revisões de PR e, depois de analisá-los, considerando que eram apropriados, ajudei a orientar o engenheiro sobre como reagir a eles. Se eu não pudesse fazer essa avaliação por conta própria, teria que pedir a uma terceira parte, transformando isso em uma situação mais complexa, possivelmente navegando quatro pessoas com opiniões diferentes.
Em todas essas situações, EMs não precisam ser os especialistas técnicos dentro do time, e devem delegar essas atividades aos engenheiros. No entanto, ter contexto técnico e um entendimento profundo da tecnologia de responsabilidade do time levará a decisões mais eficazes.
Qual é o Nível Técnico Suficiente?
Se ser técnico é necessário, quão técnico é técnico o suficiente? EMs deveriam estar entregando código regularmente?
Isso certamente depende da situação. O objetivo principal do EM é viabilizar um time eficaz, o que é o mesmo dentro de um contexto técnico. Escrever código regularmente pode ser a melhor alternativa, dependendo do time, embora certamente não seja o caso mais comum na minha experiência.
Uma boa regra prática é o tamanho do time. Em times pequenos, é mais frequente o caso em que o gestor pode contribuir regularmente e ainda ser um líder de time eficaz. Essa contribuição pode acontecer com ele exercendo um papel de tech lead ou até mesmo atuando como contribuidor.
No entanto, quando os times crescem, a alavancagem do EM geralmente muda de entrega para viabilizar a entrega com atividades de nível mais alto. Com mais liderados, também é mais difícil para EMs terem tempo de foco, frequentemente se tornando um gargalo se tentarem continuar contribuindo.
Em resumo, embora EMs devam manter o contexto técnico para fornecer suporte em diferentes situações, eles devem sempre se perguntar qual é a atividade de maior alavancagem que podem fazer. E isso frequentemente não é entregar código.
Ser técnico não é tudo, mas é parte do todo
Embora este artigo foque nos aspectos técnicos do papel do EM, esperamos que ainda esteja claro que ter contexto técnico não é suficiente para um gestor. Liderar um time de engenharia é um papel multifacetado que torna o time eficaz enquanto cria um ambiente estável para seus membros.
Mas ser técnico é vantajoso em múltiplas situações, e EMs devem investir em tornar isso mais uma ferramenta em seu arsenal.
Esse post faz parte de uma série sobre Liderando Times de Software com Pensamento Sistêmico.