Equipas grandes, energia de equipa pequena
Nesta página
De poucos em poucos anos, a IEEE Spectrum publica mais uma autópsia de falhas catastróficas de TI1. A mais recente contabiliza mais de $2 biliões por ano só em custos de falhas de software nos EUA. Os casos de estudo são tristemente familiares.
O sistema de salários Phoenix do Canadá inflacionou de CA$310M para $5,1B e deixou 70% dos funcionários federais com erros no pagamento. O sistema Horizon dos Correios do Reino Unido mandou pessoas inocentes para a prisão enquanto a liderança encobria bugs que sabia que existiam.
Já trabalhei em organizações que teriam entrado na lista se alguém se tivesse dado ao trabalho de as documentar.
Retrospetivas que não levam a lado nenhum
Os projetos descarrilam. Há uma correria. Depois vem uma retrospetiva a perguntar “o que podem os devs fazer de diferente?” E nunca a gestão.
Já estive nessas retrospetivas. As em que toda a gente sabe o que correu mal (o âmbito mudou três vezes, o prazo foi fixado antes de existirem requisitos, alguém acrescentou um gestor para “ajudar a coordenar” e de repente passas mais tempo em standups do que a escrever código), mas ninguém o diz, porque dizê-lo é admitir que o problema é a estrutura.
Para o poder que tem sobre a organização das equipas e dos processos, a gestão intermédia quase não responde pelos resultados. Poupavas milhares de milhões em despesa e aumentavas a produtividade em força se a gestão fosse o mínimo indispensável e fosse responsabilizada como toda a gente.
O imposto da camada de gestão
Os grandes projetos não falham porque os engenheiros não sabem programar. Falham porque cada camada de gestão acrescenta 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 pessoal. O pessoal exige gestores. Os gestores exigem processo. O processo exige reuniões. As reuniões exigem documentação. A documentação exige ciclos de revisão.
Nalgum ponto desta cadeia, alguém devia estar a escrever software.
Cada camada existe para coordenar a camada de baixo. Mas a coordenação tem custos: o contexto perde-se na tradução, as decisões atrasam-se à espera de aprovação e a responsabilidade dissolve-se em comité. Quando algo se parte, há gente suficiente envolvida para que ninguém seja claramente responsável.
O sistema de salários 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 percebia o que de facto se passava em baixo, até ser tarde demais.
Porque é que as equipas pequenas funcionam
As equipas pequenas superam as grandes. Não por terem engenheiros melhores, mas por terem:
- Ciclos de feedback curtos. Lanças uma coisa e vês os resultados.
- Responsabilidade clara. Quando algo se parte, toda a gente sabe quem o está a corrigir.
- Comunicação direta. Sem telefone estragado por três camadas de gestão.
A Linear chegou a uma avaliação de $1,25B com 100 funcionários e 2 PMs. Sem testes A/B. Sem dashboards de crescimento. Sem planeamento de sprints. Sem OKRs para contribuidores individuais. Só equipas pequenas de designers e engenheiros que pensam como gente de produto.
O produto vende-se 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. É esse o objetivo.
O erro não é crescer, é como se 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 precisares delas. Pôr um “diretor de engenharia” quando tens 8 engenheiros. Criar um “gabinete de gestão de projetos” porque dois projetos se sobrepuseram uma vez. Contratar gestores para gerir gestores antes de teres provado que precisas sequer da primeira camada.
Cada camada que acrescentas é uma aposta de que o custo de coordenação compensa o benefício da coordenação. A maioria das organizações perde essa aposta e nem sabe.
Escrevi sobre isto de outro ângulo no meu texto sobre Workforce Engineering na flowstate2. O problema da maioria dos líderes de tecnologia não é não saberem o que se passa, é terem construído sistemas em que a informação tem de atravessar tantas camadas que saber se torna impossível.
A resposta não são mais gestores. É melhor visibilidade.
Quando precisas de escalar além do que uma só equipa consegue, o objetivo deve ser preservar a dinâmica das equipas pequenas através de ferramentas, em vez de gerir a complexidade através de hierarquia. Torna a informação visível por defeito. Deixa as equipas ser donas dos resultados de ponta a ponta. Dá aos líderes de engenharia poder para coordenar diretamente.
Na flowstate, é isso que estamos a construir: uma plataforma de Workforce Engineering que dá visibilidade às organizações sem criar hierarquias de reporte. Para trazer à superfície os bloqueios sem exigir reuniões de ponto de situação. Para manter a liderança informada sem a transformar em gargalo.
A oportunidade de $2 biliões
Toda a gente sabe o que está errado. Corrigi-lo exige que quem tem poder se limite a si próprio.
A gestão intermédia existe porque é a opção por defeito. Porque sempre se fez assim. Porque orçamentos grandes parecem precisar de equipas grandes e equipas grandes parecem precisar de camadas.
Mas as provas são esmagadoras. As organizações que queimam milhares de milhões em projetos falhados têm milhares de funcionários. As que lançam produtos que funcionam têm muitas vezes dezenas.
A diferença não é talento. É estrutura.
A certa altura, temos de deixar de esperar resultados diferentes.