When the shift supervisor doesn't trust AI: how an FDE overcomes resistance in a pilot

Picture the third week of a pilot. The usage chart has started to fall. The shift supervisor still logs in but ignores almost every suggestion the model makes. At the start-of-shift meeting, an inspector asks outright: “Is this thing for grading us?”

This happens a lot. A 2026 survey by PwC and the Manufacturing Institute found that 62% of frontline workers are sceptical of AI and only 24% say they are excited about it. So the people who will actually use your tool probably start out suspicious of it, even after senior management has signed the contract.

For an FDE, this is your problem, not HR’s. Salesforce describes the FDE as someone who works closely with customers to clear blockers and speed up AI adoption. If the real users don’t trust the tool, that is a blocker too, and clearing it is part of the FDE’s job.

Every objection hides a specific worry

Engineers often make the same first mistake: they treat resistance as noise, a mood that will pass if they wait. In fact it is data. Prosci, an organisation that specialises in change management, says that frontline employees and managers grow more sceptical when they cannot see how AI reaches its decisions.

There is another fear that people find harder to say out loud. According to ITPro, employees who see AI as a way to monitor them stop engaging and look for ways around it. Then the improvement loop stops too. If nobody corrects the wrong suggestions, the model learns nothing from the shop floor.

So when you hear an objection, first work out the real worry behind it. You can take the table below with you on site.

What the user says	The real worry	What the FDE should do
“Is this machine for grading us?”	Being monitored	Keep correction logs out of individual performance reports, and say so plainly
“It’s just guessing”	Not understanding how the machine decides	Show the reasoning and confidence for every suggestion
“If the machine’s wrong, who takes the blame?”	Taking the blame for the machine’s mistakes	Make a person the final reviewer
“So how many of us will they need later?”	Losing their job	Raise this first, not last

The last row matters most. MindStudio advises tackling the fear of job loss first. If you avoid it, every training session that follows is a box-ticking exercise.

How a pilot gets rescued

Take a hypothetical example. An electronics components factory gives its 12-person QC team a trial of a model that reads images and suggests the type of defect. In the first week everyone is curious. By the third week, the share of suggestions marked “accept” has fallen sharply.

The timing is not a coincidence. Behavioural data from Worklytics, a company that sells analytics tools, often shows usage of AI tools dropping clearly after the third week, once the novelty wears off and the real friction shows up.

These are a vendor’s figures, so treat them as a reminder to be on the factory floor that week rather than at a desk watching a dashboard.

Your first move is to sit through a shift with the supervisor, not to sit down with senior management. In the PwC survey, 45% of respondents said AI initiatives at their company had failed partly because frontline leaders were not involved enough. The conversation might go like this:

FDE: Which defect type does the machine get wrong most often?

Supervisor: Scratches and dust. It calls dust a scratch, and a scratch means we have to scrap the part.

FDE: If the machine showed you where on the image it was looking, would that make the call easier?

Supervisor: Yes. But all the times the team corrects it, is anyone counting? Does it go on each person’s record?

FDE: Every correction is logged so we can retrain the model, but none of them are tied to anyone’s name in performance reports. That will be written into the project documents, and you can check.

That conversation gives you five changes, and the first three come straight from what the supervisor said. The first is the interface: show the image region the model relied on, its confidence level and a few similar past cases.

The second is who decides. The inspector is the one who confirms or corrects, and every correction becomes training data. The third is a written commitment that correction logs stay out of individual performance reports.

These three changes are also your case to senior management. As Prosci puts it, trust is built through transparency and human oversight. And when people review alongside the AI, it is clear who is accountable.

The fourth change is how you measure. People using the tool does not mean the pilot has succeeded. For a QC team, better measures are inspection time per batch, the number of defects that slip past inspection, and the share of inspectors’ corrections that end up in the next model.

The fifth change is to make one named person responsible for listening to frontline feedback during the first 90 days and acting on it. Put that person’s name in the plan, along with a weekly meeting with the supervisor.

Users need to see their feedback turn into updates. If they don’t, they stop giving it.

To scale, start with peers

Once the first team is on board, don’t rush to roll out across the whole factory. Worklytics suggests building a peer network of “champions”: find the people each team already listens to and train them more thoroughly before a wider rollout.

The night shift will listen more readily to an inspector from their own shift than to an engineer from outside.

The rest of the work happens inside your own company. Salesforce says its FDE team passes everything it learns on the front line back to product and engineering. Dust being mistaken for scratches is a model bug. The worry about being scored is a product design requirement, and it deserves a ticket.

Mistakes that slowly kill a pilot

The most common mistake is demoing to the boss and assuming the users have agreed. Next comes hiding how the model works because users supposedly “don’t need to know”. Then usage logs quietly turn into a staff league table, which is exactly the fear of monitoring that ITPro describes.

The other two are harder to spot. One is reporting usage counts as if they were value delivered. The other is collecting feedback and leaving it there, with nobody responsible for acting on it. All five mistakes have the same root. They treat frontline users as people who receive the product, when in fact they are helping to design it.

If you are preparing to move into an FDE role, look for phrases such as “user adoption”, “change management” or “work with frontline teams” in job descriptions.

On a CV, a line such as “after interviewing end users, added an explanation to each model suggestion; acceptance rate rose from X to Y” carries more weight than three lines listing frameworks.

For interviews, have a story ready about a time users pushed back and what you changed as a result.

Salesforce’s FDE director has warned that without FDEs, thousands of customers could stay stuck at the pilot stage. For the QC team in the example, what got the project unstuck was not a better model. It was someone willing to go down to the factory floor and ask the supervisor what was worrying him.