When Training Is Forgotten Because the System Changed Again

She went on the course. She practised. She wrote her own notes, with screenshots, and kept them beside the keyboard. After a few months she could process the month-end in the accounting system without looking anything up. Colleagues began to ask her for help.

Then, one Monday, the screen looked different. The menu she always used had moved. A button had a new name. The step that used to come third now came first, and one report she relied on appeared to have gone. Her notes no longer matched what she saw. She was, in a small but real way, a beginner again.

This is a common experience with modern business software, which is updated continuously rather than replaced every few years. Most of the time the changes are improvements. But for the person who had mastered the old way, each change carries a cost that rarely appears in any plan: the loss of confidence that took months to build.

Why software keeps changing

Microsoft's documentation on release options for Microsoft 365 explains the model directly. Instead of large updates every few years, customers receive new features as they become available. Administrators can choose to keep most users on the standard release while a few selected people receive updates early through what Microsoft calls targeted release. The stated purpose is to let administrators and change managers test updates, prepare user notifications and documentation, and brief the internal help desk before changes reach everyone.

That guidance describes the tools for managing change. In many small businesses, nobody uses them. Updates simply arrive, on whatever day the vendor releases them, and staff discover them when they log in.

What research says about learned skill and change

The Nielsen Norman Group, a usability research firm, has written about the tension between fresh and familiar designs. It notes that frequent users build skilled performance through routine, relying on consistent layouts and behaviour, and that these experienced users tend to resist radical change more than occasional visitors do. Its general advice to designers is to evolve interfaces gradually where possible, preserving what users already know.

Prosci's ADKAR model of individual change describes five elements: awareness, desire, knowledge, ability and reinforcement. The last three are relevant here. Knowing how a system works is not the same as being able to use it fluently under pressure, and without reinforcement people tend to slip back to old habits or lose confidence.

Microsoft's survey of frontline workers, an international study rather than a South African one, found that 55% had adapted to new digital tools without formal instruction or practice. That figure concerns new tools rather than updates, but it suggests how often people are left to work out changes on their own.

How a trained skill is undone

Consider an illustrative case: a Kimberley medical practice group with about thirty staff, using a cloud practice-management system and a cloud accounting package. Both vendors release updates monthly. The practice manager receives the vendors' release emails but rarely has time to read them. No one tests changes before they reach the reception and billing staff.

The mechanism is straightforward:

Training is a single event. Staff were trained at go-live, and that training is never refreshed. Why that matters is discussed in why technology implementations fail after go-live.
Nobody owns the system after launch. Without a named owner, nobody reads the release notes or decides when to prepare people. The case for ongoing ownership is made in why business systems need ongoing stewardship.
Personal notes go stale. The guides people wrote for themselves stop matching the screen, and there is no shared, maintained version.
Change arrives during the work. The person discovers the update in the middle of a deadline, when there is least time to relearn.

In the illustrative practice, the effect shows up at the front desk. When the billing screen changed, the receptionist who had trained newer colleagues found herself asking them for help, because one of them had happened to stumble on the new layout first. Claims were captured more slowly for a fortnight. Nobody connected the slowdown to the update, and nobody thought to tell her in advance that it was coming.

The human tax: confidence

The time cost is real: minutes spent searching for a moved function, asking a colleague, or redoing a step. But the more significant cost is to confidence.

Confidence with a system is built slowly. It is the feeling of knowing what will happen when you click, of being able to work quickly and help others. When the system changes without warning, that feeling can be lost at once. Some people take this in their stride and enjoy exploring the new version. Others may become hesitant, double-check everything, avoid functions they used to use, or quietly worry about making a mistake in front of patients or colleagues. Mellorca cannot say how any individual responds. It can say that repeated, unannounced change asks people to rebuild their competence over and over, and that the effort is invisible to everyone except them.

There is also a quieter effect on learning itself. If people come to expect that whatever they learn will soon change, the incentive to learn properly weakens. Mellorca has looked at a different barrier to learning, the lack of time, in the employee who never has time to learn. This is the other side: learning that is done, and then undone.

What could change

Name a system owner. One person reads the vendor's release notes each month and decides what staff need to know.
Use early-release options where they exist. Putting one or two experienced users on early release lets them meet changes first and prepare colleagues.
Explain changes in the context of the work. A short note saying where the month-end report has moved is worth more than a link to a general release summary.
Keep one shared, maintained guide. Replace personal notes with a short process guide that the system owner updates when the screens change.
Treat training as ongoing. Brief refreshers after significant updates reinforce skill rather than leaving it to erode.

Introducing change without disrupting work is a skill in itself, discussed in how to implement a new business system without disrupting operations.

Trade-offs

Updates matter. Many updates include security fixes. Delaying them to protect familiarity can create real risk.
Managing change takes time. Reading release notes and updating guides is an ongoing task that someone must be given time for.
Uneven experience. Early-release users carry more disruption on behalf of others. That should be a choice they make, not a burden imposed.
Not everyone needs support. Some staff adapt easily and may find structured briefings unnecessary.

Why it matters

For the business, managed change means fewer errors after updates, less time lost to searching and asking, and better use of what was spent on training. For the person, it means that the skill they built is maintained rather than repeatedly reset. Changes still come, but they come with warning and with help.

That is the dividend: predictability, and the confidence that grows from it. Being good at your work should not have to be re-earned every time a vendor moves a button.

Sources and further reading

Set up the Standard or Targeted release options for Microsoft 365 - Microsoft 365 admin (last verified 10 October 2026)
Fresh vs. Familiar: How Aggressively to Redesign (last verified 10 October 2026)
The Prosci ADKAR® Model - Prosci (last verified 10 October 2026)
https://www.microsoft.com/en-us/worklab/work-trend-index/technology-unlocks-a-new-future-for-frontline (last verified 10 October 2026)