The Pressure to Use AI Was There. The How Was Not.
One morning, he got a Slack notification. "As of today, AI writing tool accounts have been activated for everyone on the team. Please make active use of them to improve productivity." There were no usage guidelines, and no word on which tasks to try first. Two months later, he admitted he could count his logins on one hand. He didn't know how to use it — or more precisely, he didn't even know what "knowing how" was supposed to look like.
This scene maps directly onto a phenomenon reported by BBC Business: a growing number of companies are encouraging or requiring employees to use AI while telling them nothing about how to actually do it. The tools have arrived, but there is no path for folding them into the daily flow of work. The organization wanted speed. The employees lost their bearings.
The Accounts Showed Up. The Design Never Did.
There is a striking split in how companies roll out AI. Some buy licenses, hand out accounts, and wrap things up with an announcement that reads "AI use is encouraged going forward." Others first design which tasks the tool will serve, what outputs it should produce, and at what level it will be used — and only then bring the tool in. Most of the organizations now struggling belong to the first group.
This isn't simply a training gap. The problem is less that people don't know how to operate the tool, and more that they don't know what they're supposed to do with it. When a marketer is handed an AI copywriting tool and left to decide, alone, "where exactly does this fit into my current work?" — that isn't a reduction in workload. It's a new cognitive burden. And few people have the slack in their workday to make that call.
Surveys of UK companies keep turning up the same pattern. A majority of managers at organizations that have adopted AI tools say their teams "aren't using them properly" — yet only a small fraction have put formal usage guidelines or workflow-integration plans in place. The investment happened; the design that converts it into actual work outcomes was skipped.
We already know how decisive the first few weeks are when a new person joins an organization. Six months in, there is a stark difference between someone who was given structured guidance — what work they own, who they collaborate with and how, what standards they'll be judged by — and someone who wasn't. A new hire given nothing but a desk on day one rarely figures out their role on their own. There's no reason tool adoption should work any differently. The day the account is created is the day onboarding begins. How people relate to the tool in those first few weeks determines whether it ever makes it into their actual work.
How Pressure Produces Box-Checking Instead of Adoption
The word that stands out in the BBC's reporting is "confused." Employees aren't resisting or refusing — they don't know which way to go. That distinction matters. Plenty of executives blame failed AI rollouts on employee resistance, when what's actually happening on the ground is closer to an absence of direction.
When there's a goal but no path, people make the safest choice available. Rather than rejecting the AI tool outright, they settle into performative use: handing a report draft to the AI and then rewriting it from scratch, submitting the output unreviewed, or only ever dabbling with it on things unrelated to their real work. None of these leads to the productivity gains the organization was counting on.
The stronger the short-term performance pressure, the sharper this pattern becomes. When there's no time to learn while doing, and AI usage suddenly appears on the performance review, employees will prioritize the deadline in front of them over learning the tool. Usage metrics go up. Actual work doesn't change.
The counterargument deserves a fair hearing. Today's AI tools are far more intuitive than previous generations of enterprise software, and YouTube and online communities offer vast amounts of free learning material. Some argue that an overly structured rollout program can actually stifle employees' self-directed exploration and shut down creative uses the organization never anticipated. There's no shortage of cases where people who learned by trial and error came to understand a tool more deeply than those who simply followed the guidelines. The observation that exploration teaches more than manuals do is not wrong.
But for that argument to hold, certain preconditions must be met. There has to be time to explore, a culture that tolerates mistakes, and a structure through which what people learn can flow back into the work. Pressure poured on without those three things isn't autonomous exploration. It's abandonment.
What Korea's Solo Operators and Middle Managers Should Be Asking Now
In Korea, this problem comes with an extra layer of pressure. The decision to adopt AI comes down from the top of the organization, but the responsibility for making it work lands on frontline managers and solo operators — the one-person planners and strategists common in Korean companies. They end up in the position of having to design "how should our team actually use this?" entirely on their own.
The first thing to check in that position is whether the team's purpose for using AI is genuinely concrete. Words like "efficiency" or "encouraged use" are not purposes. The goal has to connect to a measurable outcome — "cut the time to draft a proposal to under 30 minutes," or "automate the data-gathering step of the weekly report." Adoption without a purpose leaves nothing behind but the license fee.
Next, ask whether you've actually mapped out, together, where in each team member's workflow this tool could slot in. If you work alone, it's worth experimenting directly with which step of your daily or weekly routine AI assistance genuinely helps. Even without a company-wide rollout, small integration experiments at the individual level can start right now.
Set the tolerance for failure in advance, too. When AI output gets used as-is and the result disappoints, the only thing standing between that moment and the conclusion "this is useless" is calibrated expectations. The first few attempts have to be treated as the cost of learning the tool. If you're a manager, you need to create that slack for your team. If you're working solo, you need to grant it to yourself.
The gap between the day the account is issued and the day the tool enters real work — organizations that designed how to fill that gap in advance, and those that didn't, will be standing in entirely different places six months later, having paid the exact same license fee. How you design the first few weeks decides whether the rollout succeeds or fails. This is not a technology problem. It's a design problem.
