There is a version of digital transformation that looks like success on paper.
The architecture is clean. The system passed UAT. The go-live date was hit. The steering committee signed off. And then, three months later, half the team is still using the old process — or worse, a shadow process nobody knew existed.
I have been on the solutioning side of enough transformations — across large manufacturers, growing startups, and everything in between — to know that this outcome is not bad luck. It is the result of a specific, repeatable mistake: treating human adoption as a post-deployment problem. It is not. It is a design input. And if you wait until go-live to discover that, you will be rebuilding.
The Excel Nobody Talked About
A few years ago, I was working on a production tracking system for a manufacturing client. The scope was well-defined. The requirements had been gathered. The stakeholders had signed off at each milestone. During discovery interviews with the floor supervisors — the people who would actually use the system every day — one detail surfaced that changed a lot.
For three years, they had been running a parallel Excel process alongside the official system. Not because they were resistant to technology. Because the original system was genuinely difficult to work with during testing and data entry. So they built their own workaround. Quietly. Practically. And it worked well enough that nobody above them had any reason to ask.
That Excel file was not in any requirements document. No steering committee had flagged it. It existed only in the daily reality of the people doing the work.
When we found it, several assumptions we had built the new system on turned out to be wrong. The UI and UX needed to change — not cosmetically, but structurally — to support the actual workflow. The way data was captured, validated, and progressed through states had to be rethought.
This is something I have come to believe strongly across every transformation I have been part of: the success of a new system depends on how closely it maps to the actual process. Not the intended process. Not the process as documented. The process as it is lived by the people doing the work. The closer that mapping, the higher the chance of adoption. And you cannot get that mapping without feedback from the people inside the process. We caught it before go-live because we ran discovery interviews. Many teams do not.
Why This Keeps Happening
Engineering managers and CTOs tend to think of adoption as a change management problem. You build the system, you train the users, you manage the transition. That framing puts adoption at the end of the project timeline.
The problem is that everything upstream of adoption — the architecture, the data model, the UX — gets locked down long before training begins. By the time you discover that users have edge cases your system cannot handle, or workflows your UI makes harder instead of easier, the cost of change is high.
What I have seen consistently, across industries and company sizes, is that the gap is almost never between IT and the business. It is between the architecture team and the people operating the legacy system every single day.
Those operators carry institutional knowledge that exists nowhere in the documentation. They know which edge cases break the official process. They know what gets entered manually because the system cannot handle it. They know where the real workflow diverges from the one on the process map.
That knowledge does not surface in a requirements workshop with the project sponsor. It surfaces when you sit down with the floor supervisor, the accounts clerk, the customer service rep, and you ask them to walk you through a difficult day.
What Changes When You Treat Adoption as a Design Requirement
The shift is not about adding more training. It is about moving discovery earlier — and treating what you find there as architecture input, not user feedback.
In practice, this means a few things:
Discovery interviews happen before architecture decisions are locked. Not as a UX exercise at the end, but as a core input to how the system is structured. Who are the actual operators? What does a hard day look like for them? Where does the current system force them to work around it?
The people running the legacy system are primary stakeholders. Not just the business owner who commissioned the project. The person entering data just before the shift ends matters as much as the VP who approved the budget. Their edge cases are not exceptions — they are requirements.
Undocumented processes are treated as signals, not surprises. When you find a shadow process — an Excel file, a WhatsApp group, a paper log — the right response is curiosity, not judgment. Something caused that to exist. Understanding what will improve your design.
The UX is designed around the actual workflow, not the intended one. There is always a gap between how a process was designed and how it actually runs. The further that gap, the higher the adoption risk. Closing it is an architecture problem, not a training problem. And the only way to close it accurately is through direct feedback from the people living that process every day — not from documentation, and not from a manager describing what their team does.
The Investment Question
For engineering managers and CTOs weighing whether this approach is worth the time, the calculation is straightforward.
Discovery interviews with end-users add time at the front of a project. Running them well, analysing what you find, and feeding it back into the design adds more. It is not free.
But the alternative — discovering critical workflow gaps during UAT, or after go-live — is far more expensive. Rework at that stage costs multiples of what early discovery would have cost. And the softer costs — user resistance, shadow processes, low adoption rates, the quiet failure of a system that technically works but practically doesn't — are harder to measure and longer to recover from.
This calculus has only improved with AI. The ability to prototype faster means you can put something in front of an operator earlier, gather real feedback, and course-correct before significant development effort is sunk. The cost of early iteration has dropped. Which means the case for investing in discovery and rapid prototyping — before architecture decisions are locked — is stronger now than it has ever been.
The floor supervisors at that manufacturing client had been working around the original system for three years before anyone asked them why. Three years of friction, double entry, and accumulated workarounds — baked into the muscle memory of the team who would need to adopt whatever came next.
We could not have built a system they would actually use without understanding that first.
What This Looks Like in Practice
If you are running or commissioning a digital transformation right now, the question worth asking is: who on your team has sat with the people who will use this system day-to-day, and what did they find?
Not the project sponsor. Not the department head. The operator. The person who knows every exception the current process cannot handle.
If the answer is "we have not done that yet" — and your architecture decisions are already in progress — you are building adoption risk into the system whether you intend to or not.
The discovery does not need to be a months-long ethnographic study. A handful of structured interviews, run early, with the right people, will surface more than a dozen requirements workshops with stakeholders who are one level removed from the actual work.
Human adoption is not something you manage after the system is built. It is something you design for from the beginning.
If you miss that window, you will find out the hard way — usually three months after go-live, when someone mentions the Excel file they have been maintaining since the project started.
