Change Management Is Debugging Your Org OS

Why do we treat organizational resistance as a people problem?

We treat resistance as a people problem because it is easier to blame individuals for not adapting than to examine whether the change itself was poorly designed.

In 2021, I was brought in to salvage a stalled ERP migration at a 300-person manufacturing company. The initiative had been “in progress” for 8 months. Adoption among shop floor managers was at 12%. The project team described the problem in familiar terms: resistance to change, lack of buy-in, insufficient executive sponsorship. The VP of Operations called it a “culture problem.”

I spent the first 2 weeks ignoring the culture narrative and instead doing what any engineer does when a system behaves unexpectedly. I observed. I collected data. I formed hypotheses. I tested them. What I found was not a culture problem. It was a design problem.

What does it mean to debug an organization?

Debugging an organization means treating unexpected behavior as information rather than insubordination, and systematically isolating the root cause.

Software debugging follows a reliable pattern: reproduce the problem, isolate the variable, test a fix, verify the fix. Organizational debugging follows the same pattern, but the variables are workflows, incentive structures, and information flows rather than code paths.

In the ERP migration, I started by reproducing the problem. I shadowed 6 shop floor managers through a full day of work, asking them to use the new system while I observed. Every single one encountered the same 3 friction points within the first 90 minutes. First, the new system required 14 clicks to complete a material requisition that took 4 clicks in the old system. Second, the new system did not display real-time inventory levels, forcing managers to switch to a separate screen. Third, the approval workflow in the new system routed requests through 2 additional approval levels that did not exist in the old process.

These were not culture problems. These were bugs. The change management team had designed the migration around the ERP vendor’s “best configuration practices” (their term, not mine) without observing how the existing workflow actually functioned. The managers were not resisting change. They were rejecting a system that made their work harder. Their resistance was a perfectly rational response to a degraded user experience.

How do you apply the debugging cycle to organizational change?

Apply the four-phase debugging cycle: observe the actual behavior, hypothesize why the system is producing that behavior, test your hypothesis with a minimal intervention, and verify the outcome before scaling.

Phase one is observation without interpretation. I spent 40 hours observing workflows before forming any hypothesis. This is the hardest discipline for change managers trained in frameworks like ADKAR or Kotter’s 8-Step, which begin with a predetermined model of what change should look like. Debugging begins with no model. It begins with the question: what is actually happening?

Phase two is hypothesis formation. Based on observation, I formed 3 hypotheses about the ERP adoption failure. Hypothesis 1: the workflow was functionally worse for daily operations. Hypothesis 2: the training materials did not address the actual tasks managers performed. Hypothesis 3: the approval workflow changes were imposed without consulting the people who would use them.

Phase three is testing. I worked with the implementation team to create a modified configuration for 1 shop floor (22 people) that addressed all 3 hypotheses. I reduced the material requisition to 5 clicks, added a real-time inventory widget to the main screen, and reverted the approval workflow to match the existing structure while preserving the audit trail the finance team required. The modification took 4 days of configuration work.

Phase four is verification. Within 2 weeks, adoption on the test floor rose from 12% to 84%. The managers did not need training sessions, motivational speeches, or executive mandates. They needed a system that worked. I rolled the modified configuration to the remaining 4 shop floors over the next 9 weeks. Organization-wide adoption reached 78% within 11 weeks of the intervention.

What does this reveal about conventional change management?

Conventional change management frameworks assume resistance is an emotional response to disruption, but in most cases, it is a rational response to poorly designed systems.

The change management industry is built on a model of human resistance that treats organizations like patients who need to be guided through stages of grief. Kubler-Ross was never meant to describe organizational dynamics, yet her framework has been adapted into dozens of change management models that assume denial, anger, bargaining, depression, and acceptance are the natural arc of any transformation.

This framing has a convenient property for consultants and project sponsors: it locates the problem in the people rather than in the change. If people resist, they are in the “denial” stage. If they complain, they are in the “anger” stage. The framework provides language that makes any feedback interpretable as a phase to be managed through, rather than a signal to be listened to.

Marcus Aurelius wrote that the obstacle is the way. In organizational change, the obstacle (resistance) is literally the way. It is the system telling you where your design is flawed. Every complaint is a log entry. Every workaround is a stack trace. Every refusal to adopt is a failed assertion that your change was compatible with the operational reality.

When is resistance actually a culture problem?

Resistance is a culture problem only after you have eliminated every design, workflow, and incentive explanation, which in my experience accounts for fewer than 15% of cases.

I do not deny that genuine cultural resistance exists. In roughly 15% of the change initiatives I have evaluated, resistance persisted after all design issues were resolved. These cases shared common characteristics: the change eliminated a role, reduced someone’s authority, or required skills that individuals were unwilling to develop. These are genuine people problems that require genuine people solutions.

But 85% of the resistance I have encountered was the system working correctly. People were producing accurate feedback about flawed designs. The tragedy is that this feedback was systematically ignored, reinterpreted as emotional resistance, and managed through communication campaigns rather than design iterations.

The Stoic discipline of distinguishing between what is in our control and what is not applies directly. You cannot control whether people feel uncomfortable with change. You can control whether the change you designed actually works for the people who must use it. Start with what you can control. In most cases, that is all you need.