Times grandes, energia de time pequeno
Nesta página
A cada poucos anos, a IEEE Spectrum publica mais uma autópsia de fracassos catastróficos de TI1. A mais recente soma mais de $2 trilhões por ano só em custos de falhas de software nos EUA. Os estudos de caso são tristemente familiares.
O sistema de folha de pagamento Phoenix, do Canadá, inflou de CA$310 milhões para $5,1 bilhões e ainda deixou 70% dos funcionários federais com erros no pagamento. O sistema Horizon, dos Correios do Reino Unido, mandou inocentes para a prisão enquanto a liderança escondia bugs que sabia que existiam.
Já trabalhei em organizações que entrariam na lista se alguém tivesse se dado ao trabalho de escrevê-las.
Retrospectivas que não levam a lugar nenhum
O projeto sai dos trilhos. Vem a correria. Depois vem uma retrospectiva perguntando “o que os devs podem fazer diferente?”, nunca a gestão.
Já estive nessas retrospectivas. Aquelas em que todo mundo sabe o que deu errado (o escopo mudou três vezes, o prazo foi definido antes de existirem requisitos, alguém colocou um gerente para “ajudar a coordenar” e de repente você passa mais tempo em daily do que escrevendo código), mas ninguém fala, porque falar significa admitir que o problema é a estrutura.
Para o tanto de poder que tem sobre a organização e os processos dos times, a gestão intermediária quase não responde pelos resultados. Você economizaria bilhões em gastos e aumentaria a produtividade de um jeito enorme se a gestão fosse enxuta e cobrada como todo mundo.
O imposto da camada de gestão
Projetos grandes não fracassam porque engenheiros não sabem programar. Fracassam porque cada camada de gestão adiciona latência, dilui a responsabilidade e cria incentivos desalinhados com entregar software que funciona.
O padrão é previsível:
O projeto recebe orçamento. O orçamento justifica headcount. O headcount exige gerentes. Os gerentes exigem processo. O processo exige reuniões. As reuniões exigem documentação. A documentação exige ciclos de revisão.
Em algum ponto desse caminho, alguém deveria estar escrevendo software.
Cada camada existe para coordenar a de baixo. Só que coordenação tem custo: o contexto se perde na tradução, as decisões atrasam esperando aprovação e a responsabilidade se dissolve em comitê. Quando algo quebra, tem gente demais envolvida para alguém ser claramente o responsável.
O sistema Phoenix tinha 80.000 regras de pagamento para implementar. Mas as regras não eram o problema. O problema era uma organização em que a informação passava por tantas camadas que ninguém no topo entendia o que de fato acontecia lá embaixo até ser tarde demais.
Por que times pequenos funcionam
Times pequenos rendem mais que os grandes. Não porque tenham engenheiros melhores, mas porque têm:
- Ciclos de feedback curtos. Você entrega algo e vê o resultado.
- Responsabilidade clara. Quando algo quebra, todo mundo sabe quem está consertando.
- Comunicação direta. Sem telefone sem fio por três camadas de gestão.
A Linear chegou a uma avaliação de $1,25 bilhão com 100 funcionários e 2 PMs. Sem testes A/B. Sem painéis de crescimento. Sem planejamento de sprint. Sem OKRs para colaboradores individuais. Só times pequenos de designers e engenheiros que pensam como gente de produto.
O produto se vende sozinho porque funciona. E funciona porque quase não há nada entre quem toma as decisões e quem escreve o código. Muitas vezes são as mesmas pessoas.
Isso não é acaso. É o ponto.
O erro não é crescer, é como você cresce
A lição não é que as organizações devam ficar pequenas para sempre. Alguns problemas exigem escala.
O erro é recorrer a camadas de gestão antes de precisar delas. Contratar um “diretor de engenharia” quando você tem 8 engenheiros. Criar um “escritório de gerenciamento de projetos” porque dois projetos se sobrepuseram uma vez. Contratar gerentes para gerenciar gerentes antes de provar que você precisa da primeira camada.
Cada camada que você adiciona é uma aposta de que o custo da coordenação vale o benefício dela. A maioria das organizações perde essa aposta e nem sabe.
Escrevi sobre isso por outro ângulo no meu post sobre Workforce Engineering na flowstate2. O problema da maioria dos líderes de tecnologia não é que eles não sabem o que está acontecendo. É que construíram sistemas em que a informação precisa atravessar tantas camadas que saber se torna impossível.
A resposta não é mais gerentes. É mais visibilidade.
Quando você precisa crescer além do que um único time dá conta, o objetivo deve ser preservar a dinâmica de time pequeno com ferramentas, e não administrar a complexidade com hierarquia. Deixe a informação visível por padrão. Deixe os times serem donos dos resultados de ponta a ponta. Dê aos líderes de engenharia autonomia para coordenar diretamente.
Na flowstate, é isso que estamos construindo: uma plataforma de Workforce Engineering que dá visibilidade às organizações sem criar hierarquias de reporte. Para expor bloqueios sem exigir reuniões de status. Para manter a liderança informada sem transformá-la em gargalo.
A oportunidade de $2 trilhões
Todo mundo sabe o que está errado. Consertar exige que quem tem poder se imponha limites.
A gestão intermediária existe porque é o padrão. Porque sempre foi feito assim. Porque orçamentos grandes parecem pedir times grandes e times grandes parecem pedir camadas.
Mas as evidências são esmagadoras. As organizações que queimam bilhões em projetos fracassados têm milhares de funcionários. As que entregam produtos que funcionam muitas vezes têm dezenas.
A diferença não é talento. É estrutura.
Em algum momento, a gente precisa parar de esperar resultados diferentes.