The technology company that ran on paper

The client was a technical hardware business. Technology sat in the name, in the catalogue and in every customer conversation. Behind the counter, the operation ran on paper. Orders moved through the business as physical documents, passed hand to hand, and if a piece of paper went missing, the order went with it. Everyone knew it. Nobody could quite let go of it.

The reason nobody could let go was that the paper system was not really a paper system. It was a memory system, held in the heads of the old guard who had designed it over decades and never written any of it down. It worked because they made it work. New hires had to learn the business by watching and doing, apprenticed to knowledge that existed nowhere else, and many of them found the climb too steep and left. The people who understood the system best were also the people the system depended on entirely, and they knew it.

So when the business decided to implement an ERP with AI capability, it was doing something genuinely necessary. It was also, and this is the part few change plans account for, asking its most experienced people to trade mastery for beginnerhood. They knew the business needed the system. Wanting it was a different matter altogether.

What followed were some remarkable dynamics. The company was implementing the ERP and rubbishing it at the same time, sometimes in the same meeting. Leaders would voice their frustration with the new system openly, and every complaint from the top handed the resistors a permission slip. Factions formed and resisted in public. The people most needed to carry the change were the ones most vocally undermining it, often without realising the signal they were sending.

We came into this one halfway through, when the implementation was already flagging. The instinct at that point in a struggling rollout is always to push harder on the deployment: more training, more configuration, more pressure. We did the opposite and stepped back, because the diagnosis mattered more than the momentum. What the step back revealed was that the requirement had never truly been defined. The business had concluded it lacked software. What it actually lacked was systems. Its processes lived in memory rather than in any form a system could encode, and software layered over undocumented process gives you bad systems with software on top. No amount of configuration was going to fix a requirement nobody had written down.

So before returning to the rollout, we helped the business do the hard work it had skipped: our ICAM and ICAP frameworks stepped the leadership team through answering the real questions first, defining and actually building out the processes the software needed to support, aligning the executive team on the destination, and creating the genuine urgency the change deserved rather than the grudging compliance it was getting.

The other half of the work was leadership discipline through the low point of the curve. Every change passes through a valley where the losses feel total and the benefits feel theoretical, and what leaders say in that valley sets the tone for everyone below them. The commitment we asked of this executive team was simple to state and hard to keep: hold the line in public, bring the frustrations to the leadership table instead of the shop floor, and give the sceptics evidence rather than echoes. Once the leaders stopped rubbishing the system, the factions lost their air cover, and the conversation shifted from whether the change would survive to how to make it work.

The rollout landed. The software went in, the investment that had looked like being written off delivered its return, and the sales process improved significantly, with orders now documented and guided by the system rather than carried around in someone's hands. The change reached the resistors too. They took longer, as resistors do, but with the leadership steady and most of their colleagues visibly better off, they came around on the evidence. And the problem that had been costing the business people for years resolved along the way: with everything documented and the system guiding the work, new hires got up to speed quickly, and the turnover that came from learning by watching fell away.

The lesson travels well beyond this client. Technology adoption fails as a leadership problem far more often than as a technical one, and the resistance is rarely about the software. It is about what the software takes from people: the mastery, the status and the indispensability that the old way conferred. Diagnose that loss first, do the systems work before the software work, and hold your nerve in the valley.

If your organisation is adopting new technology and finding the resistance harder than the implementation, talk to us about our change services. Diagnosing what your people stand to lose, and leading them through it, is exactly the work we do.