Most digitalization projects do not fail because of the software. They go wrong in the first weeks, when people learn about the change from a corridor conversation and fill the gaps with the worst version. By the time the official announcement arrives, trust is already lower than it needs to be.
This article is for a managing director or a change lead who is about to tell a team about a new system, a process moved from paper or spreadsheets, or a custom tool. It covers the first meeting only: what to say, what to promise, and how to answer the questions that come. For the longer view, see change management for technology adoption.
Before the meeting
Decide three things first, because staff will ask about all of them.
- What problem the project solves. One sentence, in terms people recognise: "orders are retyped three times" is better than "improving operational efficiency".
- Who is affected and roughly how. Name the teams and the tasks, not the whole company.
- What is still undecided. Write it down. It is much easier to say "this is not decided" if you have already admitted it to yourself.
If the project came out of a process review, bring the same evidence you used. If you are still choosing where to start, scoring candidates by hours, errors and owner gives you language that staff can follow.
Tell line managers a day earlier. Nobody should hear it first from their team.
The first meeting: four parts
Keep it to 20–30 minutes, with time left for questions. Do it in person or on video, not by mail alone.
1. Why
Start with the problem, not the tool. Use an example staff will recognise from their own week. Avoid slogans. Say who asked for the change and why now.
2. What changes
Describe, in a few sentences, what will be different in daily work once the project is done. Be concrete: "orders will be entered once and visible to the warehouse", not "processes will be streamlined". If you cannot yet say, say so and give a date.
3. What does not change
This is the part leaders skip and staff listen for. Name what stays: the team structure, the customer contacts, the responsibilities that are not part of the project. Include only what you have actually decided. If you are not sure, leave it out.
4. What happens next
Give the next three steps and the date of the next update, even if the update is "no news". Explain how people can take part: describing how the work really happens, testing early versions, or naming the awkward cases the system must handle.
What to promise, and what not to
Promise things you control:
- A date for the next update, and keep it
- A named person and a place where questions can be asked, also anonymously if that helps
- Involvement of the people who do the work in testing before the change goes live
- Time for training during working hours
Avoid promises you cannot keep:
- "Nothing will change for you." Something will, or you would not be doing the project.
- "Nobody will lose their job." Say this only if the decision has been made and you are able to stand behind it. If it has not, say what you know.
- "It will be easy." Rather say that it will take some getting used to and that support will be there.
- Exact dates for the whole project before the plan is tested.
Five questions that always come
Prepare short, honest answers. Here are the typical ones and a sensible shape for each reply.
1. "Will I lose my job?" Answer directly. If the aim is to remove repeated manual work and no reductions are planned, say so, and say it is a decision you have made. If you do not know, say what you know and when you will know more. A vague reassurance is worse than an honest "not decided".
2. "Will this mean more work for me?" Usually, yes, for a short time: learning, parallel running, entering data twice during the switch. Say it, and say what you will do about it, for example by moving other tasks or planning the switch outside the busiest weeks.
3. "Who will teach me how to use it?" Describe the plan, even a simple one: who trains, when, how long, and what happens if someone misses it. Mention that training is in working time.
4. "Why can't we keep doing it the old way?" Return to the problem from part one. Then explain how long the old way will remain available. A short overlap helps, but without an end date it becomes two systems forever.
5. "Who do I ask when something doesn't work?" Give a name or a channel, not "IT". In the first weeks after go-live, staff should have a quick way to reach someone who can help.
If a question has no answer yet, write it down in the room, and send the answer to everyone by the date you named. For a longer discussion of building trust before a launch, see explaining an AI agent to employees; the principles apply to any new system.
After the meeting
- Send a short written summary the same day: the problem, what changes, what does not, next steps, the date of the next update
- Collect questions you could not answer and publish the answers together
- Talk to the two or three people most affected, one to one, in the following week
- Keep the update date. Silence after a first meeting is read as bad news
Common mistakes
- Announcing by mail only. There is nobody to ask, so people ask each other.
- Starting with the tool name. Staff care about their work first.
- Over-reassuring. One broken promise costs more trust than ten honest "I don't know yet".
- Telling only managers. The people who do the work know the awkward cases and should be asked.
- Going quiet. Missing the promised update is more damaging than having no news.
Checklist
- Write the problem in one sentence that staff recognise
- Decide what is fixed and what is still open
- Tell line managers a day before
- Prepare four parts: why, what changes, what does not, what next
- Prepare honest answers to the five questions
- Promise only an update date, a place for questions, involvement and paid training time
- Send a written summary the same day
- Keep the update date
Sources
- Our related articles linked above.
- The meeting outline and answers are a working practice, not a standard; adapt them to your company and to what has actually been decided. No client results or market figures are claimed in this article.
