Who Really Decides Around Here?

The Change Was Already Happening

The project had been running for four months.

The client was demanding, the scope complex, with several engineering stakeholders involved at contractual level, and requests for adjustments arrived frequently. Some were small clarifications. Others reshaped entire work packages. On paper, every scope change required discussion, approval, and commercial alignment before execution.

In practice, work often started before any of that happened as everyone knew the project schedule was “very ambitious”.

The project manager would discover, sometimes weeks later, that a team was already implementing a modification he had never approved. By the time the information reached him, the work was underway, budgets were being consumed, and negotiation space had narrowed to almost nothing.

From his perspective, the problem was timing. Team leaders were not coming to him early enough. They were not flagging changes as soon as they appeared. They were not consolidating information before execution began. As a result, he was forced into reactive conversations with the client, defending overruns instead of negotiating scope.

Inside the project, everyone was busy. Information was flowing. Meetings were happening. And yet, decisions about what counted as a change were consistently made only after the consequences became visible.

The project was not drifting because no one cared.

It was drifting because the moment where a decision should have been made had quietly passed — without anyone noticing that it was theirs to make.

The Comfort of Central Control

From both the organisation’s and the project manager’s points of view, the setup made sense.

The project was complex. The client was persistent. Scope changes had both technical and commercial consequences. Allowing multiple people to step into the negotiation or even label something as a “change” felt risky. Fragmentation would weaken the position of the company. Control had to stay centralized.

So it was the company’s best practice to have the PM acting as the single point where changes were to be recognized, assessed, and negotiated. Given the very tight schedule, team leaders were expected to execute, not to engage in commercial conversations or challenge client requests directly. The PM was aware that by shielding the team leaders from pressure, conflict, and ambiguity, the project would have the best conditions to finish on time.

Central control created reassurance. It preserved coherence in client communication. It reduced the risk of contradictory messages. It reinforced the idea that change management was a managerial responsibility, not an operational one.

On the surface, this looked like leadership.

What remained invisible was the trade-off embedded in that choice.

By holding the authority to decide what constituted a change exclusively at his level, the PM also held the responsibility for recognizing it. Still, recognition of a change, in a complex project, does not happen where negotiation happens (i.e. PM). It happens where information first appears (i.e. team leader).

Central control felt safer. But safety came at the cost of timing. As the closer decision authority is placed to formal power, the further it moves away from real-time reality.

When Discernment Is Removed from the Edge

Over time, team leaders adapted to work at the protection of the shield.

They learned that they are there to execute and deliver according to the ambitious schedule. Everything else came second. Identifying a change in scope was not necessarily their first priority. That judgment belonged higher up. Their responsibility was to deliver what arrived, clarify technical details, and keep work moving.

With all eyes looking at the schedule, they understood that if something felt different from the original scope, it was nevertheless safer to execute first and report later,  once there was clarity, or once the impact could be demonstrated. Until then, raising questions to their client counterpart would have created friction without authority.

So discernment slowly disappeared from the edge of the project.

Signals that should have triggered early conversations were absorbed into execution. Requests were treated as instructions. Ambiguity was resolved by action. What could have been discussed became something that had already happened.

This was not negligence. It was learned behavior pushed by the “ambitious schedule”.

The system taught team leaders that what mattered most was progress, delivery, and keeping momentum. Noticing changes came secondary and only when team leaders noted their budgets were at risk. 

As a result, the project developed a silent rule: changes became visible only when they turned into budget problems.

By the time numbers no longer added up, decisions had already been made — not explicitly, but through accumulated execution. Authority had not disappeared. It had simply moved, quietly, from decision to consequence.

The project was no longer governed by intent or agreement, but by what had already been done.

Decisions That Arrive After Execution

Formally, decisions about scope belonged to the project manager. In reality, most decisions were made elsewhere and much earlier.

They were made when a request was treated as work. When an accepted work-change replaced challenging the client. When execution filled the space where a decision should have happened - at team leader level.

By the time the project manager became involved, the system had already moved. Work had started, resources were committed, and the conversation with the client could only address consequences, not choices.

This created a structural illusion of control. The PM appeared to be deciding. But what he was actually doing was validating what execution had already confirmed. Negotiation became retrospective. Approval followed delivery.

Power did not disappear from the project. It shifted. It moved from explicit decision-making to implicit execution. From formal authority to operational momentum. From leadership intent to irreversible facts.

No one set out to bypass the PM. And in fact the PM himself was highly involved in controlling and hunting the changes.

The system simply learned that decisions would be made faster by acting than by waiting. And once that pattern took hold, speed belonged to execution, not to governance.

In such a system, accountability arrives late, clarity arrives late, and cost becomes the primary signal that something should have been decided earlier.

By then, it is no longer a decision. It is a justification.

A Question of Where Authority Actually Lives

Leadership asked for detailed change management. 

What they received was detailed visibility after execution had already taken place.

The gap is not procedural. It is architectural.

In this project, authority to recognize a change was placed far from where change first appeared. Discernment was centralized, while information was distributed. As a result, decisions were structurally delayed; not by people, but by design.

The project manager did not fail to control change. Team leaders did not fail to escalate. The system failed to decide early.

And when a system decides late, it always decides through cost.

This raises a leadership question that goes beyond this project, this client, or this PM:

At what level in the organization are people authorized to acknowledge and say, “this is no longer the same work” before execution turns it into a financial fact?

Until that question is answered explicitly, the organization will continue to let projects answer it implicitly.

Organizations do not drift because change exists. They drift when the moment where change should be recognized is structurally misplaced. When authority to acknowledge, name, and decide is detached from where reality first shifts — or when accountability is absent at that level — action inevitably replaces choice.

What is often labeled as a problem of discipline, communication, leadership skill, or external pressure is, more fundamentally, a problem of decision architecture. Culture does not form around intention or declared values, but around where the system allows decisions to be made — and where it quietly prevents them.

In the end, the invisible organization is revealed not by what leaders claim to control, but by when decisions actually occur. And in many systems, the answer is the same: the system decides first.

• Where does execution in your organization replace explicit decision-making?
• Where has acting first become safer than deciding openly?
• When consequences surface, do you see incidents — or cultural signals?

Until next time, may authority, clarity, and execution stay aligned.

Alina Florea
The Invisible Organization