The build was good. That is what made it instructive. It shipped on time, on scope, and it did the thing it was specified to do — and then it sat there, and the team it was built for kept doing the work the way they had always done it, and everybody was too polite to say so for about six weeks.
Nothing was broken. Uptime was fine. The model was accurate. If you had looked at any dashboard we had at the time, the project was a success, and it was not.
What we had actually measured
We had measured deployment. Every signal we were watching answered the question is it running? and none of them answered is anyone using it?
Those come apart more often than you would think, and when they do, they come apart quietly. A system nobody opens throws no errors. It generates no complaints, because complaining requires having used it. It simply produces a flat usage line that nobody is looking at, next to a green status page that everybody is.
Deployment is a fact about your infrastructure. Adoption is a fact about someone's Tuesday. We had built excellent instrumentation for the first one.
Why they didn't use it
When we finally sat with the team and asked properly, the reason was mundane and, in hindsight, entirely predictable.
The system was correct and it was somewhere else. It lived in its own interface, which meant using it required leaving the tool where the work already happened, forming a new habit, and trusting an output whose reasoning was not visible. Each of those is a small tax. Together they were larger than the tax of just doing it the old way, which was familiar and which nobody would be blamed for.
There was also a quieter thing, which took longer to surface: the first time the system was wrong, nobody knew what they were supposed to do about it. There was no defined behaviour for disagreement. So the safe move was not to rely on it, and safe moves become habits fast.
The three changes we made
Adoption is build work
The change that mattered most was not any of those three individually. It was moving adoption from something you attend to after launch to something that is in scope from the start — with a named owner, like any other deliverable.
That is why change management is one of the five disciplines we staff on every build rather than a phase at the end. When a loop takes over one step of a workflow, somebody's job changes. Somebody loses a task they were good at, and somebody gains a judgement call they did not previously have to make. If nobody has designed for that, the system is asking people to reorganise their working day in exchange for nothing they asked for.
We also demo weekly to the people who will actually run the workflow, not to the stakeholders who approved it. Those are different audiences and they give completely different feedback. Stakeholders tell you whether it looks impressive. Users tell you whether they would ever open it.
The test worth running on your own systems
Pick a system you launched more than a quarter ago. Do not look at its dashboard. Instead, find one person who was supposed to use it and ask them to walk you through the last time they did.
If they have to think about when that was, you have your answer — and the fix is almost never technical.
