A significant AI tool is being rolled out across a function - meant to speed up a slow, manual part of the workflow. Adoption is stalling. Some employees are openly skeptical in meetings; more are quietly not using it at all.
MBA Lab is independent and is not affiliated with, endorsed by, or an official representative of Virginia Commonwealth University. This scenario is an original MBA Lab analysis, not an official VCU case or case solution - see the FAQ below.
The conventional response
Treat this as a communication and change-management problem: better messaging, mandatory training sessions, adoption targets tied to performance reviews, and public recognition for early users. The underlying assumption is that resistance is mostly about unfamiliarity or inertia, fixable with enough push.
This response works for the fraction of resistance that really is just inertia or unfamiliarity - and does nothing for the rest, because it never asks why people are actually hesitant before trying to overcome it.
The poorly executed people-first response
Hold listening sessions, genuinely invite concerns, and then respond with broad reassurance - "no one needs to worry" - without actually engaging the specific productivity, role-change, privacy, or workforce questions that were raised. The sessions feel participatory. The underlying concerns go unaddressed.
This version can be worse than not asking at all, because it creates the expectation that concerns were heard and will shape the outcome, then visibly doesn't change anything.
A response that segments resistance instead of treating it as one thing
Actually segment it, because "resistance" is usually several different things wearing the same expression: a legitimate risk concern (data handling, output quality, liability), fear of job loss, a real skill gap, a genuine workflow mismatch (the tool doesn't actually fit how the work gets done), an ethical objection, a status threat (expertise that suddenly feels devalued), or simple inertia. Each needs a different response - lumping them together is most of why the conventional response fails.
Share the actual business case, including its limits. What the tool is expected to do, what it isn't good at yet, and what's genuinely still unknown - rather than a confidence level the organization doesn't actually have.
Include affected employees in workflow design and risk review, not just in a listening session after the design is already final. People closest to the actual work usually spot failure modes a rollout plan misses.
Establish real guardrails: human oversight on outputs that matter, clear data governance, quality checks, an escalation path, and a genuine process for reporting when the tool gets something wrong or causes harm.
Pilot in stages and publish what's actually being learned - including the failures - rather than a single big-bang rollout with adoption metrics as the only signal.
Invest in real capability building, not a one-time training session, for the skill gap segment specifically.
Be honest when roles may change. If the tool is expected to shift what some jobs look like, saying so directly - even without every detail resolved - holds up better over time than vague reassurance that later turns out to have been misleading.
How mindfulness shapes this
Leadership enthusiasm about a new tool can itself become a bias - a leader excited about the tool's potential can become quietly defensive toward critics, reading legitimate concerns as mere resistance to change. Noticing that enthusiasm bias, and treating skepticism as potentially useful information rather than an obstacle, changes what actually gets heard.
How care shapes this
Care means taking seriously that this isn't only a productivity question for the people raising concerns - it can touch identity (a skill that took years to build), livelihood, privacy, fairness in how the tool is applied, and downstream effects on customers or clients. Waving those away as "just resistance to change" fails to take the concern on its own terms.
How accountability shapes this
Accountability means adoption happens where it's actually justified by evidence, not adoption for its own sake; outcomes get measured honestly, including negative ones; the risk controls set up during rollout are actually enforced; and there's a real decision process for what happens if the tool underperforms - including scaling it back, which a pure adoption-target mindset makes hard to do gracefully.
Risks and tradeoffs
Participatory processes can become symbolic if they don't visibly change anything about the plan - which erodes trust faster than not doing them at all. Moving carefully and inclusively takes real time, and competitors moving faster is a genuine, not imagined, cost of that choice. And no leader can honestly promise zero job displacement or perfect safety from a new technology - the credible version of this conversation is honest about that uncertainty rather than promising a certainty that doesn't exist.