AI training for a non-technical team: how to run it so somebody uses it on Monday

An engineering team hands the trainer three things for free: a shared repository, a shared vocabulary and a test that goes red when something breaks. A newsroom, a sales team, HR and a design studio have none of them. A programme that ignores that ends in a pleasant day and zero change on Monday.

I know both sides of this transaction. I run these sessions, and before that, as a CTO, I sent my own departments to other people's. Then I checked what was left a week later. Enthusiasm and a few links were left, and the work went on as before.

Below I describe how such a room differs from a team that writes code. Then the way I pick the one task the whole day is built around. Then the line between a sceptic and a blocker, because for the first half hour they look identical. At the end: the session at the TVP Television Academy, the list of failures that ruin a day like this, and a test you can run before you order anything.

Why a room without engineers is harder

The missing red signal hurts most. A developer gets a red pipeline and knows immediately that the model made something up. A journalist gets a smooth paragraph that reads as credible. The only filter is her own knowledge of the subject. So I build the exercises on material the participants know by heart. On somebody else's example nobody catches the error, because there is nothing to compare it against. What a document looks like after travelling that whole way without a single signal, I took apart as nine classes of error in a publicly funded report written with AI.

The second difference is the stake. An engineer asks straight out whether the tool will speed up the work, and wants to see numbers. A team whose work lives in documents asks a different question, usually in the corridor: is somebody counting on needing fewer of us after this. A day that pretends nobody is thinking about it loses the room at the first coffee break. It looks different on the technical side, where the workshop runs on the team's own repository and the argument of the day is where an agent's autonomy stops.

The third is the mix. One session seats several professions and several different jobs. An exercise cut for one of them bores the rest. So I ask each group for input material before the date and prepare the task in variants. Same working pattern, a different file on screen.

One task instead of twenty tools

A tour of twenty tools looks rich in the agenda and disappears within a week. People remember names they have no way to run, because the company bought one seat for one tool. So I build the whole programme around a single task. I pick it before the session, together with the buyer, and it has to meet three conditions.

That filter cuts out most ideas that sound attractive on a slide. One task and one tool are left, sometimes a second as a fallback. In a newsroom it is cutting a long piece down to a trailer. In sales it is the first draft of a reply to an enquiry. In HR it is a job description built from a recruiter's notes. The rest of the catalogue goes into the post-session materials, where it bothers nobody.

Somebody always asks whether that is too little for a whole day. I answer from the other side of the ledger. A day of the whole department costs more than the invoice for the training. Only a task everyone repeats every week can pay that back. Twenty tools that nobody stayed with pay back nothing. The same mechanism works one floor up, at company level, where one delivered process beats a list of a hundred initiatives.

A participant leaves with a saved prompt that works on their own material, and with one sentence about what they will not hand to that tool. Both go into a shared document while everyone is still in the room. A document with no owner dies in the second week, so I ask for a name before the day is over.

A sceptic and a blocker look identical for the first half hour

Both sit leaning back, both keep their hands off the keyboard, both drop a remark about having seen this somewhere already. The difference shows up at the first exercise.

A sceptic asks about things that have an answer. Where did the model get this. What happens when it puts down the wrong name. Who signs off on text that came out of a chat window. Those are good questions, usually the best ones asked all day. The sceptic is an ally and does not know it yet. I answer precisely, next to him, on his own example. Once he gets a hard answer, he turns into the most demanding participant in the room and pulls the rest along.

A blocker asks about things that have no answer. Whether AI will destroy the profession. Whether any of this is ethical. The conversation runs on assumptions and never ends, because there is no way to settle it. The test is simple. I give a concrete task and watch. The sceptic starts doing it and within a moment says what does not add up. The blocker keeps talking.

I do not win an argument with a blocker in front of the room, and I do not try. I name the topic, write it on the board and book ten minutes after the last exercise. That conversation is calmer, because by then the person has seen something on their own material. A public win costs more than it is worth. You win the argument, you lose the participant, and the rest of the room remembers that this is a place where people get lectured.

Sceptics deserve one more thing. I plan the tool's failure into the programme instead of waiting for it to surface on its own. I ask participants for a question from their own field, one the model should fail. It usually fails. Then we take the answer apart: what is true, what merely sounds true, and how to tell the difference without leaving your desk. That moment buys attention for the rest of the day, and along the way it explains why the smoothest answer sounds the most certain.

The TVP Television Academy: a room in Warsaw and branches across the country

In December 2023 I ran a session for the TVP Television Academy called "Using artificial intelligence in journalistic work". The Academy described it on its own site like this: Szymon Paluch "introduced journalists from Warsaw and TVP branches across the country (via streaming) to the world of chatbots". Two sentences, and both things this piece is about follow from them: an audience that is non-technical by profession, and a hybrid format.

The photo at the top of this post comes from that day. One thing in it matters: the trainer has two audiences at once and can see only one.

A studio changes the risk list before the programme even starts. The picture from a laptop usually goes through a vision mixer there. The fallback then stops meaning "swap the cable". Changing the source is somebody else's decision, taken in another room. I agree it before the start, together with the signal I will use to ask for it. In an ordinary conference room the same problem is solved by one HDMI cable.

Hybrid adds a second audience that cannot interrupt. A person in the room raises a hand and asks. A branch at the other end of the line writes in the chat and waits. With that format I assign the chat to one named person in the room, and I ask the remote side by name at agreed moments. I also add hard checkpoints: whoever finishes the exercise types one word in the chat. Without them the trainer tunes the pace to the audience he can see, and the other half falls behind and never catches up.

Exercises in a hybrid also have to work solo. Working in pairs and glancing at the next screen works on one side of the line only. So every task gets a written instruction on the slide and can be done alone, without asking. The demo runs in one window at a large font size, because video compression eats everything below that.

Six things that ruin a day like this

The programme for a non-technical department comes together in one evening. The rest is the hard part, because a room like that cannot work around a failure with its own hands. Nobody will switch to another model over the API, nobody will run it locally, nobody will get around the corporate proxy. When the tool does not come up, the exercise simply does not happen. Nobody gets that day back, because no one will convene the whole department a second time.

• • The tool is blocked. The corporate proxy lets the login page through and cuts the calls to the model. It looks like a working tool until somebody sends the first message.
• • Accounts the participants do not have. The licence tends to be bought for the buyer and a few people on the board. The rest of the room hits a sign-up screen with phone verification and half of them will not hand over the number. They are right.
• • The guest network. It holds a few laptops and sags under a whole department, because nobody ever loaded it like that. You spot it when the exercise runs in the front rows while the back rows wait.
• • The live demo. The model answers slower than yesterday, the vendor moved the buttons in an overnight update, the plugin asks for a fresh login. Each of those alone is minor. With the projector on, each one costs the credibility of the whole day.
• • Sensitive data on screen. A participant pastes a real contract or a real client email, because that is what their work looks like. They do it in front of the room, sometimes in front of a camera. It is the most expensive failure on the list, because it does not end when the session does.
• • The gap between the room and the stream. People in the room answer out loud. The people on the other end of the line see the back of somebody's head and hear half a sentence. Within fifteen minutes they stop trying and go back to their inbox.

So before I confirm a date I send four questions, and all of them go to IT rather than to the buyer. Do these specific domains get through the corporate network, from a corporate laptop, in this room. Who has an account and of what type. Who in the room has admin rights and will pick up the phone during the day. And what may be pasted into the tool.

On that last one, "probably nothing sensitive" is not an answer. I want one sentence from the person accountable for it, and I then put it on a slide so the room has it in front of them all day. Sometimes nobody in the company can write that sentence. The problem is then older than the training, and it comes back afterwards twice as loud. I wrote separately about who should write those rules down and keep them alive.

The demo itself I prepare in three versions: live, as a screen recording of the same run, and as screenshots in step order. In the morning I walk through all of it again, on that connection and on that laptop. The demonstration material is synthetic and looks like a document from that industry, so it teaches the same thing and carries nobody's data onto the screen. The phone sits next to the laptop with the hotspot on.

What is left after two weeks

One day gives people a skill and a first habit. It does not change the process, because a process changes by decision, and decisions are not taken in a training room. So before the date I ask about three things. Who on your side will say that this is how we work now. Where will that be written down. When will somebody check for the first time whether people actually do it.

Two weeks later, count how many people used that one task at least once a week, and ask them what they improved compared with their first attempt. The number of uses says more than a survey score, because a survey measures the day itself and comes out high even when nothing was left. If fewer than half the room is using it, the obstacle is usually access or a missing sign-off on the material.

One day will not build a layer of people who invent their own uses either. That is separate work, spread over months and roles, and I described it while writing about the three levels of readiness in a team. A training session sets up the first of them and nothing beyond that.

Before you order anything, run a test that takes ten minutes. Take a corporate laptop, get on the corporate network, open the tool that is meant to be used in the session, and log in with the kind of account the participants will get. Then ask three people on the team for one task they do every single week that involves writing or reading text. Four steps that pass and three concrete answers mean the programme will write itself. Anything else means the first hour of the conversation goes on process and access, and we set the date after that.

Frequently asked questions