Ownership como Habilidade para Engineering Managers

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

Setting the direction Definindo a direção por MidJourney

Engineering Managers (EMs) trabalham em um ambiente complexo. Um time tem múltiplas iniciativas. Há diferentes opiniões, de pessoas acima, abaixo ou adjacentes na estrutura organizacional, sobre como enfrentar desafios técnicos, como o time deveria trabalhar e até no que as pessoas deveriam trabalhar. Em torno de tudo isso, há prazos e diferentes tipos de pressão interna e externa. Em resumo, é fácil se perder.

Essa complexidade cria um desafio real para EMs. Quando times têm uma performance ruim, muitas vezes o problema não está na qualidade dos indivíduos envolvidos ou mesmo no espaço do problema em que estão. Está centrado na falta de consistência. Podem faltar consistência em suas práticas, nunca realmente dominando-as. Podem faltar consistência em seu trabalho, executando um roadmap frágil. Ou pode faltar consistência em sua visão, tendo dúvidas constantes sobre seu caminho.

Nossa falta de confiança não é resultado da dificuldade. A dificuldade vem da nossa falta de confiança. — Sêneca

Independentemente do tipo, a inconsistência cria um time frágil, e em algum momento, um time frágil será atropelado pelo seu ambiente.

Distrações, distrações por toda parte

A realidade de um time de software moderno é multifacetada. A qualquer momento, múltiplos projetos estarão em andamento e haverá alguns em planejamento. Design docs para melhorias técnicas sugeridas circularão, e bugs e incidentes serão levantados regularmente.

Para ter sucesso em um mar de distrações, um time precisa ter uma perspectiva clara sobre no que vai trabalhar e como enfrentar esses desafios. Embora isso não precise ser prescritivo, como um roadmap detalhado ou design técnico, a direção precisa ser firme. Uma visão consistente do cliente permitirá ao time priorizar o importante do menos crítico. Uma visão constante da tecnologia permitirá que a dívida técnica seja tratada no longo prazo.

Manter uma direção é uma tarefa desafiadora, porém. Em meio a todas essas opções, haverá múltiplas opiniões. As pessoas terão diferentes perspectivas sobre como trabalhar, no que trabalhar e até quais aspectos do trabalho devem ou não ser melhorados.

Uma visão simplista desse problema diria que é apenas sobre separar boas de más ideias. Uma perspectiva mais realista é que a maioria das opiniões será valiosa. Uma pessoa pensa isso, a outra sente aquilo, e a terceira fez diferente em sua experiência passada. E todas podem estar corretas dentro de seus contextos.

A outra abordagem simplista é acreditar que um time pode evoluir através de uma abordagem passo a passo de melhoria contínua: basta medir os resultados e iterar. Isso pode funcionar nos livros. No entanto, na realidade, um time é uma teia de múltiplos sistemas que interagem entre si, e entender o resultado real de pequenas melhorias será muito mais fácil de falar do que de fazer.

Seguir o Fluxo como Estratégia (Ruim) de Liderança

Por causa da situação acima, um caminho fácil mas arriscado para um líder de engenharia é seguir o fluxo, ou em outras palavras, seguir o que outras pessoas dizem. O product manager provavelmente terá features ilimitadas para entregar, e cada membro do time terá perspectivas sobre possíveis melhorias. Há múltiplas formas de seguir esse caminho, mas o traço comum é acreditar que outra pessoa sempre sabe melhor.

E isso pode funcionar bem por um tempo. Se o time tem um roadmap empolgante, focar exclusivamente em entregá-lo levará a um impacto positivo. Se a organização está indo bem o suficiente, a maioria das ineficiências do time fica escondida na maré que levanta todos os barcos. Como já disseram, “Toda teoria de gestão funciona em um ambiente de crescimento.”

No entanto, isso também se desfaz eventualmente. Manter um time bem-sucedido no longo prazo significa que o time enfrentará desafios. O ambiente de negócios pode mudar, levando a mudanças no roadmap. A dívida técnica continuará se acumulando, levando a uma desaceleração na produtividade. Ou membros do time podem sair, levando a uma disrupção na capacidade.

Nesse ambiente, as ineficiências se tornarão aparentes. Opiniões divergentes levarão à confusão, a falta de um plano levará a baixo impacto, e é quando você pode ver times andando de lado, retrocedendo no caminho da produtividade.

Struggling teams go in the wrong direction Times com dificuldades vão na direção errada no caminho da excelência (imagem original de Will Larson)

É aqui que vejo times com dificuldades frequentemente. Não são times com pessoas menos competentes ou técnicas. São times que não têm alinhamento, que não têm uma visão clara de sua missão e roadmap, ou que não concordam sobre como trabalhar de forma eficaz. O resultado são times que não estão obviamente falhando, mas também não estão sendo muito bem-sucedidos.

Ownership como Ferramenta

O objetivo de um Engineering Manager (EM) é criar um time eficaz. Embora tenham pares com quem trabalham em Produto, Design e outras disciplinas, eles também gerenciam a maioria das pessoas em um time de engenharia. O sucesso do time é o sucesso do EM.

Por isso, ajudar o time a se alinhar em um caminho adiante é responsabilidade do EM. Isso não significa que precisam ter todas as ideias ou tomar todas as decisões. Mas precisam ter plena confiança na direção do time e agir caso isso não esteja acontecendo.

Outros membros do time têm ótimas perspectivas e ideias. Com certeza têm, e faz parte do papel do EM entender essas perspectivas e criar espaço para que sejam compartilhadas. No entanto, o que eles não têm é uma visão de alto nível do time ou a accountability pelos resultados. Por outro lado, a liderança acima do time tem uma perspectiva ampla, mas não tem uma visão próxima da realidade do dia a dia. Por isso, o EM precisa ser um líder, assumindo ownership do problema e da solução que entregará os resultados esperados.

Nem todos os membros do time identificarão os mesmos problemas críticos, nem pensarão nas mesmas soluções, mesmo que o fizessem. Algumas soluções resultarão em mais problemas críticos.

Dessa cacofonia intelectual, o líder precisa fazer o trabalho de comparar e contrastar conceitos, integrar propostas, responder e fazer perguntas, corrigir mal-entendidos, dar o devido reconhecimento, sequenciar inputs e, finalmente, produzir um plano de ação para atingir o propósito.

Systems Leadership: Creating Positive Organizations

Na prática, isso significa que o EM precisa fornecer direção, mantendo um ambiente estável para o time. Deve fazer isso dentro de produto, trabalhando de perto com product managers e pares de design para decidir o que fazer e comunicar ao time. Deve fazer isso dentro de engenharia, liderando engenheiros e o time em um caminho técnico de longo prazo. E deve fazer isso com processos, definindo práticas eficazes para o contexto do time.

Isso é especialmente importante quando times tentam melhorar ou mudar de direção em um ambiente fluido. Em qualquer processo de mudança, as coisas tendem a piorar antes de melhorar, e os resultados não serão alcançados a menos que a consistência seja mantida por tempo suficiente.

Direção, não Ditadura

No entanto, fornecer direção não significa dizer a todos o que fazer ou não criar um ambiente seguro e inclusivo para que as pessoas deem suas opiniões. Significa alinhar o time em direção a um objetivo e ajudar todos a executarem dentro dele. Uma abordagem bem-sucedida significa incorporar todas as perspectivas, fazer as pessoas se sentirem ouvidas e alinhar todos juntos em um caminho adiante.

Abaixo estão alguns aspectos práticos para ter em mente ao tentar liderar um time ativamente.

Entenda o contexto: todo time trabalha dentro de um ambiente. A empresa terá sua cultura, a organização terá uma estratégia, e as pessoas ao redor do time (tanto acima quanto abaixo) terão diferentes perspectivas. Para que qualquer abordagem seja bem-sucedida, ela precisa respeitar e agir dentro desse contexto, não ignorá-lo.

Entenda sua autoridade: um EM tem autoridade sobre um time, mas essa autoridade não é ilimitada. Há pares em diferentes disciplinas, como product managers e designers. Há pessoas acima na estrutura organizacional que também têm perspectivas. Há membros do time que precisam ser ouvidos. EMs devem entender seu círculo de influência ao agir e escalar quando mudanças são necessárias em áreas fora de seu alcance.

Itere em direção a um resultado: Ninguém está sempre certo, e mesmo quando um EM propõe alternativas, algumas podem não ser aceitas ou precisar de refinamento. Embora possa ser mais simples desistir, receber feedback, refinar a perspectiva e iterar em direção a um resultado bem-sucedido levará a um resultado melhor.

Use princípios, não práticas: Para se adaptar melhor a contextos existentes, EMs devem considerar princípios mais do que práticas. Por exemplo, falar sobre como ciclos curtos de feedback são importantes é mais fácil do que impor pair programming em um time. O antipadrão familiar aqui é a aplicação de Scrum ao pé da letra, que lenta (mas certamente) criou uma aversão a metodologias ágeis dentro da indústria.

Ouça, discuta e adapte-se ao contexto: embora EMs tenham autoridade, devem buscar usá-la com parcimônia. Discuta problemas com o time, ouça diferentes perspectivas e construa alinhamento antes de tomar ação.

Assuma ownership: em um ambiente complexo, é fácil esperar que outra pessoa (a liderança, o gestor, etc.) venha resolver os problemas em questão. EMs devem sentir ownership da direção do time, propondo ativamente alternativas até que o alinhamento seja alcançado.

Continue refinando seus princípios: conforme continuam trabalhando com times, vivenciando diferentes situações e vendo o resultado das ações, EMs devem continuar refinando seus princípios sobre como times eficazes devem trabalhar. Essa perspectiva será sua força no longo prazo, permitindo-lhes agir com mais confiança no futuro.

Liderar um time significa garantir que o time tenha sucesso em seu contexto. EMs devem se sentir empoderados e responsáveis por isso, ajudando o time a encontrar o melhor mesmo em situações complexas. Embora isso possa às vezes parecer avassalador, vai garantir uma perspectiva melhor e de longo prazo para o time e seus membros.

Gostou deste post? Escrevo sobre liderança em times de engenharia de software. Assine para ficar por dentro.