Ao longo da minha carreira, tive a oportunidade de gerenciar desde pequenos projetos com equipes enxutas até projetos gigantescos com dezenas de times. Nesses cenários, atuei como gestor de gestores, supervisionando líderes e criando camadas de gestão. Em empresas de tecnologia, que se organizam melhor em torno de produtos do que de projetos, tive as mesmas oportunidades de liderança. O que percebi em ambos os casos é que a velocidade se perde à medida que o número de pessoas envolvidas aumenta. Mesmo em empresas de tecnologia organizadas por produto, a sobreposição de níveis de gestão resulta em lentidão.

No início, eu acreditava em um modelo organizacional influenciado pelas grandes estruturas onde trabalhei. Achava que times com pessoas de diferentes senioridades trariam ganhos culturais e acumulação de conhecimento. Juniores precisam de ensino, o que gera conhecimento documentado. A longo prazo, o time alcançaria excelência técnica, entregando rápido e com qualidade, a um custo menor do que um time composto apenas por seniores.

No entanto, ao testar esse modelo, enfrentei a alta oferta de empregos em engenharia e altos salários, resultando em um grande turnover. Trabalhei em uma empresa com mais de 100% de turnover em um ano. Nesse cenário, os times não alcançavam a performance esperada, e o conhecimento se perdia rapidamente. Refatorações constantes se tornavam reconstruções totais dos serviços.

Após muita frustração com a baixa performance desse modelo, passei a acreditar em times pequenos e muito seniores. Equipes de duas ou três pessoas são responsáveis por produtos e funcionalidades cuja carga cognitiva seja suportável. A sobrecarga cognitiva é perceptível quando o time se torna disfuncional, mesmo com poucas pessoas. A comunicação é prejudicada e o conhecimento se concentra em uma pessoa, em vez de ser bem distribuído. Nesse ponto, é necessário ter outras duas ou três pessoas para cuidar dos produtos excedentes. Com um bom entendimento dos boundary contexts, novos serviços podem ser criados e passados para o novo time.

Faz sentido começar com um monolito e, ao se dividir, continuar como um novo monolito dentro do novo time. O número de serviços cresce junto com o tamanho do time, e não o contrário. Assim, times de engenharia de software tendem a ser pequenos.

Por que um software precisa de milhares de pessoas trabalhando nele? Porque a complexidade da construção exige cada vez mais pessoas. Trabalhei em uma grande corporação que chegou a ter 6000 pessoas no desenvolvimento do produto digital.

Acredito que, ao adotar times pequenos e altamente seniores, conseguimos mitigar muitos dos desafios das grandes estruturas, ganhando em agilidade e eficiência. Esse modelo permite uma melhor distribuição de conhecimento e uma comunicação mais eficaz, resultando em produtos de maior qualidade e entregas mais rápidas.

Durante minha transição para empresas de tecnologia, as chamadas “x-techs”, notei a diferença entre modelos de gestão tradicional e horizontal. Embora grandes corporações também trabalhem sob metodologias ágeis, seus processos e tamanho geram muita inflexibilidade e morosidade. Grandes organizações enfrentam desafios únicos, pois possuem milhares de clientes e, portanto, requisitos rigorosos de segurança, performance e integração com sistemas legados. Esses fatores criam processos complexos e lentos. A complexidade do software é muitas vezes criada pelos processos estabelecidos, exigindo mais pessoas. Essa complexidade surge porque o software cresce sem foco nas necessidades do cliente, mas sim no corporativismo da empresa, onde processos são criados para garantir posições. Muitas vezes, a regulamentação e as exigências legais são culpadas, mas essas não deveriam ser tão complexas a ponto de exigir departamentos inteiros. Essas exigências podem ser facilmente absorvidas por cada time afetado. Em contraste, uma gestão horizontal, focada em colaboração constante e flexibilidade, proporciona uma resposta mais rápida às mudanças do mercado e necessidades dos clientes.

Com base nessas experiências, percebi que, para um time de engenharia, as hard skills (habilidades técnicas) se sobrepõem às soft skills (habilidades interpessoais). Mesmo a gestão deve ter um conhecimento técnico profundo para liderar o time em todos os desafios técnicos. Em última instância, o mais alto na hierarquia deve ser o responsável por definir a solução técnica caso o problema seja escalado. Embora as soft skills sejam importantes para manter a coesão da equipe, motivar os membros e assegurar uma comunicação eficaz, é o domínio técnico que realmente direciona o sucesso do time, garante a qualidade das entregas e assegura a confiança do time na liderança.

Essa visão se contrapõe à gestão tradicional, onde se esperava do gestor muito mais soft skill do que hard skill. Valorizar o soft skill sobre o hard skill e acreditar que um gestor pode ser hands-off é aceitar que a camada mais sênior já não é mais capaz de intervir na solução. Para mim, a senioridade está mais relacionada ao tempo. Resolver problemas e pensar fora da caixa é o que todo profissional deve alcançar. Uma vez lá, atuando dessa forma por bastante tempo, ele se torna sênior.

Entender que o gestor tem mais senioridade e, por conta disso, um salário maior, implica que ele seja a maior autoridade na definição da solução. Se o papel dele não for, em última instância, o de definir a solução, sendo hands-off, ele tem um papel que deveria ser tratado em paralelo, possuindo o mesmo salário e senioridade da pessoa que define a solução.

Um ponto crucial que merece discussão é a distância da alta gestão dos problemas na ponta, o que impossibilita seu envolvimento eficaz na solução. Essa distância muitas vezes justifica a existência de uma gestão hands-off e a criação de múltiplas camadas de gestão para garantir posições. No entanto, acredito que esse modelo não é eficiente. Em vez disso, defendo a eliminação dessas camadas intermediárias de gestão, promovendo uma estrutura onde, mesmo que a área de engenharia tenha muitos profissionais, eles respondam diretamente a um número muito pequeno de líderes. Esses líderes devem ser tecnicamente competentes e capazes de conhecer, juntos, toda a solução, estando a par de todos os problemas enfrentados na ponta. Com um time sênior, há autonomia para enfrentar o dia a dia sem a necessidade de uma gestão colada a ele.

Essa proximidade dos líderes com os problemas operacionais não só melhora a tomada de decisões, mas também garante que as soluções propostas sejam mais práticas e diretamente aplicáveis. Líderes técnicos bem informados podem intervir rapidamente quando necessário, evitando a perda de conhecimento e a lentidão associada à transferência de informações através de múltiplas camadas de gestão. Além disso, esse modelo reduz o risco de corporativismo e a criação de processos desnecessariamente complexos, focando no desenvolvimento de soluções que atendam diretamente às necessidades dos clientes e do mercado.

Em resumo, a evolução constante e a adaptação são essenciais no mundo da tecnologia. Adotar times pequenos e altamente seniores pode mitigar muitos desafios enfrentados em grandes estruturas, promovendo agilidade e eficiência.

A discussão interessante é como desmontar um time enorme e trazê-lo para os moldes aqui propostos.