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.
Why it matters
In project management, nearly everything discussed as a technical problem is really a problem of expectations badly negotiated at the start. Scope, time and cost were agreed at a moment when nobody had enough information, and afterwards nobody wanted to reopen the conversation.
My filter is the quality of the status report. If every project is green, the reporting system is not working: in any real portfolio some initiatives are in trouble, and a healthy organisation surfaces them in time rather than discovering them at the closure committee.
What usually goes wrong
What I see fail most is the absent sponsor. They sign the kick-off, appear in the photo, and do not come back until there is a problem. Without somebody with real authority clearing obstacles every fortnight, the project manager ends up negotiating as an equal with areas that do not report to them, and loses.
What to watch
- Which risks are identified, who owns each one, and when they were last reviewed.
- The size of the first useful delivery: the further out it is, the more it resembles a bet.
- How it was estimated and how close the same organisation's previous estimates turned out to be.
How I read this entry
If this landed on my desk, the first thing I would ask for is not percentage complete: it is the list of pending decisions with a name and a date. A percentage can be dressed up; a decision stuck for three weeks with an identified owner cannot be argued with, and it explains the delay far better.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Comments
No comments yet. Yours can be the first.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
