Autonomia vs. Determinação externa

Foto de Sohrab Salimi
Sohrab Salimi
5 Min. Tempo de Leitura
Este conteúdo foi traduzido com IA. Ver original

Praticamente todas as grandes empresas de tecnologia já embarcaram no movimento de equipes de produto autônomas, engajadas/consistentes, multifuncionais e colaborativas – e acredito que isso seja positivo. Raramente vemos empresas usando os modelos antigos (principalmente o modelo de pool). No entanto, ainda não é fácil encontrar o equilíbrio certo entre autonomia e controle externo.

Os resultados falam por si, mas atribuo a maioria das vantagens ao aumento da motivação e ao verdadeiro senso de propriedade que surge quando as equipes sentem que podem decidir sobre seu próprio trabalho.

Porém, mesmo quando os líderes de equipe me dizem que suas equipes são autônomas e independentes, muitos membros da equipe veem as coisas de forma diferente. Quando isso acontece, tento descobrir exatamente o que a equipe não consegue decidir sozinha ou onde se sente limitada.

Onde está a linha entre autonomia e controle externo?

Na maioria das vezes, isso se resume a uma das duas respostas:

Ou a equipe ainda não conquistou totalmente a confiança da gestão e, por isso, a gestão não quer dar liberdade total aos membros da equipe.

Ou a equipe quer mudar algo que a gestão considera parte das bases fundamentais.

Basicamente, todas as equipes concordariam que existem algumas coisas que podem decidir livremente, assim como outras áreas que fazem parte dos pré-requisitos comuns a todas as equipes.

Um exemplo

Neste último caso, seria muito incomum se cada equipe escolhesse sua própria ferramenta de versionamento. Se a equipe de desenvolvimento definiu o GitHub como padrão, isso normalmente é considerado parte das bases fundamentais. Mesmo que uma equipe tenha forte preferência por outra ferramenta, os custos superariam em muito os benefícios para a empresa.

Este exemplo é bem claro, mas existem muitos outros onde isso não é tão óbvio.

Cada equipe deveria poder abordar a automação de testes à sua maneira? As equipes deveriam escolher individualmente a linguagem de programação? E o framework de interface do usuário? E a compatibilidade com navegadores? E recursos caros como "suporte offline"? Deveriam decidir o quão "ágeis" querem trabalhar? E toda equipe realmente precisa estar envolvida em várias iniciativas de produto da empresa?

Como frequentemente acontece com produtos, no final tudo se resume a um compromisso – neste caso, um compromisso entre autonomia e cumprimento das bases estabelecidas.

Embora eu apoie fortemente o princípio de equipes autônomas e independentes, confesso que também sou um grande fã de investir em boas bases. Com uma base sólida e compartilhada, as equipes conseguem criar produtos e experiências incríveis muito mais rapidamente.

Quero explicar esse compromisso com mais detalhes. Mas também quero enfatizar que não estou dizendo que existe apenas uma resposta para essa questão – pode ser diferente para cada empresa e equipe. Tudo depende de vários fatores que vou explicar aqui:

Pontos a considerar:

– A competência da equipe:

De modo geral, existem três situações diferentes:

Equipe A – uma equipe experiente com pessoas inteligentes e criativas, em quem você pode confiar plenamente para tomar boas decisões.

Equipe B – essas pessoas têm boas intenções, mas em muitos casos ainda não têm a experiência necessária para tomar boas decisões, por isso precisam de algum apoio.

Equipe C – uma equipe júnior que talvez nem saiba o que não sabe. Sem acompanhamento intensivo, essas equipes podem causar grandes problemas sem querer.

– Velocidade:

Um dos principais argumentos para diretrizes fixas é a velocidade. A lógica é que as equipes deveriam poder construir sobre o trabalho dos colegas, para não perder tempo reinventando a roda. No entanto, em alguns casos é aceito e comum permitir que as equipes trabalhem um pouco mais devagar e eventualmente façam algo em duplicado, se isso promover a autonomia. Às vezes, porém, é essencial para o negócio que as diretrizes sejam seguidas.

– Importância da integração:

Em algumas empresas, o portfólio consiste em produtos relacionados mas majoritariamente independentes, onde integração e diretrizes não são muito importantes. Em outras empresas, o portfólio envolve produtos altamente integrados, onde certas diretrizes gerais são indispensáveis. No final, depende se a equipe deve focar em uma solução única específica ou encontrar uma solução ótima considerando toda a empresa.

– Fonte de inovação:

Se as principais fontes de inovação futura já estão nas bases, as equipes deveriam ter mais liberdade para repensar esses elementos fundamentais. Se as origens da inovação estão no nível das soluções, a equipe deveria focar menos nas bases e mais em inovações criativas no nível da aplicação.

– Tamanho e localização da empresa:

A autonomia frequentemente se torna difícil quando surgem problemas de escalabilidade. Quando as empresas crescem e suas equipes estão distribuídas em diferentes locais, estabelecer certas diretrizes básicas se torna mais difícil, mas também mais importante. Algumas empresas tentam resolver isso com o conceito de "Centro de Excelência", reunindo uma equipe que trabalha em conjunto em uma tarefa específica em um local determinado. Outras tentam com papéis mais holísticos. E outras ainda adicionam processos.

– Cultura organizacional:

A relação entre autonomia e controle externo também desempenha um papel importante na cultura da equipe. Quanto mais diretrizes a empresa estabelece, mais as equipes sentem que sua autonomia está sendo limitada. Para equipes B e C isso ainda pode ser aceitável, mas para equipes A já é mais problemático.

– Maturidade da tecnologia:

Querer estabelecer uma base uniforme para todos cedo demais é um problema comum. Se a base ainda não está madura, ela não pode oferecer o suporte para o qual foi pensada. Pressionar demais pela implementação de diretrizes antes que as bases estejam realmente prontas pode prejudicar seriamente as equipes que dependem delas. É como tentar construir algo sobre um castelo de cartas instável.

– Importância para o negócio:

Partindo do pressuposto de que a base é sólida, existem mais riscos com uma equipe que não utiliza essas bases. Em alguns casos, isso pode não ser grave. Mas quando se trata de produtos ou iniciativas cruciais para o negócio, é preciso pensar bem no que focar.

– Grau de responsabilidade:

Outro fator é o grau de responsabilidade que acompanha a autodeterminação e independência. Se as equipes não têm responsabilidade própria – especialmente se não há equipes A fortes – elas também não têm motivo real para dar atenção especial a esse compromisso. Mas você quer que as equipes pensem sobre esse compromisso. Se sei que a equipe é forte e está totalmente ciente dos riscos e consequências e mesmo assim quer ignorar ou substituir um componente essencial das bases, então apoio os membros da equipe nessa decisão.

Resumo

Como você pode ver, há muitos pontos a considerar. Na minha opinião, porém, a maioria das equipes é muito razoável quando esses temas são abordados abertamente. Às vezes, algumas perguntas básicas sobre os impactos já ajudam a equipe a tomar melhores decisões em relação a esse compromisso.

No entanto, se as equipes constantemente tomam más decisões a esse respeito, você deveria repensar o nível de experiência da equipe e talvez investir mais tempo para garantir que os membros da equipe realmente entendam todos os contextos de negócio.

Este texto é do blog de Marty Cagan e foi traduzido por nós para o português.

Fale com nosso assistente Fale com nosso assistente