It Wasn’t Resistance. It Was an Organization Working in Fear
A few months ago, I had to witness an implementation where power decided on its own, and that’s when you realize something quite uncomfortable: the ERP does not fix the company, it only speeds up its disorder. The tool ends up amplifying weak decisions when the organization had already lost discipline a long time ago.
There is a very common confusion in technology. You see slowness, changes in criteria, and rework, and you assume the problem is resistance to change. My experience often tells me something else. The team was not resisting; it was adapting to the only possible context, one in which disagreeing could be costly.
That reading completely changes the diagnosis. An organization that lives in fear does not debate decisions; it absorbs them. It does not correct mistakes; it hides them. It does not build stability; it buys time with every adjustment, and then claims that was “alignment.”
In a manufacturing and installation company with debt, little visibility, and a turnover rate close to 15% per month, the visible symptom was operational instability. The real cause was extreme concentration of power. One person changed priorities, reinterpreted plans, and there was no formal mechanism to close decisions. There was no governance; there were impulses with authority.
From the outside, that could look like a lack of alignment. From the inside, it looked more like survival. If contradicting the owner meant friction, threats, or dismissal, the team stopped discussing and started executing with the smallest possible margin for maneuver. That did not generate commitment. It generated defensive obedience. And that obedience damaged the quality of decisions almost as much as any bad architecture.
That is why trying to solve it with an ERP was so predictable. Software does not create judgment; it only systematizes what already exists. If the company cannot sustain stable priorities, the ERP does not organize: it amplifies. In this case, moreover, the implementation required redesigning costs, quoting, and operational integration on a base that changed every week. There was too much automation on too little governance.
The solution was not elegant, but it was pragmatic. Execution was protected with a parallel control layer. It was moved to a web version to reduce friction. Traceability was strengthened with versioning and reversibility. The goal was not to make the system prettier; it was to contain the damage while the way decisions were made was stabilized.
The lesson for a CTO is uncomfortable, but useful. Before scaling processes, you need to understand who can change them and under what rules. If power does not accept limits, technology does not fix the organization. It only makes the symptom faster. A well-implemented ERP can bring order to an operation, but no platform compensates for a culture where no one can say something makes no sense without fearing the cost.
