Image Gary Hamel spent decades asking why large organizations become rigid, slow, and hard to work inside. His diagnosis is simple: bureaucracy is not a symptom of poor management. It is a design, and its purpose is control, not the creation of value.
Image Gary Hamel spent decades asking why large organizations become rigid, slow, and hard to work inside. His diagnosis is simple: bureaucracy is not a symptom of poor management. It is a design, and its purpose is control, not the creation of value.
The teams that struggle most are rarely short of process. They have Release Train Engineers, quarterly PI Planning, Portfolio SAFe layers, and Agile coaches in numbers that would surprise most startups, and they are usually less able to respond to change than they were before any of this arrived.
What Hamel FoundHamel and Michele Zanini spent years measuring what bureaucracy costs before publishing Humanocracy in 2020 [1]. In the United States, management and admin jobs doubled between 1983 and the time of their research, while other roles grew by less than 40 percent. By 2014, there was one manager or admin for every 4.7 workers, around 18.5 million people whose core job is oversight, review, and sign-off. Their wages alone ran to about $1.4 trillion, and that is before counting the output they would produce if redirected to value-creating work. Hamel and Zanini put the total annual cost of bureaucracy at around $3 trillion in the US, and around $9 trillion across OECD countries [2].
The problem is not that people stop working. It is that work gets aimed at the wrong thing. Every approval layer, every sign-off cycle, every status report exists because someone decided that knowing what is going on matters more than letting the people closest to the work make the call. Hamel names what this builds: an org that runs on control, not contribution. His alternative, Humanocracy, starts from the opposite goal: maximize contribution, not control.
In context
- Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
- Source: Scrum.org
- Published: 11/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por que importa
Em gestão de projetos, quase tudo o que se discute como problema técnico é na verdade um problema de expectativas mal negociadas no começo. Escopo, prazo e custo foram acordados num momento em que ninguém tinha informação suficiente, e depois ninguém quis reabrir a conversa.
Meu filtro é a qualidade do relatório de status. Se todos os projetos estão em verde, o sistema de informação não serve: em qualquer portfólio real há iniciativas com problema, e uma organização saudável as mostra a tempo em vez de descobri-las no comitê de encerramento.
O que costuma dar errado
O que mais vejo falhar é o patrocinador ausente. Assina o início, aparece na foto e depois só volta quando há problema. Sem alguém com poder real removendo obstáculos a cada quinze dias, o gerente de projetos acaba negociando de igual para igual com áreas que não lhe reportam, e perde.
O que observar
- Quais riscos estão identificados, quem é dono de cada um e quando foram revisados pela última vez.
- O tamanho da primeira entrega útil: quanto mais longe estiver, mais se parece com uma aposta.
- Como foi estimado e quão perto estiveram as estimativas anteriores da mesma organização.
Como leio esta publicação
Se isto chegasse à minha mesa, a primeira coisa que eu pediria não é o avanço percentual: é a lista de decisões pendentes com nome e data. O percentual dá para maquiar; uma decisão travada há três semanas com um responsável identificado não dá para discutir, e explica o atraso muito melhor.
A notícia original está publicada em outro idioma; o trecho é citado como o veículo o entrega e o comentário é escrito em português.
Comentários
Ainda não há comentários. O primeiro pode ser o seu.
Está vivendo isso na sua equipe?
Abra o chat e me conte como estão lidando com isso. Tenho interesse em comparar notas.
