Building an AI Culture: Mindset Change

Organisations tend to underestimate resistance until they run into it. The tool is bought, an introductory session is held, and a few weeks later the usage report shows only a small part of the team has touched it. The manager concludes the tool was a poor fit, when the problem lies somewhere else entirely.

Employee resistance to AI is rarely technical. Someone who works with accounting software and messaging apps every day is not afraid of a text assistant; they are afraid of a consequence they have already pictured for their own job. Until that mental picture changes, no training course will make a difference.

Where the resistance comes from

Three roots sit behind most resistance. First, concern over one's standing: if the machine does the very work my value in the organisation is measured by, where do I stand tomorrow. Second, distrust of machine judgement; a specialist with years of experience will not readily accept the output of a system that cannot explain how it reached a decision. Third, ambiguity over responsibility: if the model's output is wrong, who answers for it? All three are reasonable questions, and slogans do not answer them.

Signs of a culture that is not ready

• The tool has been purchased, but voluntary usage is low and rises only when a manager reminds people.
• Staff either accept the system's output without review or ignore it altogether; neither is a sign of considered trust.
• Errors go unreported, because in the team's mind reporting an error means admitting incompetence.
• Nobody knows which role holds the final decision over what the model produces.

What only the chief executive can do

Mindsets do not change by memo. What works is a senior leader taking a clear and repeated position on one specific point: the purpose of this tool is not headcount reduction, it is lifting repetitive work off the people already here. If that sentence is spoken but the first saving in practice turns into layoffs, trust is gone for years. The commitment has to be verifiable, not merely verbal.

Why this is more delicate in Iranian organisations

In many Iranian small and mid-size firms, institutional knowledge sits in the heads of a few experienced people and has never been written down. Those same people have the strongest reason to feel threatened, because their principal asset is exactly the knowledge that is meant to move into the system. If they are not brought along, the project stalls not through open objection but through slow cooperation and incomplete information. The remedy is to give them genuine authority in designing the solution, not to route around them.

A three-month path to changing mindsets

• Month one: hold short one-to-one conversations with ten to fifteen people across teams and ask which part of their work wastes the most time. Publish the list so everyone sees the starting point came out of their own work.
• Month two: automate one item from that list with the direct involvement of the person who owns the work. Open access to a small group and ask them to report errors without worry.
• Month three: report the result to the whole organisation with numbers and without inflation, including what did not work. Then position that group as the internal reference point for the next wave.

Mistakes that destroy trust

• Presenting the tool as a productivity programme without explaining what the freed-up time will be spent on.
• Measuring staff on how much they use the tool; this produces performative usage, not real adoption.
• Hiding the system's errors to protect the project's image, which turns the first visible mistake into broad distrust.
• Handing the whole matter to IT, when the problem is organisational in nature rather than technical.

How to tell the mindset has shifted

The right measure is not the number of training sessions or attendance at them. Three signals say more: the share of voluntary use without managerial prompting; the number of new applications proposed by staff themselves; and the count of reported errors. The counter-intuitive part is that a rise in error reports during the early months is a sign of health, not crisis; it means the team feels safe enough to speak up.

Frequently asked questions

• Which team should we start with?
  The one with the most repetitive work and the least resistance; the first success should come easily so it can serve as a model.
• What if a key person objects?
  Make them a partner in the design and give them authority over where the acceptance thresholds sit; informed objection is an asset once it becomes review.
• How much formal training is needed?
  Less than people assume; a few hours of practice on a person's own real work does more than multi-day generic courses.

Takeaway

Culture cannot be bought, and it cannot be built by memo. What shifts a mindset is direct experience of one small improvement that staff themselves helped create. Start with one team, one repetitive task and one explicit commitment about what happens to the time saved; the rest follows.

Glossary

• Technology adoption: How much users genuinely and voluntarily use a new tool, regardless of how many were trained.
• Human in the loop: An arrangement where the system's output is approved by an accountable person before it is acted on.
• Psychological safety: An environment where raising an error or a disagreement carries no personal cost.
• Change management: The set of actions that turns an organisational change from a management decision into everyday behaviour.
• Executive sponsor: The senior manager who publicly owns the success or failure of an initiative.
• Task automation: Handing a specific repetitive task to software, as distinct from handing over an entire job.
• Explainability: A system's ability to show why it arrived at a particular output.