6 minutos de leitura

Se você já ocupou uma posição de liderança em produto ou tecnologia, provavelmente sentiu na pele a montanha-russa que é gerenciar uma equipe em crescimento exponencial e ter que se adaptar a cenários que não previstos.

Neste contexto extremamente dinâmico, surge uma pergunta essencial: quando é o momento certo para reestruturar os times de produto? Essa decisão não pode ser tomada levianamente, porque influencia diretamente na eficiência que seu time vai ser capaz de exercer.

Fazer software é uma atividade altamente “path dependent”. As decisões tomadas no começo referentes ao produto e tecnologia não só influenciam, como também limitam as decisões disponíveis no futuro. Um pequeno desvio no começo, pode causar um grande problema lá na frente.

Por isso, é nosso papel buscar sinais de que está na hora de mudar de rota e reorganizar a maneira como nossos times de produto e tecnologia estão estruturados. Quais são esses sinais?

Decisões estruturais de baixa qualidade

A Lei de Conway é um princípio que afirma que a estrutura de uma organização afeta diretamente na arquitetura do sistema que ela produz. Em outras palavras, a maneira como as equipes estão organizadas e se comunicam influencia em como um sistema é arquitetado, construído e entregue.

VEJA TAMBÉM: Checklist – sinais de uma squad de alta performance

Muitas vezes, quando a Lei de Conway é citada, as pessoas pensam apenas em arquitetura de software. Mas ela não se resume a isso. A forma como seu time está estruturado pode também influenciar na estrutura da sua estratégia de produto, por exemplo. A Lei de Conway se aplica a Sistemas Complexos como um todo.

No contexto de equipes que criam software, quando a Lei de Conway não é levada em consideração ou é mal interpretada pelo líder, a consequência pode ser um sistema que tem como arquitetura algo inadequado para o caso de uso da empresa.

Ou seja: um sinal que aponta o momento ideal para reestruturar seu time é quando a arquitetura produzida pela organização não corresponde mais ao que é necessário para empresa e para o software sendo construído.

Vejo muita conexão entre a Lei de Conway e a popularização do modelo organizacional Spotify. Para combater estruturas monolíticas de alta interdependência e, com a democratização de arquiteturas de micro-serviço, as empresas começaram a adotar o uso de times menores e multi-disciplinares, com missão e accountability claros alinhados a um propósito em comum.

Quando uma empresa quer mudar a estrutura de um sistema, uma estratégia viável é reorganizar como os times de produto estão estruturados para que eles espelhem a arquitetura desejável. O nome desse tipo de estratégia é chamado de Inverse Conway Maneuver na literatura.

Mas existem alguns riscos ao aplicar essa estratégia:

• O primeiro é a clássica gestão da mudança. Existe um período de transição em que o time estará trabalhando em um novo formato, mas com uma arquitetura antiga que deve ser adaptada para a nova.
• E também: não basta reorganizar times de tecnologia com base no sistema que queremos criar. Uma coisa é o sistema, outra é a interpretação do sistema pelas pessoas que executam. Para executar corretamente a manobra, deve-se olhar para ambos e garantir alinhamento entre eles.

Como falei, muitas vezes a Lei de Conway é associada apenas à arquitetura de software. Porém, ela pode ser aplicada a todo tipo de sistema (não apenas sistemas técnicos). A estratégia de produto, por exemplo, deve ser vista como um sistema que também é influenciado pela Lei de Conway. Ou seja, a organização do time também influência em como a estratégia é executada e interpretada.

É também possível que essa manobra não funcione. Isso acontece porque, como mencionado no começo, fazer software é path dependent. Não só isso, é algo extremamente interconectado. Uma mudança em uma parte do sistema causa mudanças indesejadas em outra. Portanto, é necessário endereçarmos não apenas a organização do time mas o sistema em si de forma mais proativa. Não espere que um automaticamente corrija o outro!

Nesse artigo, Mathias Verraes traz uma visão interessante sobre como a Lei de Conway e, por consequência, o Inverse Conway Maneuver não se aplicam a sistemas rígidos e pouco flexíveis. Nesses casos, ele aconselha primeiro mudar o sistema, depois a organização.

Carga cognitiva excessiva

É importante falar um pouco sobre a Teoria da Carga Cognitiva e entender como ela nos impacta como indivíduos antes de nos aprofundarmos em como ela pode impactar os times que gerenciamos e, claro, se precisamos de uma reestruturação.

A teoria, criada por John Sweller em 88, usa como base a forma como seres humanos processam informação.

A todo momento, somos impactados por informações que precisam ser interpretadas e filtradas – nossa memória sensorial que faz isso. O papel dela é fazer uma curadoria do que realmente é relevante para o contexto, assim como jogar fora o que não é.

Das informações que passam, elas são armazenadas na memória de trabalho. Esse tipo de memória tem uma capacidade limitada de 5 a 9 itens sendo processados simultaneamente.

Nossos cérebros armazenam as informações mais relevantes e codificam elas em “schemas” (ou categorias) na memória de longo prazo para que seja mais fácil acessá-las futuramente.

Conforme retornamos informações da memória de longo prazo e as reutilizamos na memória de trabalho, mais fixadas elas se tornam e passamos a nos lembrar delas com mais eficiência.

Mas o que é Carga Cognitiva?

Carga Cognitiva, segundo o psicólogo John Sweller, pode ser definida como a quantidade total de esforço sendo usado na memória de trabalho. Ele prega que os seres humanos possuem um limite de armazenamento na memória de trabalho e que, quando ultrapassado esse limite, atividades que envolvem processamento de informação (como aprender e trabalhar) se tornam cada vez mais ineficientes.

Por que estou falando tudo isso?

Pois, assim como todos nós, times de produto também possuem capacidade limitada de administrar e processar grandes quantidade de informações simultâneas.

Conforme o time cresce e se torna bem-sucedido, a quantidade de outputs gerados se acumula, o que faz crescer também a demanda por manutenção desses outputs. Além disso, o time passa a acumular novas responsabilidades, o que aumenta (ainda mais) a quantidade de informações que precisam ser administradas.

Aos poucos, a quantidade de informações sendo processadas ultrapassa o limite de carga cognitiva do time, impactando em motivação e performance.

Quando o time começa a reportar sobrecarga e insatisfação, é importante analisarmos de perto se a carga cognitiva do time não foi ultrapassada. Se sim, talvez seja o momento de uma reestruturação para que se tenham responsabilidades mais limitadas e mais claras.

No livro Team Topologies, os autores dão boas dicas do que fazer para reduzir o impacto de times de produto com alta carga cognitiva:

1. Identifique quais são todos os domínios (ou áreas de foco) de um sistema. Aqui é importante levar em consideração o sistema desejável para que, lá na frente, a Lei de Conway não te leve a caminhos errados.
2. Você pode classificar os domínios entre simples (maioria dos problemas possuem uma solução clara), complicados (solução é menos clara e requer mais experimentação) e complexos (o problema precisa ser melhor estudado).
3. Atribua cada time a um domínio específico, levando em consideração que, se um domínio for complexo/complicado demais, o ideal é quebrar o domínio em subdomínios antes de quebrar o time para cuidar do mesmo (vide Lei de Conway).

Idealmente, um time deve ser composto por até 8 pessoas. Essa rule of thumb foi derivada de um estudo feito pelo antropólogo Robin Dunbar que identificou que um ser humano consegue manter relações de alta confiança com 5 a 8 indivíduos.

Portanto, considerando que o tamanho ideal de um time é de 5 a 8 pessoas, eles aconselham que:

• Um único time seja responsável por até 3 domínios simples;
• Um único time administra apenas 1 domínio complexo ou complicado.

Outros sinais

Existem também outros sinais que podem indicar que é o momento de reestruturar seu time. Porém, muitas vezes existem soluções mais simples do que uma reestruturação completa da organização. Alguns exemplos são:

• Mudança estrutural na estratégia de Produto ou Negócios;
• Redução ou aumento do time;
• Time não sabe pelo que é cobrado e qual sua responsabilidade no sistema como um todo;
• Comunicação é truncada. As pessoas têm dificuldade em saber com quem e onde se comunicar para resolver um problema;
• Estagnação e baixa performance;
• Reestruturações incrementais do passado não resolveram o problema por completo;
• Insatisfação do time com seu trabalho e da empresa com o time.

A verdade é que todos já passaram ou vão passar por uma reestruturação de times de tecnologia. Faz parte do nosso papel, como líderes, entender quais sinais buscar e qual é a maneira correta de fazer essa estruturação.

Espero que esse artigo tenha dado um pouco de luz ao tema. Mas, qualquer dúvida ou complemento, pode me chamar em joao@bossabox.com.