Ao longo da minha carreira, interagi com inúmeros times de desenvolvimento, e a diferença entre equipes de baixa, média e alta performance e maturidade é notável. Curiosamente, os times de maior sucesso nem sempre eram formados por uma maioria de seniores. Pelo contrário, o que realmente os diferenciava era uma distribuição equilibrada de senioridade, alta integração, familiaridade, confiança mútua, autonomia e um compromisso inabalável com as entregas.

Já os times com performance mais baixa frequentemente tropeçavam em armadilhas que, à primeira vista, podem não parecer óbvias. Vou explorar as mais comuns.

Decisões Estratégicas Equivocadas na Formação de Times

Um erro estratégico comum na formação de times é adotar modelos como a pirâmide invertida de senioridade ou o “flat team”.

Um flat team é aquele composto majoritariamente por profissionais de senioridade baixa. Isso geralmente acontece por limitações financeiras. É importante notar que “júnior” aqui não tem a ver com tempo de casa ou carreira; há pessoas com 20 anos de experiência estagnadas, sem evolução em hard ou soft skills. Times com muitos juniores e plenos tendem a ter pouca profundidade técnica e carência de skills de liderança e gestão para resolver problemas mais complexos, sejam técnicos ou de tomada de decisão estratégica. Convenhamos, é raro encontrar um “Júnior Pro Max” – alguém fora da curva. Como o adjetivo já diz, ele é uma exceção.

Por outro lado, o time com pirâmide invertida é formado principalmente por seniores e poucos outros perfis. Geralmente, a justificativa inicial para essa estrutura parece lógica e, muitas vezes, é uma medida desesperada para resolver um problema ou indica pouca expertise em gestão de times. Essa composição apresenta vários problemas, sendo os atritos os mais comuns. Esses atritos podem surgir por problemas de ego, discussões sobre “quem é o melhor”, “quem tem a melhor solução” ou até mesmo “quem chama mais atenção”. Também há casos de resistência em realizar atividades mais operacionais e de baixo valor intelectual, entre outros. Mais explicações para isso poderiam ser tema de outro artigo.

A Mão Pesada da Governança Organizacional

A concentração excessiva de “governança organizacional” muitas vezes deixa de ser por segurança e passa a indicar falta de confiança nas pessoas, resultando em controle individual excessivo e na necessidade constante de justificar cada passo. É como se a mensagem fosse: “Você não entende desse assunto, não sabe fazer e não tem responsabilidade, ou é tratado como uma criança que precisa de supervisão constante, pegando na mão para caminhar.”

Esse baixo nível de autonomia implica uma grande necessidade de pedidos de aprovações internas e externas. Esse modelo, justificado pela “segurança”, exige múltiplos aprovadores que, muitas vezes, não têm compromisso real com a entrega final. Nesse cenário, gasta-se mais tempo justificando, coordenando e pedindo autorizações do que entregando software. Engenharia de software é uma profissão criativa, e ambientes com muitos controles e passo a passos fixos tendem a sufocar a inovação.

Nesse contexto, podem acontecer três cenários: os melhores talentos buscam oportunidades em outros lugares, são expulsos por não se adequarem à rigidez do sistema, ou abrem mão da inovação e são achatados para o formato desenhado, que geralmente é muito menor do que o que eles teriam para contribuir.

Times de alta performance prosperam em ambientes com segurança psicológica, onde têm autonomia para tomar decisões e autoridade para implementá-las, o que resulta em um fluxo mais rápido e maior qualidade. – Gene Kim em “Accelerate: The Science of Lean Software and DevOps”

Estruturação e Disposição dos Times

A estruturação e disposição dos times impactam diretamente a velocidade das entregas, resultando em um impacto negativo na produtividade. É aqui que empresas mais tradicionais mais sofrem durante processos de digitalização, modernização ou desenvolvimento de novos produtos. Em 1957, Conway já identificava que o modelo de comunicação organizacional afeta diretamente a arquitetura de sistemas. Uma má distribuição e organização de times implica na multiplicação de custos operacionais, com repetições de trabalho (a mesma necessidade sendo resolvida por equipes diferentes), custos de infraestrutura e a complexa necessidade de orquestração sobre quem faz deploy primeiro, e assim por diante.

Não é raro encontrar cenários onde vários times diferentes alteram o mesmo serviço, muitas vezes de forma simultânea. Ou, durante um período de modernização, o projeto antigo não é “congelado” e continua em constante evolução/correção, enquanto outro time trabalha em um novo épico ou na “modernização” do mesmo projeto. Um projeto com branches diferentes evoluindo concomitantemente para direções distintas é um pré-anúncio do caos. Quanto mais o tempo se alonga, maiores as chances de tempo e trabalho serem desperdiçados, pois, no final, alguém precisará decidir se refaz uma das branches (geralmente aquela que não foi alterada por ele) ou se integra pedaços de código na branch com mais alterações.

O atrito entre as equipes e os atrasos na entrega de software são geralmente sintomas de uma estrutura de equipe deficiente. (Teams Topology)

Para mitigar esses problemas, organizar a formação dos times com base em propósito e modo de interação, seguindo o modelo de Team Topologies, é estratégico. E a disposição dos times isolando-os em Bounded Contexts e aplicando Domain-Driven Design (DDD) são bons direcionadores para justificar e dar propósito à existência de cada time.

Mudanças Constantes no Time

Mudanças frequentes na composição do time, seja por alto turnover, necessidade emergencial de adicionar alguém para acelerar uma entrega/correção, ou “empréstimos” para outros times (desfalque), são prejudiciais. Segundo a Lei de Tuckman, toda vez que a composição de um time é alterada, ele tende a regredir para um estágio anterior, geralmente para Storming ou Norming, distanciando-se do estágio de alta performance.

Busca por Métricas Sem Foco em Comportamento

Buscar métricas sem fomentar a criação de capacidade e a mudança de comportamentos é outro problema comum. Métricas bem elaboradas são como fotografias da situação atual. A melhor forma de melhorá-las e atingi-las é descobrir que tipo de comportamento as pessoas (ou nós mesmos) precisam adquirir para mover esses ponteiros.

Pense na metáfora de perder peso: não adianta olhar a balança todo dia. Em um processo de desenvolvimento, assim como se perde gordura e se ganha massa magra, as melhorias podem não ser lineares e imediatas. Por um tempo, pode parecer que não está “melhorando”, e ao confrontar os números, recebem-se falsos negativos.

Por outro lado, forçar o atingimento de métricas pode gerar falsos positivos: parece que a cobertura de teste aumentou, mas a qualidade em si, que é o esperado, não melhorou. A pressa vai forçar os times a “encontrar” caminhos para mascarar o resultado, seja ignorando classes ou chamando pedaços de código sem realmente avaliar as saídas. Ao buscar resultados artificiais, você está gerando um problema futuro para a organização. Princípios como coragem e transparência, que o XP “prega”, são extremamente importantes aqui, além de habilidades modernas de gestão para entregar valores reais, em vez de meramente mentir com estatísticas.

Criar Atividades ou Resolver Problemas Inexistentes

É muito comum que times com grande conhecimento teórico, mas pouca maturidade, e com a boa intenção de “antecipar problemas”, acabem aumentando a complexidade desnecessariamente. Eles usam boa parte do tempo imaginando problemas que não terão, antes mesmo de começar a resolver uma questão real. Projetar e solucionar problemas que estão apenas na imaginação é uma prática eficaz para criar complexidade “acidental”.

A complexidade acidental é um dos três tipos de complexidade, e é gerada pela “preferência” do arquiteto ou do desenvolvedor. Ela se manifesta em decisões que não resolvem nenhum problema que o negócio realmente precisa, sendo muitas vezes um capricho para aplicar algo novo que se aprendeu ou usar um framework da moda.

É o velho dilema: “Vou iniciar um projeto seguindo as melhores práticas, com arquitetura em microsserviços, um cache distribuído, um Kafka para assincronicidade, service mesh, etc… e tudo isso para um projeto que está apenas nascendo, tem só um cliente e uma demanda projetada de 200 chamadas por mês.”

Muitas vezes, em um projeto do zero, entender o problema real e aplicar uma técnica de Lean Inception para saber o que faz sentido, por onde começar e o que não vai entrar na solução ajuda a direcionar as decisões. Em um refinamento, todos sabem o que é importante, mas poucos sabem priorizar. Além da habilidade de priorizar, também há a necessidade, em conjunto com outras skills, de saber negociar e vender. Só aqui, são três soft skills importantes de liderança que alguém realmente sênior tem.

Há casos em que ferramentas modernas chegam, mas as práticas ainda são de modelos de pensamentos antigos. Por exemplo, exigir um schema de banco de dados para um banco de dados não estruturado (NoSQL) é um claro anti-padrão. Além de perder o benefício do schema-on-read, essa prática aumenta a complexidade desnecessariamente.

Falha no Compartilhamento de Conhecimento

O compartilhamento de conhecimento é um problema muito comum em várias organizações. Dentre vários tipos, o mais clássico ocorre quando pessoas com pouca maturidade acreditam que concentrar ou centralizar o conhecimento nelas é uma ferramenta de poder. Pensam que, ao ter um problema “com seu nome”, se tornarão indispensáveis para a organização. Na realidade, essa prática as transforma em um gargalo, inclusive dificultando suas mudanças de posição, promoções ou novos projetos.

A falta de gestão de conhecimento pode apontar para uma baixa qualidade do produto e do processo, falta de técnicas de team building, documentação pobre e baixa qualidade da solução ou do código. De fato, não há benefício nenhum em ser chamado numa madrugada de sábado porque só você conhece como o sistema funciona.

No ambiente atual, acumular conhecimento acaba erodindo seu poder. Se você sabe algo muito importante, a forma de obter poder é, na verdade, compartilhando-o. (Joseph Badaracco)

Onde Todos Esses Problemas Apontam?

Todos esses problemas convergem para algo que muitas vezes ninguém quer abordar diretamente: a falta de conhecimento e maturidade em engenharia de software e nas skills de liderança dos chefes e líderes da organização.

“A capacidade de liderança é o teto que determina o nível de eficácia de uma pessoa.” (John C. Maxwell – As 21 Irrefutáveis Leis da Liderança)

“O mundo está precisando de líderes.” (JB Carvalho)

É comum, mas não normal, que nos cargos estratégicos existam mais chefes do que líderes. A maior parte das soluções para alta performance em engenharia de software vem de decisões ou ações que geralmente são contraintuitivas. E a pergunta que fica é: quem tem o poder de decisão para implementá-las? Quando essas ideias, técnicas e princípios são explanados, parecem “unicórnios voando sob arco-íris”, perfeitas. Mas na hora da prática, sempre surgem desculpas, quando na realidade o que falta é conhecimento e/ou coragem para aplicá-las corretamente.

Algumas empresas atualmente estão contratando pessoas mais técnicas para cargos mais estratégicos. Contudo, o perfil desejado é algo bem difícil de achar: uma pessoa que tenha profundidade técnica, conhecimento de gestão e de gente ao mesmo tempo. É realmente muito difícil encontrar esse conjunto completo. Você está achando que tem, né? Dos três, a habilidade de liderar, entender e se comunicar com pessoas é a mais difícil, e a de gestão a mais fácil entre elas.

Práticas Comprovadas (Mas Difíceis de Aplicar)

Vou listar algumas práticas cujos resultados e efetividade são amplamente documentados e que, para a comunidade técnica, não são novidade. No entanto, a aplicação delas, quando ocorre, geralmente deixa a desejar na maioria dos casos. As organizações que conseguem implementá-las são consideradas de nível Elite na avaliação do DORA. Essas são algumas dessas práticas:

• TDD (Desenvolvimento Orientado a Testes)
• Pareamento (Pair Programming)
• Team Building
• Fomento de Conhecimento e Coaching
• Times Verticalizados e Orientados a Domínio
• Times com Autonomia Fim a Fim
• Pequenas Entregas Diariamente com Automação
• Testes em Produção
• Abertura para Falhar Rápido
• Ambiente Seguro
• Cultura de Aprendizagem e Melhoria Contínua

Que nada mais são do que algumas das práticas essenciais da Agilidade e DevOps.

Conclusão

Ao final desta análise, fica evidente que a alta performance em times de desenvolvimento não é um mero acaso ou o resultado de uma pilha de talentos seniores. Pelo contrário, ela é o reflexo direto de decisões estratégicas acertadas, de uma governança que fomenta a autonomia, de uma estrutura de times bem definida e de uma cultura que valoriza o aprendizado e o compartilhamento.

Percebemos que as armadilhas desde a formação inadequada das equipes e a mão pesada da governança, até a falta de foco em comportamentos e a resistência ao compartilhamento de conhecimento, são sintomas de um problema maior: a carência de liderança e maturidade nos cargos estratégicos. Não basta ter “chefes”; o cenário atual exige líderes que não apenas compreendam a fundo a engenharia de software, mas que também possuam as habilidades de gestão e, crucialmente, as soft skills para guiar e inspirar pessoas.

As práticas comprovadas como TDD, Pair Programming, Team Building e a criação de ambientes seguros com autonomia e cultura de aprendizado não são segredos, mas sim pilares da agilidade e do DevOps. No entanto, sua implementação efetiva é onde muitas organizações falham, seja por falta de conhecimento, coragem ou a capacidade de enfrentar o status quo.

Em suma, a verdadeira transformação para a alta performance em engenharia de software reside na coragem de mudar a mentalidade de liderança e na disposição de investir em uma cultura que capacite, confie e inspire seus times. Somente assim será possível colher os frutos de equipes verdadeiramente eficientes, inovadoras e, acima de tudo, humanas.