No documentário The Story of C++: The World's Most Consequential Programming Language, lançado em junho de 2026, Andrew Koenig — ex-pesquisador do Bell Labs e editor do projeto de padronização ISO do C++ — descreve o ambiente em que a linguagem nasceu com uma frase que, em tradução livre, diz o seguinte:
"Quando você junta muitas pessoas altamente inteligentes em um só lugar, todo tipo de coisa acontece, algumas que você pode controlar e outras que não."
É uma frase sobre o Bell Labs, mas poderia ser sobre qualquer time de software que já entregou algo relevante. E o que mais nos interessa nela não é a primeira metade — a parte controlável, das metodologias e dos processos. É a segunda: as coisas que você não controla. É exatamente ali que mora o resultado extraordinário.
Ninguém planejou o C++ em um documento de requisitos. Ele emergiu de pessoas capazes, colocadas próximas umas das outras, com liberdade para discutir o problema. O papel de quem lidera não foi determinar a saída — foi criar as condições e aceitar que parte do resultado escapa ao controle.
Não é a ferramenta. Nunca foi
Ao longo de anos apoiando e construindo times de desenvolvimento, a constatação que mais se repete é também a mais desconfortável para quem vende metodologia: a maior parte do fracasso ou do sucesso de um projeto de software não tem a ver com as ferramentas ou as técnicas empregadas, mas com a equipe montada para executá-lo.
Já vimos os dois extremos, mais de uma vez.
De um lado, projetos tecnicamente complexos e sensíveis ao negócio, entregues por equipes pequenas — três, quatro, cinco pessoas — inteligentes e, crucialmente, complementares entre si. Prazo recorde e qualidade admirável. Não porque tinham um processo melhor, mas porque cada decisão passava por alguém que sabia avaliá-la, e nenhuma decisão dependia de uma única pessoa.
Do outro, projetos triviais do ponto de vista técnico, tocados por equipes grandes cujos integrantes não se complementavam. O resultado é sempre o mesmo roteiro: entregas atrasadas, pedaços de software que não se encaixam quando finalmente se encontram, orçamento estourado e uma qualidade ruim que todo mundo enxerga e ninguém nomeia.
A diferença entre os dois casos não estava no board, no framework de estimativa ou na stack. Estava em quem sentava para resolver o problema.
O que significa "complementar"
Complementaridade é uma palavra que costuma virar clichê de vaga de emprego. Vale ser específico, porque é disso que depende o resto do argumento.
Um time complementar não é um time de pessoas iguais e boas. É um time em que:
- As competências se sobrepõem o suficiente para haver conversa, e diferem o suficiente para haver revisão. Se todo mundo tem exatamente a mesma formação, o code review vira aprovação automática. Se ninguém compartilha vocabulário, vira ruído.
- Existe pelo menos uma pessoa que enxerga o sistema inteiro. Alguém que percebe quando duas decisões locais e corretas produzem uma incoerência global.
- Ninguém é insubstituível por acidente. Conhecimento concentrado em uma cabeça não é senioridade, é risco operacional.
- As pessoas discordam sem que isso vire um problema pessoal. Time que não discorda não está de acordo — está calado.
Repare que nada disso aparece em um organograma. É por isso que a composição de um time não é uma tarefa de recrutamento: é uma decisão de engenharia.
Por que a IA aumenta o peso dessa decisão
A leitura mais comum sobre inteligência artificial no desenvolvimento é que ela reduz a importância das pessoas — se a máquina escreve o código, o time importa menos. Nossa leitura é o oposto.
A IA absorve muito bem o trabalho repetitivo e maçante: o boilerplate, a tradução mecânica de um padrão conhecido, o teste óbvio, a refatoração de assinatura. Esse era, historicamente, o trabalho que escondia a diferença entre um time bom e um time mediano — porque uma equipe grande e pouco entrosada ainda conseguia mostrar volume de entrega.
Quando esse trabalho sai da mesa, o que sobra para o humano é a parte intelectual: definir fronteiras, escolher o que não construir, julgar se a sugestão da IA resolve o problema certo, decidir o que vai para produção. Sobra exatamente aquilo que só um bom time faz bem.
Ou seja: a IA não nivela a diferença entre times — ela a expõe. Um time forte com IA fica desproporcionalmente mais rápido. Um time fraco com IA passa a produzir código ruim em maior velocidade, e a dívida técnica que antes levava um ano para aparecer chega em três meses.
Já escrevemos aqui sobre a mecânica dessa relação, em O paradoxo da Clean Architecture na era da IA: o resultado do desenvolvimento assistido não depende só da capacidade do modelo, mas da maturidade técnica de quem está entre a cadeira e o teclado.
Onde colocamos o nosso esforço
Por tudo isso, a maior parte do nosso esforço na Hibex Solutions não está em defender uma stack ou um framework de processo. Está em demonstrar — com projeto real, e não com slide — que um bom trabalho de composição da equipe é o que determina o destino de cada projeto.
Na prática, isso significa tratar as seguintes perguntas como decisões de arquitetura, e não como assunto de RH:
- Quais competências este problema realmente exige, e quais estamos contratando por hábito?
- Quem, neste time, é capaz de discordar da pessoa mais sênior da sala?
- O que acontece com a entrega se a pessoa mais importante do projeto sair em três semanas?
- Estamos adicionando pessoas para acelerar, ou para justificar o cronograma?
Um time menor e bem composto entrega mais do que um time grande e desconexo. Isso não é uma opinião confortável de se defender diante de um plano de headcount, mas é o que vimos acontecer repetidamente.
E vale a ressalva: montar o time certo é condição necessária, não suficiente. As práticas cotidianas que transformam um bom time em um time que entrega são outro assunto, que tratamos em O que separa times de alto desempenho dos que só fazem Scrum no nome.
Como eu conduzo isso na prática
Se a tese é que pessoas determinam o resultado, então a forma de conduzir a empresa precisa ser coerente com ela. Três compromissos, que assumo de forma explícita:
1. Contato direto com cada colaborador. Sem camadas de intermediação para saber como o trabalho está indo. Liderança que só recebe informação filtrada por relatório descobre os problemas tarde demais — e, quase sempre, descobre por eles já terem virado consequência.
2. Comunicação regular sobre o momento da empresa. Em intervalos previsíveis, digo ao time o que estou pensando: onde a empresa está, para onde acredito que ela deve ir e por quê. Não é comunicado institucional; é exposição de raciocínio. Faço isso por dois motivos. O primeiro é dar a cada pessoa a chance de se alinhar com a visão de forma consciente, e não por adivinhação. O segundo é mais importante: é dar a elas a chance de apontar quando algo não parece estar no caminho certo. Uma visão que ninguém conhece não pode ser corrigida por ninguém.
3. Um canal seguro de feedback — com retorno. Todos precisam ter um caminho direto para me dizer o que está errado, sem custo político. E "seguro" só significa alguma coisa se houver resposta: feedback que entra em um formulário e nunca volta ensina o time a parar de dar feedback. O retorno é a parte que torna o canal real.
Nenhum desses três pontos é sofisticado. São difíceis por outro motivo: exigem tempo de quem lidera e disposição para ouvir que uma decisão sua foi ruim.
O que fica
A frase de Koenig termina admitindo que parte do que acontece está fora de controle. Isso costuma soar como um risco a ser mitigado. Nós lemos como a descrição honesta de como o bom software aparece.
Você não controla a solução elegante que surge de uma conversa de corredor, nem a simplificação que economiza seis meses de trabalho e nasce da observação de alguém que estava olhando o problema de outro ângulo. O que você controla é quem está na sala, se essas pessoas se complementam, e se elas têm segurança para falar.
Isso, sim, é decisão de gestão. E é a única que consistentemente vale mais do que a escolha da ferramenta.