When you bring AI into a company, tell your team before anyone asks what you are changing, what you are not promising, and when they will hear more. Skip the slogan that AI will replace nobody. In the Netherlands, 41% of working people already think AI could take over part of their job, and a team left to guess will guess the worst.
In most first team meetings about AI, the owner has spent weeks living with the project and the team has spent a few minutes. Nobody says the real question out loud, which is "does this have anything to do with my job?", so the meeting is spent answering a question that was never asked.
This essay is about the conversation that comes before the project. The business case is covered in what AI actually gives your team; this is about what the owner of a company of ten to a hundred people can say to the people who work there about AI and jobs, and what they should deliberately leave unsaid.
Will AI take my job? What your team already thinks
Start with what is known. Statistics Netherlands (CBS) asked Dutch adults with paid work whether AI could take over their job. Its 2025 survey, published in February 2026, found that 41% think AI could partly take over their work and 4% think it could take it over entirely. Roughly half said no. Treat the figures as dated: one survey, one year, and the tools have moved since. They still show the room you are walking into: not a team of panicking people, and not an untroubled one either. Close to half of it has already done the arithmetic on its own job.
Two details in the CBS data changed how I run these conversations. The first is that the belief is not concentrated among people who know nothing about AI. Of the workers who already use AI in their work, 56% think their job could be partly or entirely replaced. Among those who do not use it, the share is 37%. The second is the mood. Of the people who think AI can take over their work, 8% say they are very worried and 40% somewhat worried. The dominant feeling is concern rather than panic, and concern is the mood in which a clear, specific conversation actually works.
The first detail is the awkward one. The common reflex is to treat fear of AI as a knowledge problem: run a training day, let people play with the tool, and the worry fades. The numbers hint at something else. The people closest to the tool are the ones most likely to see what it could do to their own tasks. I read that as people paying attention, not as people who have misunderstood. Users may simply hold different jobs from non-users, so I would not build a theory on this. But I would not build a communication plan on "they just need to try it" either. You cannot train away an accurate observation. You can only respond to it.
Why is "AI will not replace anyone" a promise you should not make?
Because it is the sentence an owner most wants to say and is least able to guarantee. You do not know what your company will look like in three years. You do not know your customers, your margins, or the next version of the tools. A promise about a future you do not control has an expiry date, and the damage when it expires is larger than if you had never made it.
There is a second problem. A blanket promise is read as evasion. People who have thought about their own job for an evening do not believe that nobody is affected. They believe somebody will be, and that you are not telling them who. The more absolute the reassurance, the more rehearsed it sounds. I believe that in the typical small company the usual outcome is a few hours a week handed back to each person rather than a smaller team. But "typically" is a different word from "promised", and your team can hear the difference.
What I suggest instead is a scoped promise: narrower, shorter, and one you can keep. For example: "For the next twelve months this project is not a reduction plan. If that changes, you will hear it from me first, and you will hear it with notice." Whether you can say that depends on your numbers, not on your good intentions. If you cannot say it, say that instead: "I cannot promise that, and here is what I can promise." People tolerate a limited, honest promise far better than a large one that later turns out to be false.
What should you tell your team about AI before they ask?
I use a short list of five things, each of which can be said in a sentence or two. If an owner cannot say one of them, that is information about the project, not about communication.
- What is changing. One named process, in plain words. "We are going to try an assistant that drafts the first version of quotes" is a statement. "We are exploring AI-driven transformation" is fog, and fog is read as threat.
- What is not changing yet. Roles, contracts, working hours, who reports to whom. Say it only if it is true, and say for how long.
- What the freed time is for. Where the hours go. This is the question underneath every other question, and it gets its own section below.
- Who decides, and what the team can say no to. A named person owns the project, and the team can see the name. Anyone affected can say "this does not work for my part of the job" and be heard. I wrote about why that has to be one owner rather than a sponsor.
- When they will hear more. A date. Silence after the announcement is the second announcement, and people write it themselves.
Notice what is missing: enthusiasm. I do not ask owners to be excited out loud. The people most at risk from a pitch are the best at spotting one.
How do you talk to a Dutch team about AI without sounding like a sales pitch?
This section is specific to the Netherlands, and it comes from practice rather than research. In a Dutch company the question often arrives early, out loud, and from the person you least expected. Not everyone waits for a private moment. That is useful. A team that asks "and what does this mean for my job?" in the first five minutes has told you what the meeting is for. The polder habit of giving everybody a say before anything starts is not decoration here. It is the least expensive risk reduction available. Whether it travels to Flanders I cannot say from my own work, and the Belgian rules differ, as the piece on cao 39 and the three-month rule shows.
The practical consequence is to invite the question rather than defend against it. I put it on the agenda myself: "The first thing I expect you want to ask is whether this affects your job, so let's start there." It takes the pressure out of the room, because the thing everybody was waiting to say has been said by the person with the most power in it.
There is also a formal layer, and it only applies once a company reaches a certain size. Under the Wet op de ondernemingsraden (WOR), a Dutch company with at least 50 people must have an ondernemingsraad (OR). Article 25 of that law has the employer ask the OR for advice before an important decision, and the list includes introducing or changing an important technological facility (article 25, paragraph 1, under k). Whether a particular AI tool counts as important is a judgement for a labour-law adviser, not for me. Below 50 people the OR is not mandatory, and the team still has a voice, usually through staff meetings or a personeelsvertegenwoordiging.
What I add from practice is that the legal minimum describes when the OR hears, not when your colleagues should. By the time formal advice is requested, the corridor has usually been discussing the project for weeks. The consent side of this is covered in shadow AI and the right of consent, and the day-to-day side in why nobody can repeat your AI rule.
Can you introduce AI without layoffs? What happens to the freed hours?
Every worried question in the room is a version of this one. There are three possible answers, and an owner should know which one is true before the announcement. The hours can go into more work in the same time, which is growth. They can go into work that was waiting, which is the backlog: the follow-up call, the overdue quote, the file nobody has had time to tidy. Or they can leave the payroll, which is reduction. All three are legitimate business decisions. Only one of them can be hidden, and it is the one people suspect.
I ask owners to write the answer down per process, for themselves rather than for the team. The exercise often ends a confusion on the owner's side. Many find a backlog rather than a surplus: quotes go out late, customers wait for callbacks, the team has been coping for two years. There the honest message is "this gives you back time you do not currently have". It is also easier to believe, because everyone in the building can see the queue.
Where the honest answer is that less of this work will be needed, say so as early as you know it, in terms you can defend. In a small firm the usual mechanism is attrition: the vacancy that is not refilled, the temporary contract that is not renewed. Be precise about it. "When someone leaves the quoting team, we will first look at whether the work still needs a full replacement" is a sentence an owner can say without lying, and employees notice the difference between that and "no one is affected".
What do you say when someone tells you they are afraid?
Sooner or later one person will say it plainly: "I am afraid this will take my job." Three answers fail. The first is reassurance without information: "don't worry." The second is a pivot to the technology: "it's only a tool." The third is a change of subject to training. What works is slower and less comfortable. Acknowledge it, say what you know and what you do not, and give a date for the next update. "I cannot tell you what the company looks like in three years. I can tell you what this project does and does not do this year, and I will tell you the same day if that changes."
Then do the dull part, which is to keep the date. Trust in these projects is built almost entirely out of promises small enough to keep. A date for the next update, kept, is worth more than a good speech. Do not set a date you cannot meet.
How do you know the team still understands the project?
I use three questions, asked in the same words at day 30 and again at day 90, preferably anonymously. Do you know what this project is changing in your work? Do you know who to talk to when something about it is wrong? If your role were going to change, would you expect to hear it from me or somewhere else? None of this needs a survey tool. A show of hands or a paper slip does the job in a team of twenty.
What matters is the direction. If the number of people who say "I know" falls between day 30 and day 90, communication has stopped, whatever the model is doing. It is the same logic as in any failed adoption: the system can be perfectly healthy while the project quietly dies in the building.
Where can an outside AI consultant help, and where can't they?
An outside consultant can help with the conversation in two ways. They can tell you, before the announcement, what the project really changes, which is half of knowing what to say. And they can be the person who says "this part of the job will not be touched" with technical authority, because they know what the tool can and cannot do. What a consultant cannot do is have the conversation for you. Your team does not owe a stranger their trust, and they should not give it away. They owe it, conditionally, to the person who signs their contracts.
If you want a second opinion on what to tell your team before you commit, that is a normal part of the first weeks of working with an AI consultant for SMEs. If the project is too thin to justify the worry it will cause, I would rather say so in the first call than in the sixth month.
None of this makes the fear go away, and it is not meant to. The fear is mostly a reasonable response to an uncertain situation, and your team is entitled to it. What you are aiming for is smaller: a team that knows where it stands today, knows where to ask, and has no reason to fill the silence with its own worst case.
We build custom AI and LLM systems that run in production: a clickable MVP by the second call, fixed steps, and you own the code.
AI agency in the Netherlands →
