Lesson 6.4: Training users and driving adoption

Software nobody uses changes nothing. Learn why people resist, how adoption spreads, how to train on real tasks and how to measure whether behaviour changed.

By the end of this lesson you will be able to plan how a customer's people will start using what you built, and stay using it. You will learn the main reasons people do not adopt a new tool, how adoption usually spreads through a group, how to design short training around real tasks, how to build a network of champions, and how to measure whether anything has changed beyond the attendance sheet. You will see three rollouts, one of which stalls, and use a simulator to see how much follow-up support is worth. This lesson closes Module 6, on customer communication, and with it the middle of the track. It builds on the handover of Lesson 5.4 and the communication skills of 6.1 to 6.3. Everything you have built so far matters only if the people it was built for use it, and this lesson is about making that happen. You need no technical background.

Lesson 1.1 put the finish line of the role at the point where the customer's people are getting value from something running in production. A system that is deployed, monitored and handed over, and then ignored, has not crossed it. The software works, the dashboard is green and the customer's results do not move, because the callers still work from their old spreadsheets, the nurses still phone each other and the analysts still export the data by hand. Many technically successful projects fail in just this way. They deliver a tool and not a change in how people work, and the change is where the value is.

The real goal is changed behaviour

Training is usually planned as an event: a session, a manual, a video. But the aim is not that people attend or even that they understand. It is that they do something differently, every day, after you have gone. That reframes the task. You are not teaching a product. You are helping people change a habit, and habits resist change.

It helps to state the goal as a behaviour, in the same style as the aim of a demo in Lesson 6.1: "Callers start each morning from the sorted list, not from their own spreadsheet." "Bed managers check the screen before they phone another ward." "Support agents read the drafted reply and the quoted source before they send." Each is something you could see someone doing. If you cannot describe the behaviour you want, you cannot measure whether it happened.

Why people do not adopt

When a new tool is not used, the reason is rarely stupidity or stubbornness. It is usually one of a handful of understandable causes. Knowing them lets you ask the right questions.

They do not know how. The training was too short, too abstract, or too long ago. They tried once, got stuck and went back to what works. They do not see the benefit. The tool helps the organisation, but what is in it for the person? If it adds work for them and saves it for someone else, they have little reason to use it. It is harder than the old way. Even a better tool has a cost at first: new steps, a slower start, a screen they do not know. If the old way is familiar and quick, it wins under pressure. They do not trust it. If the tool gave a wrong answer once, or they cannot see why it says what it says, they check everything by hand, which removes the saving. They fear it. Of being measured by it, of being replaced by it, of being blamed when it is wrong. These fears are often unspoken. The incentives point elsewhere. If people are rewarded for something the tool does not support, such as the number of calls rather than the number of payments, they will do what is rewarded. Their manager does not use it. People copy what their managers visibly do. A tool the boss ignores is a tool the team can ignore. There is nowhere to get help. A small problem in the first week, with nobody to ask, becomes a reason to stop.

These are different problems and need different cures. Repeating the training does not help someone who fears being measured. A better interface does not help someone whose manager does not use the tool. The first task in adoption is therefore diagnosis: find out which causes apply to which people.

How adoption spreads

Adoption in a group does not happen all at once. A well-known description comes from the researcher Everett Rogers, in his work on the diffusion of innovations. He observed that people take up new things at different times and described five groups: innovators, about 2.5 per cent of eventual adopters, who like to try new things; early adopters, about 13.5 per cent, often respected people who adopt early when they see a real benefit; the early majority, about 34 per cent, who adopt when they have seen it work for others; the late majority, another 34 per cent, who adopt when it is becoming normal or necessary; and laggards, about 16 per cent, who change last, if at all. The percentages are the standard ones, and other sources give looser ranges, so treat them as a rough picture and not a measurement of your customer's team.

The practical lessons are these.

Start with the enthusiasts, but do not stop there. Innovators and early adopters will try almost anything, and they give you feedback and early wins. They are not typical, and their enthusiasm does not tell you how the majority will react. Respected early adopters matter most. The early majority look to people like them. When a well-regarded colleague says "this saves me an hour a day", others listen far more than they do to the vendor. Find these people, help them succeed and let them tell the story. The large middle needs proof and ease. They adopt when they have seen it work for others in similar jobs and when using it is not hard. Peer stories and a smooth first week matter more than features. The late majority and laggards need a different approach. They may adopt when the old way is withdrawn, when their manager asks, or when they see that most others have moved. For some, the right response is patience and support, not pressure. Do not judge by the early signs alone. A strong start with the enthusiasts can mask a stall in the middle. Look at who is using it, not just how many.

Plan the rollout in waves

Because adoption spreads, roll out in waves instead of to everyone at once. A typical shape is a small first wave of a team or a branch that includes some enthusiasts and some doubters; a second wave of several teams, with lessons from the first; and then everyone. Each wave improves the training, the guide and the tool.

Choose the first wave deliberately. Include a respected person who will give honest feedback, a manager who will use the tool visibly, and at least one sceptic, because their objections are the ones the later waves will raise. Avoid starting with the team that is most enthusiastic only, because you will learn too little, or the most hostile, because you will learn the wrong lesson.

Training that works

Most corporate training is a presentation: a person talks through screens, while the audience watches. It is easy to organise and poor at changing behaviour. People remember a small share of what they hear, and almost nothing of how to do a task they have not tried. A few principles make training far more effective.

Train on real tasks, with real data. Instead of touring the menus, give people a task from their own day and let them do it: "Here is this morning's list. Sort out the accounts you would call first." Working on realistic material is how skills and confidence form.

Keep it short and focused. Thirty to forty-five minutes on one task is better than a half-day on everything. People can absorb only so much, and a long session invites distraction. Several short sessions, spaced out, beat one long one.

Let people practise, not watch. The proportion of time spent doing should be much larger than the proportion spent listening. A sandbox with safe, fake data lets people make mistakes without consequence, which is how they learn.

Teach the first week, not the whole system. Identify the three or four tasks people will do in their first week, and teach only those. Advanced features can wait until the basics are habit.

Give them something to keep. A one-page quick guide with screenshots of the main tasks, or a short recording they can replay, is used far more than a manual. Put it where people will look: on the screen they use, pinned in the chat, printed beside the desk.

Make it easy to ask. Tell people exactly where to go with a question in week one, and make sure that someone answers quickly. A fast answer to a first-week question is among the best investments in adoption.

Train the managers first. If managers understand the tool, use it and can answer their team's questions, adoption follows. If they have not been trained, their teams will notice.

Train at a good time. Not during the busiest hour, and not as an extra after a long day. Ask the team leader when the quietest period is, and protect the time.

Predict first: two weeks after training, only about 40 per cent of the callers are using the tool regularly, though everyone attended. What is the first thing you would do? Decide before reading on.

Do not rerun the training. The first step is to find out why the other 60 per cent are not using it, by watching and asking. Sit beside a few non-users as they work and notice what they do instead and where they get stuck. Ask without judgement: "What would make this easier for you?" You may find that a screen takes four clicks that the old spreadsheet takes one, that a rule in the tool does not match how callers really decide, or that people are afraid the numbers will be used to rank them. Each of these has a different cure, and repeating a session solves none of them. Diagnosis comes before treatment.

Short sessions mean more of them, and someone must schedule them. The simulator below turns the size of the team and the group size into a number of sessions and weeks.

At the defaults, eighty people in groups of ten need eight sessions of 45 minutes, six trainer hours in all, spread over two weeks at four sessions a week.

Champions

A champion, in the sense of Lesson 2.2, is a person close to the work who believes in the project. In adoption, a network of champions is the most powerful tool you have. A champion is one of the users, a peer, not a trainer. They can answer a quick question in the next seat, show a shortcut in thirty seconds and say with credibility "I was doubtful too, but this does save time".

Choose champions for respect, not enthusiasm alone. Aim for roughly one for every ten to fifteen users, spread across teams and shifts. Give them early access, a little extra training, a direct line to you and, importantly, recognition: a mention in the weekly update, a word from the sponsor. They are doing real work for the project, usually without extra pay, and their goodwill is a resource to protect. Do not overload them, and make sure their managers know their time is valued.

Measuring adoption

How will you know whether it is working? A common and misleading answer is the attendance sheet. A better answer uses a small set of measures at different levels. A well-known framework for evaluating training, associated with Donald Kirkpatrick, distinguishes four levels, and it is a useful checklist.

1. Reaction. Did people find the training useful? Cheap to measure, with a short question after each session. But a good reaction does not mean they learned anything. Kirkpatrick himself is reported to have warned that positive reactions do not show learning. 2. Learning. Can they do the task? Test it: ask people to complete a real task in the sandbox, and see how many can. 3. Behaviour. Are they doing it on the job? This is the level that matters most for adoption, and it needs data from the system: who logs in, how often, which tasks they complete. 4. Results. Has the business outcome changed? The success metric from Lesson 2.3: the share of accounts paying within seven days, the time to find a bed.

The framework is sometimes criticised for assuming a neat chain from one level to the next, and real projects are less tidy. But it has a clear virtue: it reminds you that the first two levels are easy to measure and the last two are the ones that count.

For a typical rollout, track a few concrete numbers.

Activation. The share of intended users who have logged in and completed a first task, within a week of training. Depth. Which tasks they use, and how often. People who log in but do not use the main feature have not adopted. Retention. The share still active after four weeks and after eight. Many tools show strong early use and a decline. Support patterns. What questions arrive and from whom. A cluster of the same question points to a gap in training or a flaw in the tool. The business metric. Whether the outcome is moving, and whether the users show a better result than the non-users.

Share these numbers with the sponsor and the champions, in the weekly update. Visible progress motivates people, and a visible stall prompts action.

Dealing with resistance

Some resistance is information. When people say "this does not fit how we work", they are sometimes right, and the correct response is to change the tool, which is why early waves and demos matter. Other resistance is about fear or loss, and cannot be argued away.

A few approaches help.

Listen first, and fully. People who feel heard are less resistant. Ask what worries them, and write it down. Fix the real friction fast. If a step is awkward, change it, and tell people you did so, in public. Nothing builds credibility like a visible change made because someone complained. Address the fear directly. If people worry that the tool will be used to rank them, ask the sponsor to say plainly what it will and will not be used for, and put it in writing. Involve sceptics. Ask a sceptic to review the design or to try a new feature first. People support what they helped to shape. Get the manager's visible support. A manager who uses the tool in team meetings and refers to it by name makes adoption normal. Align the incentives. Check whether anything people are measured or rewarded on works against the tool, and raise it with the sponsor. Do not mandate before it works. Ordering people to use a tool that is not yet good turns resistance into resentment. Make it good, then make it the standard.

Worked example 1: the callers' rollout

The lender's reminder system goes to twelve callers in the first wave. The engineer has two champions: a respected senior caller who is enthusiastic, and a team leader who has doubts.

The training is thirty minutes, in a quiet period, on three tasks: reading the sorted list, marking an account as handled and flagging a wrong group. Each caller does the tasks on that morning's real list, with the champion beside them. A one-page guide is pinned in the team chat. The engineer holds a half-hour office hour on each of the first four days.

The numbers after the first week: activation 11 of 12, and depth good on the first two tasks and poor on the third. The engineer asks why. Callers say flagging a wrong group takes too many clicks. The engineer reduces it to one, and tells the team the next morning. By week four, 11 of 12 callers are using the tool daily, and two of them are telling the second wave how much time it saves. The champion's story is more persuasive than any slide. Retention held because the friction was fixed in the open.

Worked example 2: the nurse managers who went back to the phone

The hospital group's bed screen is rolled out to all six hospitals at once with a one-hour presentation to the nurse managers. Everyone attends and most say, in the feedback form, that it was useful. Three weeks later, data from the system shows that only two of the six hospitals update the screen daily.

The engineer visits the four others. At one, the nurse manager says she still phones the wards because she does not trust that the screen is up to date, and a few weeks ago a bed shown as free had been occupied. At another, the ward clerks who must update the status were never trained, because the presentation was for managers. At a third, the update takes a minute on a slow computer, and the staff skip it at busy times.

Each cause is different. The engineer adds a visible time stamp on each bed, so that people can see how fresh it is, trains the ward clerks in ten-minute sessions at the start of their shift and asks IT to speed up the slow machines. Within a month, five hospitals are updating daily. The lesson is the one the earlier sections give: a good reaction at level one hid the fact that two of the groups who needed to change their behaviour had never been trained, and that the real obstacles were small and fixable. Diagnosis found them. Repeating the presentation would not have.

The hospital rollout shows the cost of a good reaction that hid a real gap. The chart compares the number of hospitals updating the screen daily after the presentation and a month after the diagnosis and fixes.

Worked example 3: the mandate that stalled

At a company that sells to banks, the head of support orders all thirty agents to use a new reply-drafting assistant from Monday. The training is a one-hour demonstration. In the first two weeks, usage is high, because it is compulsory. In week three, a few agents notice that the drafts are sometimes wrong, and the word spreads. Agents begin to open the tool, paste its draft and rewrite it entirely, which takes longer than writing from scratch. The reported usage stays high. The benefit disappears.

The engineer notices only when the response-time figure fails to improve despite the usage figure. The fix has three parts. First, a small group of agents, chosen by their peers, review the common errors with the engineer and the prompt and sources are improved, which the agents can see. Second, the engineer works with the head of support to measure what matters, the time to a correct first reply, not the number of drafts opened. Third, agents who use the drafts well explain their method to the others in a short session.

The case shows two things. A mandate produces usage and not adoption, and the difference shows up in the outcome metric. And trust is part of adoption: when people see the tool being improved because of what they said, they begin to use it for real.

What does follow-up support add?

A common question from sponsors is whether follow-up support, such as champions, office hours and a quick way to ask, is worth its cost, compared with training alone. The arithmetic is simple. Of the people who attend training, only some will still be using the tool a few weeks later, and follow-up support raises that share.

The simulator below shows the effect. Set the size of the team, the share who attend training, the share of those who use the tool at week four without follow-up and the share who do with it. It shows the number of active users each way and the difference, and plots the number of active users as the share trained grows.

The shares are illustrative assumptions, and real figures vary a great deal between teams. Treat the simulator as a way of making the question concrete before you ask for the time and people that follow-up needs. Notice that training more people does not rescue a rollout with weak follow-up, since the gap between the lines grows with the number trained.

Try three experiments. First, keep the defaults and read the difference. Second, raise the share trained to 100 per cent without changing the use rates and see what extra training adds. Third, lower the share who use it without follow-up to 30 per cent, which describes a tool people find awkward, and see how much more the support matters.

At the defaults, 85 per cent of 80 people attend, which is 68. With training alone, 55 per cent of them, about 37, are still using the tool at week four. With follow-up support, 80 per cent are, about 54, 17 more people. The difference is the work of champions, office hours and quick answers, and it is large compared with their cost.

Common mistakes

Treating training as an event. The goal is changed behaviour, so plan the weeks after the session, not only the session. Counting attendance. Measure behaviour on the job and the business result, not just reaction and attendance. Repeating training to fix non-use. Diagnose first: watch and ask non-users what stops them. Presenting instead of practising. Train on real tasks, with real data, in short sessions. Training everything. Teach the first week's three or four tasks, and add more later. Forgetting the managers and the clerks. Train the managers who set the example and the people who update the data. Rolling out to everyone at once. Use waves, and choose the first wave to teach you the most. Mandating before it works. Fix the tool first, then make it the standard. Ignoring fear and incentives. Ask what people worry about, and check what they are rewarded for. Overloading the champions. Recognise and support them.

Key takeaways

The aim of training is changed behaviour, stated as something you could see people doing, not attendance or understanding. People rarely fail to adopt out of stubbornness. Common causes are not knowing how, no visible benefit, extra effort, mistrust, fear, mismatched incentives, an unconvinced manager and nowhere to ask. Adoption spreads in order, roughly by Rogers' categories of innovators, early adopters, early majority, late majority and laggards. Respected early adopters carry the large middle. Roll out in waves, choose the first wave to include a respected person, a visible manager and a sceptic, and build a network of champions. Train briefly on real tasks, with real data and practice, for the first week's tasks, with a quick guide and a fast place to ask. Measure at four levels, reaction, learning, behaviour and results. Behaviour and results are the ones that count. Diagnose non-use before you retrain.

Check yourself

1. State the real goal of training in one sentence. A change in behaviour: people doing something differently, every day, after you have gone, described as something you could see. 2. Name four reasons people do not adopt a new tool. Any four of: they do not know how, they see no benefit, it is harder than the old way, they do not trust it, they fear it, the incentives point elsewhere, their manager does not use it, or they have nowhere to get help. 3. Why are respected early adopters more important than innovators for adoption? The early majority look to people like themselves. A well-regarded colleague's endorsement carries far more weight than the enthusiasm of the people who will try anything. 4. A team of 100, with 80 per cent trained, 50 per cent of those still active with training only and 75 per cent with follow-up. How many more are active with follow-up? 100 × 0.80 = 80 trained. 80 × 0.50 = 40 active with training only, and 80 × 0.75 = 60 with follow-up, so 20 more. 5. Only 40 per cent are using the tool two weeks after training. What is the first step? Find out why the others are not using it, by watching and asking non-users, before doing anything else. Repeating the training addresses only one possible cause.

Try this

This exercise takes about forty minutes and gives you an adoption plan. Use a tool you are introducing at work, one you know about or an imagined rollout.

1. Write the target behaviour as one sentence about something you could see people doing. 2. List the users in three to five groups. For each, write the main reason they might not adopt, from the list in this lesson. 3. Choose a first wave of six to twelve people. Name a respected person, a manager who will use it visibly and one sceptic, and write why each is there. 4. Write the three or four tasks of the first week, and design a thirty-minute session on one of them using real data. Write what people will do, not what you will say. 5. Write a one-page quick guide for one task, with the steps in order. 6. Name your champions and what you will do to support and recognise them. 7. Choose five numbers to track: activation, depth, retention, support questions and the business metric. Write how you will get each, and the figures that would worry you. 8. Use the simulator to estimate what follow-up support would add for your team.

A good result is a target behaviour, a first-wave list, a thirty-minute task-based session, a quick guide, a champion plan and five numbers. It is the part of the project that turns a working system into a changed way of working, and it is what the customer will judge your result by.

Sources

[Diffusion of innovation](https://corporatefinanceinstitute.com/resources/management/diffusion-of-innovation/), Corporate Finance Institute. Used, with other summaries, for Everett Rogers' five adopter categories and their standard shares of 2.5, 13.5, 34, 34 and 16 per cent. Some sources give looser ranges, and I read summaries and not Rogers' book. [Kirkpatrick four-level evaluation model](https://methods.sagepub.com/ency/edvol/embed/sage-encyclopedia-of-educational-research-measurement-evaluation/chpt/fourlevel-evaluation-model), Sage encyclopedia of educational research, measurement and evaluation. Used, with other summaries, for the four levels of reaction, learning, behaviour and results, and the caution that positive reactions do not show learning. I read search summaries of these sources, not the full entries, and critics note the model assumes a neater chain from one level to the next than real projects show. The three rollouts, the usage figures and the simulator's defaults are the author's illustrations for teaching, not data from real projects. The training principles and the champion approach are practical guidance written for this lesson.

Tags: Forward Deployed Engineer Adoption Training Change management Customer success