What we learned training sceptical construction teams on AI
The scepticism in the room is the most useful thing in it. Construction people have watched software arrive with fanfare and die in a folder, sat through training days for platforms nobody used, and can smell a salesman three rooms away. Train against that instinct and you lose. Train with it and the adoption sticks.
Worth saying early: none of this is a substitute for the formal competence and training obligations the industry already carries, whether through CITB or the competence requirements now written into the building regulations regime. AI training sits alongside those, not in place of them.
Why start with their Tuesday rather than the technology?
Because nobody in the room cares what the technology is, and opening with it is the fastest way to lose them.
Open with the worst recurring hour of their week instead: the Friday report, the 47 consultant comments, the RAMS pack needing briefing, the minutes owed since Monday. Then do that task live, with their material. Not a polished demo file. Their actual tender, their actual minutes, warts and all.
The moment a site manager watches his own rambling voice note become a clean, structured diary entry, the conversation moves from whether to how. That is also why the site diary is such a good first workflow: the before and after are visible in ninety seconds.
Why deliberately let it fail in front of them?
This is the counterintuitive one, and it is the most persuasive part of any session: the tool gets something wrong and you point at it.
Sceptics do not trust a tool that claims to be perfect, because nothing in their world is. Show them a confident wrong answer, show them how a reviewer catches it, and you have taught the two lessons that matter simultaneously: this is genuinely useful, and it still needs you.
Construction professionals grasp that pairing instantly, because it is exactly how they already treat a keen graduate. Valuable output, checked before it leaves the door. The trust that survives seeing a failure is the only kind that lasts past the first week.
What are they actually asking when they push back?
Not resistance. Professional instincts that keep buildings standing. Each deserves a straight answer rather than a reassurance.
| What gets asked | What is actually being asked | The straight answer |
|---|---|---|
| "Is this confidential?" | Where does our data go, and who sees it? | Named tools, named tiers, explicit red lines on what never goes into a public tool |
| "Who is liable when it's wrong?" | Am I carrying the risk for a machine? | A named person signs off every material output. The tool never carries responsibility |
| "Is this coming for my job?" | Is my expertise being devalued? | The tasks going are the ones you complain about at every appraisal |
| "We tried software before" | Will this die in a folder like the last one? | Fair. Measure it at one month and kill it if nobody is using it |
On the third row, be honest rather than soothing. In our experience the person most relieved by automation is the one currently drowning in the admin, and the person most threatened is usually the one whose value was the filing.
Where is adoption actually decided?
In the fortnight after the session, not in the session. And it is decided by friction.
Everyone leaves with two or three specific uses for their own role, set up and working, not a list of possibilities. There is one named human they can ask daft questions of without an audience. Someone collects early wins and circulates them, because a QS hearing that another QS saved four hours lands considerably harder than anything a trainer says.
Then measure a month later: who is still using it, on what, saving how long. If the answer is nobody, the training failed, whatever the feedback forms said. That is the same adoption signal that decides whether a pilot worked, and it is equally unsentimental.
What does a successful room look like?
Not a room of enthusiasts. Enthusiasm fades and it was never the goal.
The goal is a room of professionals treating AI the way they treat any other tool of the trade: knowing what it is for, what it is not for, and how to check its work. Scepticism taken seriously converts into exactly that, which is why the rules on what goes in which tool belong in the training rather than in a policy nobody reads.
We would rather train a hostile room of thirty-year site veterans than a friendly room that agrees with everything. The veterans, once convinced, stay convinced, and they bring the rest of the site with them.