We hear this sentence in almost every first meeting. Usually from an HR manager or a plant director, usually with a shrug, usually as the reason a previous rollout failed. It is said kindly, and it is said as though it were a fact about the people.
It is not a fact about the people. It is a fact about the tools.
The same operator who “doesn’t use technology” is in three WhatsApp groups, one of which is the real communication channel of your plant. He watches repair videos on his phone at lunch. He books flights, moves money, argues about football in a group chat, and troubleshoots his own car from a forum thread. There is no literacy problem. There is a very specific refusal, and it is aimed at specific softwares.
Some of this is a hangover from real failures. But a lot of it was never tested at all. Push past “they’re not ready for it” and the honest answer is usually a guess dressed as a fact: someone assumed the floor couldn’t handle an inbox, so nobody built anything to find out.
That assumption does damage on its own.
It blames the floor for a rejection that never happened.
Where a tool was tried and abandoned, the reasons that came back, across roughly a hundred conversations with operators, supervisors and plant leadership, on about thirty sites in six countries, were never about age or education. They were about what the tool asked for and what it gave back.
It went up and nothing came back. The classic version is the hazard report: you file it, and nothing observable happens, ever. After the third time, filing stops. It wasn’t a tool for the worker. It was a data-collection instrument pointed at the worker.
It cost shift time and paid nothing back in the same shift. Production is measured hourly and rewarded. Anything that takes eight minutes and returns value next quarter loses, rationally, every time.
It created exposure. A timestamp is evidence. Where investigations end at “human error,” a system that logs what you did and when is a system that logs who to blame. Workers read incentives for a living.
It assumed desk-worker physics. A login. A password that expires. An email address the worker doesn’t have. Six sub-menus with gloves on. Any one of those was enough to kill it.
It was in the wrong register. Not just the wrong national language, though that mattered too. The wrong voice, procedure prose written for an auditor, handed to someone under time pressure who needed two steps and got a page.
Nobody, in any of those hundred conversations, said “I don’t understand technology.” They said, five different ways, “this was not built for me.”
So what actually moves
The honest answer is that adoption on a floor is not won by training people to use software. It is won by making the first thirty seconds obviously worth their time, and then never breaking that deal.
Concretely, from what has actually worked and what has actually failed:
No install, no login. A QR code on the machine or a link in the group the plant already uses. Opens in a browser. If there is a password reset flow, you have already lost a third of the floor.
Answer before you ask. The first interaction should give the worker something they wanted: the two steps of the procedure they were unsure about, in their language, in ten seconds. A system that opens by testing them, instead of listening to them, is a system that has announced whose side it is on.
One question, forty seconds. Not a course, not a module, not a quiz. A check on the decision points that carry consequence, short enough to do while the machine cycles.
Anonymous and aggregate by default. This is the design decision that decides the whole thing. If a wrong answer can be traced to a name and used against that name, you will get theatre inside one quarter, and your data will be worse than no data. Aggregate tells you something more useful anyway: seven of nine people skipped verifying the isolation. That is a procedure problem, not nine personnel problems.
The supervisor first, or not at all. A tool the supervisor does not champion dies on the floor regardless of who signed the contract. To the worker, the supervisor is the company. Any rollout plan that treats the supervisor as an end user rather than a co-owner is a plan to buy shelfware.
Show them the change they caused. This is the only real engine, and it is the one almost nobody builds. When an operator’s answer reveals that step four is ambiguous, and the procedure gets corrected, tell the floor that the procedure changed because of what they said. Do it once and you have a system people talk to. Do it never and you have another data-collection instrument.
What does not work
Points, badges and leaderboards, on a floor where the tribal borders are already tense. Mandatory completion drives, which produce completion and nothing else. An app. Anything that starts with a two-hour induction on how to use the tool, because a tool that needs an induction has already failed the test.
Our CEO put it in a recent interview in a way I would not improve on: the biggest challenge is not the technology, it is the culture, and the answer is not to ask people to trust a new platform. It is to prove value fast enough that trust arrives on its own.
There is a measurable version of that. Instrument daily usage from week one of any pilot. If the floor is not using it at 60 to 70 percent within the pilot window, do not push expansion, do not add features, and do not blame the culture. Fix the deal you offered them.