When oversight becomes the obstacle to delivery

“Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” George S. Patton
“The greatest waste in America is failure to use the abilities of people.” W. Edwards Deming
Several years ago, I was responsible for delivering an important project that was going exceptionally well. We were ahead of schedule, meeting every major milestone, and operating with the kind of momentum project managers spend their careers trying to create. The team understood the objectives, knew its responsibilities, and had enough authority to resolve routine issues without convening a summit.
This was apparently a problem.
A new manager was assigned to oversee the work and quickly became involved in virtually every aspect of the project. Decisions that had previously been made by the people closest to the work now had to be elevated for review. Routine choices required approval, settled discussions were reopened, and progress frequently paused while the team waited for direction.
The team could still make decisions, of course, provided the manager had already made them.
Nothing about the project had become more difficult. The team had not suddenly become less capable, and our objectives had not changed. What changed was the decision system. Authority became concentrated in one place, while the information needed to make good decisions remained distributed across the team.
The project acquired considerably more management and considerably less movement.
When Control Creates the Problem It Is Supposed to Prevent
The new controls were presumably intended to reduce risk and improve oversight. Instead, every approval created another queue, and every decision that moved upward separated authority from the people with the most current information. Team members became increasingly reluctant to act because even reasonable decisions could later be questioned, reversed, or subjected to another round of executive archaeology.
Progress slowed, which naturally appeared to justify even greater management involvement. The controls created the delays, and the delays became evidence that more controls were needed. It was a wonderfully self-sustaining system, provided delivering the project was no longer the primary objective.
The more control that was imposed, the less control we had over delivery. Management gained greater involvement in individual decisions but lost the momentum and predictability it was trying to protect. Eventually, a project that had been ahead of schedule began struggling to maintain progress.
We had not solved a performance problem. We had manufactured one, documented it carefully, and placed it under close supervision.
Bureaucracy With a Backlog Is Still Bureaucracy
I often think about that experience when organizations discuss Agile transformation. Many introduce sprints, stand-ups, backlogs, retrospectives, new job titles, and expensive tracking software. Everyone receives training, the walls acquire sticky notes, and the organization announces that it is now Agile.
Then the team still has to ask permission to make a routine decision.
Agility is not created by changing the names of meetings. It comes from shortening the distance between information, decisions, and action. The people closest to the work need sufficient authority to resolve routine issues, adjust their approach, and continue moving within clearly established boundaries.
Without that authority, the organization can perform every Agile ceremony correctly and remain thoroughly bureaucratic. The sprint may last two weeks, but the decision process still operates on a two-month cycle. That is not agility. It is the same bureaucracy with a backlog and a daily status meeting.
Work moves efficiently across the board until it reaches the invisible column labeled “Waiting for Someone to Decide.”
Empowerment Requires More Than Encouraging Language
This does not mean eliminating leadership, governance, or accountability. Leaders should establish priorities, define boundaries, resolve strategic issues, and intervene when risks exceed the team’s authority. What they should not do is require every decision to travel upward simply because being consulted feels reassuring.
Organizations frequently tell teams they are empowered while retaining all meaningful decision authority several levels above them. This allows management to enjoy the language of empowerment without enduring the unsettling experience of allowing someone else to decide something.
A team is not empowered because the organization says it is. It is empowered when it can make the decisions necessary to deliver. If every significant choice requires permission, the team is not empowered. It is supervised.
Measure the Waiting, Not Just the Work
Organizations measure team performance enthusiastically. They track velocity, cycle time, milestones, backlog completion, utilization, and an impressive assortment of increasingly colorful indicators. They may calculate team velocity to two decimal places while ignoring the ten days a decision sat in someone’s inbox.
That waiting time may reveal more about organizational agility than any sprint metric. If a capable team can complete the work in two days but must wait two weeks for approval, the team is not the constraint. Adding another meeting, report, approval, or dashboard will not solve the problem.
It will simply give everyone better visibility into why nothing is moving.
If you want to know whether an organization is truly Agile, do not begin by counting its ceremonies. Measure how long it takes to make a decision and how far that decision must travel.
Where does work spend the most time waiting in your organization?





Comments