The system everyone mastered and nobody used
A rollout can succeed at everything it measures: timeline, training, budget, and still fail at the only thing that matters: actual use.
A few years ago I had dinner with a team of implementation consultants from one of the Big Four. These were the people who fly into global enterprises to bring a major project- and resource-management platform to life. These were absolute wizards, certified to the hilt, and knew the system to its corners. They wielded obscure configuration options in a way the people who built the tool never considered. They were the absolute masters of the craft.
At that time, my own company was using that very same tool, and I shared how even as technology adoption experts, we were struggling with, well, adopting the technology, despite clearly seeing its promise. We do highly complex work, and anything that can help wrangle that gets us very excited.
One of the experts then mentioned, with the particular pride of someone sharing a productivity hack, that he only opens the application once a week, on Fridays. He keeps his real work where his real work had always lived: in his notes, his messages, his head, and on Friday afternoon he sits down and transfers the week’s work into the system. All neat and tidy, so that clients are impressed when they see his dashboard, and so that his firm’s dashboards show the right colors on Monday.
This was not a sheepish admission of “do as I say, don’t do as I do”. This was nonchalant signaling of mastery and seniority.
I asked why he doesn’t just keep the tool open at all times and get everything done within it, eliminating the chore of copying everything over on Fridays. His reply was blunt: because everything you do in this highly structured, amazing tool requires, even when you’ve mastered it, attention and thought. Using it will always pull you out of whatever situation you’re in: a conversation, an analysis, a complex train of thought. And for someone doing complex and challenging work, such structural distraction was professional suicide.
This took me by surprise: the single most expert users of this platform, the people whose entire profession was to get other organizations to adopt it, had themselves not adopted it, and found it ill-suited for managing the complexity it was built for. They experienced this not as failure but as fluency – because in their hearts, the system was for someone else, in another situation. It was meant for the client’s teams, for their dashboards, for their work, but not for the way they themselves prefer to work.
The client’s version, the one with a budget attached, usually runs like this:
A large enterprise buys a well-regarded system.
The project gets a name, aw kickoff, and a countdown.
The integrations connect cleanly, security signs off, data migrates on schedule.
Training is thorough: high completion rates, good spirits, no complaints.
On the morning of go-live there is cake; the project report is a wall of green.
Six months later, somebody looks at the usage numbers, and adoption is barely at twenty-two percent.
This means that four out of five tasks that were supposed to run through the new system are still done the old way, touching the new system only occasionally, when they really, really must. The dashboards for the higher-ups remain either empty or inaccurate. Productivity takes a hit, because everyone now additionally blocks an afternoon every week to fulfill their reporting obligations in the new tool.
The project lead cannot explain it. He bought a genuinely good tool! He taught everyone to use it. By every input he knows how to measure, the rollout has succeeded. But the thing the rollout was for – people actually working in the new system – is not happening.
This is the most expensive recurring puzzle in enterprise technology. And the reason it stays a puzzle is that nearly everyone involved quietly carries the same false belief: that training produces adoption.
It does not.
Training produces familiarity with an interface, but not a routine revolving around it. The consultants at that dinner were proof of this, holding the highest possible familiarity and the lowest possible adoption in the same hands, and calling the combination expertise.
Everyone has dishes they cook from memory. You did not stop looking at the recipe because someone certified you had it down, you stopped because you made it often enough that the looking became unnecessary. You wanted the outcome frequently enough that repetition built the thing no training session provides: routine.
Then there are the dishes you make twice a year, for a specific occasion. You need the recipe in front of you every single time. It does not matter that you have technically made them dozens of times across a decade; twice a year is not enough for anything to stick.
No amount of instruction will move the twice-a-year dish into your routine. The problem isn’t that you lack knowledge, the problem is that you do not make it often enough because it does not slot well into your everyday cooking.
A tool that fits the daily flow of work is absorbed fast, without effort, through sheer repetition. Almost none of that routine is created by training. The tool that does not fit requires starting from scratch every time someone is forced to touch it, and remains a slow chore – no matter how good the original instruction was.
The Friday consultant was making the twice-a-year recipe, once a week, forever.
This distinction sorts every tech rollout into one of two situations that are routinely mistaken for each other:
In the first, the gap is knowledge. The team works in a way that fits the task, and the new tool does roughly what they already do, in roughly the order they already do it. The only thing standing between them and using it is knowing which button does what. In this situatuin, training works wonders for adoption, because tool knowledge is the whole gap, and teaching what buttons do is what the teams need to get going.
In the second, the gap is behavior. The tool demands a way of working that either doesn’t fit the task, or doesn’t fit the teams: different sequences, different habits, a different shape to the day. Training cannot ever bridge this gap. Not because the training is bad, but because knowledge is not what’s missing. You are asking people to change routines, and routines are not something you know your way into. They cost attention, effort, patience, and the willingness to be temporarily worse at your job while daily operations continue underneath. That cost is often worth paying, but it has to be budgeted as one.
It almost never is.
Change management through training treats every rollout as a knowledge gap. So even when the gap is behavioral, it sells a tutorial on new screens as the answer. To a budget holder, the method is seductive: training sessions can be scheduled, attendance can be tracked, completion rates can be reported. But the required attention to behavior does not vanish just because nobody is addressing it. The cost of this discrepancy gets paid anyway – involuntarily, by individuals, after hours – in the form of workarounds that route tasks around the system and into someone’s head, or an unofficial chat, or the person on everyone’s speed dial who absorbs into herself the gap the project never acknowledged.
None of these informal workarounds show up in a status report. Money spent on the platform is real and visible. Hours logged in training are real and visible. Completion rates on the learning trail are real, visible, and reassuring. But not one of them measures whether someone’s working day actually changed. Not one of them shows if the new tool has a hidden cost that the teams need to endure. The organization is reading training attendance as operative outcomes – the way you might weigh the groceries and conclude that dinner is made.
The research on technology acceptance (the real, academic research, not the consultancies’ whitepapers) has spent decades trying to predict under which conditions teams will actually use a new system. The predictors are now well understood and not exotic. Does the person believe the tool will help them do their job? Do they believe it will be easy to use? Training nudges the second, a little, temporarily. It does not touch the first at all.
But there is a third predictor, and it is the one that matters here, because it does not predict intention – it predicts actual use. The academic term is “facilitating conditions”, and the methodically complex, but actually quite plain question it asks is: does this person’s real day – their workflow, their available time, their actual support structure – make it possible for them to use the new thing?
This is the question of whether a tool fits someone’s random Tuesday.
If the superb project management suite matches the Big Four’s workdays.
If technological transformation is understood as just shopping, or invasive surgery on the very essence of how an organization works.
Most importantly, it is the question training plans don’t ask. It is the question nobody budgets for when the behavioral gap stays invisible. It is where rollouts go to die.
Teams end up here not because they were under-trained or unconvinced, but because the conditions of their working day did not support the new routine.
Most of these calls are easier to make before an organization commits to a new technology; the decision whether to go for it or not is easier to make when you have all the costs and numbers in front of you.
Sometimes this means that the technology purchase won’t happen, simply because the cost of change turns out to be way beyond any of the financial benefits that could arise from it.
Sometimes it means that another technology is better – something incrementally improved instead of a full transformation.
And sometimes the key to all of this is simply budgeting for a bit more time – giving the teams a less steep incline to climb to a new level of work.