Centralized Control – Trapped in Wagile (Part 4 of 4)

by | Oct 22, 2014

Phase gates large batch centralized control wagile article series image

This is the last part in the series “Trapped in Wagile”. In the kick-off article I outlined three fundamental characteristics of waterfall organizations. In subsequent articles I explained Phase-Gates (part 2) and Large-batch handoffs (part 3). In this article:

Centralized Control

Tendencies to centralize control of decisions stem from misunderstanding of complexity inherent in real world projects.

An expert plumber can understand how the pipes and systems in a building fit together and behave. A plumber can break a complicated plumbing system into parts and know how they will behave together. 

Behavior of a complex system is inherently NOT understandable. For someone or a group to carry a mental model of how everything and everybody in organization system fits together is impossible. So give up on attempts to understanding. Your organization is a dynamic organism and you will never be able to keep up with the complexity it exhibits. Not even if you could keep track of every atom in the universe.

Attempts at understanding, lead organizations to demonstrate centralized control characteristics. 

Expected System Behavior:

Fractal Nature:

At portfolio or organization level:

– Deep dive product backlog reviews by senior management, where senior management drills down at user story level and often gets stuck in low level details.

– Strong management push for ALM tools to be used a certain way across the board.

At project implementation level:

A project manager or Wagile Master conducts laborious sprint planning meetings. Typically in front of a projector, doing roll call around the table, filling in estimates for each team-member. Often questioning estimates and making sure, every one has been assigned enough work to stay busy during the sprint. Expressing concern when (s)he perceives that a team member has not signed-up for all their available hours in the sprint.

At task level:

Contrary to definition of scrum, a development lead and testing lead is appointed for a scrum team. Often because an organization cannot fund enough lead-level people, these leads are shared between teams. Leads are held responsible for utilization and quality of work of junior members in the team.

Default Setting: Command and Control

The purpose of practical management is of controlling organization system to deliver desirable outcomes (goals) and not that of understanding the organization system. Confusing the two and assuming a causation that understanding leads to (better) control is a myth. Which drives centralization of “understanding” a.k.a reports up the chain.

Its a long con. People elevated to power roles (managers, leads etc) believe that there are “others” who either do not “get-it” or have not “paid-their-dues”. By believing that a complex system is understandable and only by a meritorious few, we are expressing that people who do the ‘work’ are fittings in a plumbing system. Parts that need to be told not only WHAT to do but also HOW to do their work. This tunes organization systems default setting at “command and control”.

Especially at the power centers of the organization, this deep rooted cultural belief persists –

“While there are many ways to do a job, the manager or team-lead is the best suited to organize people and schedule tasks for most efficient and most effective results.”

Try harder:

If the worker does not deliver on results planned by the manager, then the worker should try harder next time.

When you buy into the myth that complex endeavors are understandable by specialist roles – it is easy to see why, Managers/Leads are often held responsible for deciding what to work on and how to work on it. We’d be successful – if only workers stopped using their heads and did what I told them to do. Clearly when the worker fails at delivering results, they have a need to grow and apply themselves. “grow-up, try harder” – Something a caring mother would say! – See management is so benevolent. #sarcasm

Fungible Resources:

Management via abstraction is prevalent in centralized control environments. Managers spend more time buried into spreadsheets and reports than doing the work that they are reporting on. 

People are often reduced down to resources. With distilled attributes:

 Bob – Java dev, gets along with people, likes agile, technically moderate skills.

Just a few attributes, enough that the person tinkering within spreadsheet can handle. And if Bob is not available, then replace him with Jenna – she has similar characteristics. It will all work out. No need to talk to Bob and Jenna, they are resources. #soul-sucking

If this is not a case of institutionalized stereotyping then I do not know what is! – BTW, in public life people are people, but as soon as they walk in through the glass door, they turn into “resources” reduced to fit in the box their manager imagines.

Unintended Consequences:

Low morale & the Illusion of Knowing:

Uncertainty is not comfortable. It makes people and organizations nervous. Attempts at concentrating understanding helps promote an illusion of knowing.

When it is your “job” to know, “I don’t know” is not an acceptable answer. Admitting so could be career suicide.  When grappled with a complex problem, such as – What will be in this product release? or When can I get feature X ?, they substitute richness of this  complex question with a straw man.

What is the plan? – And a plan they create. Through lists of assumptions, schedules, assignments, risk logs etc. Or in case of Wagile prepare backlogs with 100’s of items and insist on team meeting velocity commitments. A plan is comforting, sometimes even makes sense. It describes a path from here to there. Though in reality there are disturbances. When faced with these changes in reality, workers paralyze and wait until new set of instructions get relayed. 

Remember the last time, rumor-mill served up a “tip” about likely project cancellation. or when your dev lead was on sick-leave and everyone avoided working on his code.

Relay of change in conditions and subsequent adjustments by the central authority is by-design bound to delays. This throws future predictions and commitments out of whack from the plan. One way to maintain illusion of knowing by people who were expected to know is to start whipping reality into conformance. Command and control is inevitable in cultures that cannot maintain comfort in face of uncertainty. Other ways are to believe-in-magic (read: lying to self), rely on heroics and stress over minute decisions made by team members. 

Lack of empowerment of workers and dis-comforting lack of control by managers wears everyone down. Some just do their jobs, some complain, some blend in with furniture, hero’s get promoted and the ones with fire in their belly leave.

Low transparency: 

Success or failure is often not recognizable until the last moment. Coupled with wait states of sequential processes and local-optimization of large-batches, dependencies get created faster than they get resolved. As central decision point for her silo/team, much depends on the manager/lead to keep track of and get resolution for dependencies that her teams needs resolved. Attempts at centralized understanding lead management to push for implementation of ALM tool. Triggering the cycle of push back and then feigned compliance by teams so as to get management off their backs. The organization still lacks any meaningful transparency, but now they can blame the tool. 


Project pressures and time line constraints never seem to let up. Remember the illusion of knowing that comes from attempts at central understanding. There is always that deliverable that needed to be done, yesterday! – channeling organizational energies to play catch-up. Never able to work on improvements that would help the group work smarter. In centralized control environments, last minute problem solving gets rewarded over learning and heroics get rewarded over improvement activities. It is likely that many past hero’s – who saved the day! are now in senior management roles who are likely to groom and favor people who tend to be like themselves.

Self-fulfilling prophecy: 

Managers or leads that control distribution of tasks, often give challenging tasks to trusted hero’s. Other people do not get a chance to sharpen their skills and demonstrate competence. Which leads to less and less of challenging work being directed to them. It is very important in centralized control environments for the workers to be perceived as skillful in their managers opinion, otherwise they will rarely get opportunities to improve and/or demonstrate competence. It is dangerous when managers pride in boxing their people into neat little categories. They often create the sub-optimal reality that they are trying to avoid in the first place.


Let it go. You don’t need to be in the “know”. Project or initiative success does not depend on your knowing, in fact it more harmful than you are aware of. Trust your team. Listen, to tune into the system from their perspective and not to formulate your answer. Serve by developing a environment of trust, support and information. You’d be surprised by how much of your work stress can be relived when you admit – “I don’t know”.

Engage us for advise and strategy services to chart your transformation journey.

While there are many challenges to overcome, I hope this series of articles provided a fresh perspective. I am eager to learn about my blind spots and whether you found this article useful. I invite you to comment below and engage in further discussion.



  1. Phase Gates : Trapped in Wagile (part 2 of 4) – Evolve Agility Inc. - […] Centralized control : Trapped in Wagile (Part 4 of 4) […]
  2. Trapped in Wagile – Evolve Agility Inc. - […] Centralized control : Trapped in Wagile (Part 4 of 4) […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.