When “data-driven” is blocked by design
The organisation announced a shift toward data-driven decision-making. A formal data function was established.
Two years later, a basic daily sales dashboard still did not exist.
The data function had no access to sales target data.
Sales targets sat outside the data warehouse.
The function had no authority to access source systems.
Authority to add the data sat with a senior leader who did not report to the data function.
The data function raised the dependency upward. It was rejected by middle management.
No escalation followed.
To keep delivery moving, the data function proposed a workaround.
Users would extract sales targets manually.
Reformat them.
Upload them weekly.
Check them repeatedly so the dashboard could run.
A user attempted to escalate the issue independently. Management did not respond.
Silence replaced decision.
The transformation team became involved.
The dependency was visible.
The constraint was understood.
Escalation to the authority that could redesign access did not occur. Instead, the same workaround was reinforced.
Manual extraction was added on top of the user’s existing responsibilities.
The process was documented.
Standardised.
Maintained.
Manual work became infrastructure.
Data responsibility was assigned.
Data authority was not.
The data function was accountable for insights.
It had no control over access.
No ability to compel integration.
No forcing mechanism when dependencies blocked delivery.
When escalation terminates below authority, redesign does not occur.
Workarounds do.
The organisation wanted data-backed decisions. The design made manual extraction permanent.
This failure mode is one surface expression of a deeper structural loop.
The full model is developed in When Failure Becomes Rational.