A familiar complaint is making the rounds in leadership meetings: “Our employees are resistant to AI.”

That diagnosis is often too convenient. In many organisations, employees are not refusing to use AI. They are being asked to add another tool to an old workflow, meet the same targets, complete the same deliverables, and trust that the consequences will somehow be positive.

That is not an adoption strategy. It is a software rollout layered onto unchanged work.

The practical question is not, “How do we get people to use this tool?” It is:

What should change in the work, the measures, and the employee’s role if this tool is genuinely useful?

Until leadership answers that question, AI activity can become productivity theatre: visible tool usage without meaningful operational improvement.

The myth of employee resistance

When employees hesitate, leaders often interpret the behaviour as fear, laziness, or a lack of technical confidence. Sometimes training is the proposed solution: schedule a workshop, distribute a prompt library, and ask managers to monitor usage.

Training can help people operate a tool. It cannot resolve a badly designed process.

Consider a sales team that receives an AI assistant for account research. Before the rollout, a salesperson might spend an hour reviewing a prospect’s website, CRM history, and recent communications. After the rollout, the business expects the salesperson to use the assistant — but keeps the same lead target, the same reporting requirements, the same research process, and the same approval steps.

The tool may reduce research time. But what happens next?

  • Does the salesperson spend the recovered time on better discovery calls?
  • Does the team qualify more carefully and pursue fewer weak opportunities?
  • Does the manager change the quality measure from activity volume to qualified pipeline?
  • Does anyone remove the manual reporting that the tool has made unnecessary?

If the answer to each question is no, the employee has been given more responsibility without a meaningful change in the system around them. Even a useful tool can feel like extra work.

This is why apparent resistance can be rational. Employees are assessing the likely impact on their workload, performance reviews, and job security. If management says AI will save time but then fills that time with more low-value tasks — or uses the tool primarily to scrutinise output — the message is inconsistent.

The problem is not that people need to be persuaded harder. The problem is that the organisation has not designed a better version of the work.

AI adoption is an operational redesign project

A reliable implementation starts with the workflow, not the software licence.

Before choosing or deploying a tool, map how the work happens today. Identify:

  1. The trigger that starts the process.
  2. The people involved and the decisions they make.
  3. The information each person needs.
  4. The repeated tasks, handoffs, and approval points.
  5. The delays, rework, and quality problems.
  6. The KPI currently used to judge performance.
  7. The step where AI might remove a bottleneck or improve a decision.

Take a customer-support process. A ticket may move from intake to categorisation, then to assignment, investigation, response, quality review, and closure. An AI tool might classify incoming tickets and draft responses. But simply inserting it into the process leaves important decisions unanswered:

  • Who checks the classification before assignment?
  • Which tickets require human investigation?
  • What level of confidence is acceptable for a draft response?
  • Is the team measured on tickets closed, response speed, resolution quality, or customer retention?
  • If categorisation becomes faster, should the team handle more volume or spend more time preventing repeat issues?

Those are operating decisions, not training questions.

A useful implementation changes at least one of three things: the sequence of work, the allocation of responsibility, or the way success is measured. If none of those changes, the tool may still offer convenience, but it is unlikely to produce a material operational shift.

The structural authority trap

Many organisations assign AI enablement to IT or HR because those departments already manage systems, training, or policy. That can be sensible for governance and support. It is often insufficient for redesign.

IT can provision access, manage security, and integrate software. HR can support role descriptions, learning, and employee communication. Neither function necessarily has the authority to rewrite how sales, operations, finance, or customer service actually works.

A workflow redesign usually requires decisions across multiple functions. Someone may need to change:

  • A department’s targets.
  • The sequence of approvals.
  • The division of responsibility between roles.
  • The definition of acceptable quality.
  • The information recorded in the CRM or operational system.
  • The way managers review performance.

If the AI initiative owner cannot make or secure those decisions, the project becomes a coordination exercise. The organisation buys access, runs pilots, and reports usage while the underlying process remains untouched.

AI ownership should therefore sit with a leader who can convene the affected functions and change the process — not merely manage the software. In a smaller company, that may be the operations lead or a department head with explicit executive sponsorship. The important point is authority, not title. When there are competing constraints, stakeholders, or implementation risks, you can use the Strategic Decision Adviser to compare the available paths before committing to one.

The owner should be accountable for a business outcome such as shorter quote turnaround, fewer preventable support escalations, or better-qualified sales opportunities. “Number of employees trained” is an enablement measure, not an outcome.

Productivity theatre and the trust problem

Productivity theatre occurs when an organisation wants the appearance of AI adoption without making the harder decisions that adoption requires.

Common signs include:

  • A mandate to use AI without a defined business bottleneck.
  • Reports on prompts or tool logins instead of process outcomes.
  • New AI tasks added while old manual tasks remain.
  • Productivity gains used to justify higher workload rather than better work.
  • Employees encouraged to experiment while being given no protection from mistakes.
  • Managers using AI activity as a proxy for commitment.

These practices create a low-trust environment. Employees reasonably wonder whether recovered time will be reinvested in higher-value work, converted into additional administrative demands, or used to reduce headcount.

That concern cannot be solved by telling employees to “embrace change.” It requires a specific operating commitment.

For example, a team might agree that time recovered from drafting routine proposals will be redirected into customer interviews, account planning, quality checks, or process improvement. The manager should define how that work will be prioritised and measured. Otherwise, the promise of saved time remains abstract.

Leaders also need to acknowledge what will not change. Not every task should be automated. Some decisions require context, accountability, or relationship skills that a tool cannot provide. Clear boundaries can build more trust than broad claims about transformation.

A practical implementation sequence

Use the following sequence before rolling out another AI tool.

1. Choose a bottleneck, not a fashionable use case

Start with a measurable operational problem: slow proposal creation, inconsistent lead qualification, repetitive internal reporting, or excessive ticket triage.

Avoid starting with “Where can we use generative AI?” That question produces a long list of experiments. Start with “Where is work delayed, duplicated, or unnecessarily expensive?”

2. Document the current process

Ask the people doing the work to walk through a recent example from beginning to end. Record the inputs, decisions, handoffs, exceptions, and rework. Do not rely solely on the official process map; the informal version is often where the real friction lives.

3. Define the future workflow before selecting the tool

Specify what the tool will do, what it will not do, and where a human remains accountable. Write the process in plain language so that a new employee could follow it without knowing the technology behind it.

4. Change the KPI at the same time

If the workflow changes but the KPI does not, employees will continue optimising for the old system. For instance, if AI reduces the time required to create a first draft, measure proposal quality, conversion, or turnaround time — not simply the number of drafts produced.

5. Decide how recovered time will be used

Make the reinvestment explicit. Assign the time to a defined activity, such as deeper customer research, proactive retention work, quality assurance, or training. If the business intends to increase capacity, explain how and why.

6. Pilot the complete workflow

Test the process from input to outcome, not just the AI step. Include exceptions, approvals, data quality issues, and human review. A successful draft-generation demo is not evidence that the end-to-end process works.

7. Review behaviour and outcomes together

Track adoption signals, but do not confuse them with value. Review whether the new workflow reduced delay, improved quality, lowered rework, or changed commercial results. Also ask employees what new friction the process introduced.

What can still go wrong

Workflow redesign is more demanding than buying software. It requires cross-functional authority, time from experienced employees, and a willingness to change established measures. A department manager may understand the problem but lack permission to alter targets or responsibilities.

There are also cases where AI is simply the wrong intervention. If the underlying issue is poor data, unclear decision rights, inadequate staffing, or a broken approval policy, adding a model may make the process harder to understand without solving the cause.

Another failure mode is redesigning too much at once. A company can create so many new procedures, controls, and role changes that employees cannot tell what is expected. Start with one important workflow, define the boundaries, and expand only after the new operating pattern is stable.

Finally, not every benefit will appear immediately. Some changes improve quality or reduce risk rather than producing a visible short-term productivity gain. That makes the baseline and the chosen outcome especially important.

Buying an AI tool is easy to describe. Adopting AI means changing how work is assigned, performed, reviewed, and valued.

Before the next software demonstration, map the workflow it is meant to touch. Identify the bottleneck, the KPI that should change, the work that will replace the time saved, and the person with authority to make those changes. If those answers are missing, the organisation is not ready for a rollout. It is preparing another layer of productivity theatre.