The tolerated pain
A new bookkeeper starts on the first of the month. By the end of week one she has been given logins for the accounting package, a separate payroll portal, the bank's business platform, a stock system, a CRM, a time-tracking app, a document-signing service, a team chat tool and a shared drive. She has been shown each one for about twenty minutes. By week six she is confident in three of them and quietly avoiding the rest, keeping a private spreadsheet for whatever she cannot yet do in the system that is supposed to hold it.
This is not a story about a slow learner. It is what happens when a business accumulates applications faster than it teaches people to use them. Every tool was bought for a sensible reason, and each works well in the hands of the person who championed it. The cost sits in the gap between how many tools exist and how many any one employee can genuinely master.
This article looks at that gap: the lost time, the training bill and the quiet workarounds that follow. It is related to, but different from, the problem of the same task being spread across several tools, covered in too many applications for one task. Here the focus is on people's capacity to learn and retain the software they are expected to use.
Why more applications means shallower skill
Learning software is not a one-off event. People need to learn the screens, then the exceptions, then the shortcuts, and then they need to keep that knowledge fresh through regular use. A tool used daily becomes second nature. A tool used once a month is relearned every time.
The Nielsen Norman Group's guidance on minimising cognitive load explains that people have limited mental capacity for processing information, and that interfaces which demand more of it make users slower and more error-prone. Each additional application brings its own menus, its own vocabulary and its own idea of where a button should be. An employee switching between eight of them is not using one skill eight times. They are holding eight partial maps in their head and switching between them all day.
- The same action has different names. A "job" in one tool is a "ticket" in another and a "project" in a third.
- Rarely used features decay. Skills for month-end or year-end tasks are forgotten by the time they are needed again.
- Training is offered once. The induction covers everything on day one, when the new starter cannot yet tell which parts matter.
Operational symptoms
- new starters who take months, not weeks, to work independently;
- colleagues who are "the person who knows how to do that" in a particular tool, and who are interrupted all day;
- staff who use only a small fraction of any application and export to a spreadsheet for the rest;
- repeat questions to IT or a supervisor about the same screens;
- work routed to whoever is comfortable with the tool, regardless of who should be doing it;
How the pain becomes money
Software overload shows up in the budget in several places, and most of them are not on the software invoice.
- Training time: every new application adds hours to induction and to each refresher. Those hours are paid wages, and they are repeated for each new employee.
- Slower work: hesitation, searching for the right screen and asking colleagues add minutes to routine tasks across the whole team, every day.
- Errors and rework: an employee who half-knows a tool is more likely to capture data in the wrong field or skip a step, and the correction costs more than the original task.
- Specialist dependency: when only one or two people can use a tool properly, their time becomes a bottleneck and their absence becomes a risk, as discussed in key-person dependency as a systems problem.
- Unused capability: the business pays for features that nobody knows are there, which is part of the picture in the real cost of paying for software nobody uses properly.
An illustrative cost model
The figures below are illustrative assumptions for a hypothetical Durban distribution business with 30 employees and an average staff turnover that brings in six new starters a year.
| Assumption | Value |
|---|---|
| Applications an office employee is expected to use | 9 |
| Induction and early training time per new starter on software | 40 hours across the first three months |
| Hours a trainer or senior colleague spends per new starter | 25 |
| New starters per year | 6 |
| Loaded hourly cost of new starter / of trainer | R170 / R280 |
| Time lost per employee per week to searching, switching and asking for help | 2 hours |
| Office employees affected | 20 |
| Loaded hourly cost, average | R190 |
| Working weeks per year | 46 |
- New-starter training time: 6 × 40 × R170 = R40,800
- Trainer time: 6 × 25 × R280 = R42,000
- Time lost to switching and help-seeking: 20 × 2 × R190 × 46 = R349,600
- Illustrative total: about R432,000 a year
The point of the model is the proportion. The training line is visible and easy to defend. The larger line is a steady drip of two hours a week per person that nobody records because it never feels like a single event. Even if the real loss were a quarter of this assumption, the amount would still exceed the annual cost of the licences themselves in many small businesses.
Why the pain is tolerated
Each application is defended by the person who asked for it. Nobody is measuring how long it takes staff to become competent, so the cost is invisible. Training is treated as something that happens in the first week and then stops. Managers assume that because the tool is "intuitive", the staff will work it out. The least confident employees do not complain; they develop private workarounds, and the workarounds become the real process.
When it becomes commercially urgent
- a new starter leaves within months because they feel overwhelmed;
- an expensive error is traced to someone using an unfamiliar screen under time pressure;
- the only employee who understood a tool resigns;
- a new application is planned and nobody can say how many people will realistically learn it;
What better looks like
The answer is not necessarily fewer tools in every case. It is a deliberate match between the number of applications and the capacity of the people who use them.
- Count what each role really touches. List the applications by job role, not by department. You may find that a payroll clerk needs three, while a sales administrator is expected to handle nine.
- Rank by frequency. Tools used daily deserve proper training. Tools used twice a year may deserve a one-page guide or may not deserve to exist.
- Remove or merge the low-value ones. The method in how to decide which software to remove applies directly.
- Give each remaining tool an owner. The owner keeps a short quick-start guide, answers questions and checks that training matches the current version.
- Train by task, not by feature. "How to capture a supplier invoice" is more useful than a tour of every menu.
- Review at renewal. Ask how many people actively use the tool and how confident they are before the next payment is made.
Understanding who uses what is also an access question. Microsoft's application management overview describes managing the applications an organisation uses and who can reach them, while the Defender for Cloud Apps documentation treats discovering which cloud applications are in use as a core capability. A small business can do a simpler version of both by writing the list down and checking it against real usage.
For a structured way to do that, see how to build a business application inventory that is actually useful, and how to know when you have too many business apps for the warning signs.
Practical next actions
- Ask five employees to list every application they log into in a typical week.
- Ask the same five which ones they feel confident in and which they avoid.
- Compare the lists with the licences you pay for and mark tools nobody uses properly.
- Time the last new starter's journey to working independently, and note which tools slowed them down.
- Write a one-page task guide for the two most-avoided tools.
- Add "who will learn this and how long will it take?" to your approval questions for any new software.
Bottom line
Software overload is a human-capacity problem disguised as a technology problem. Every extra application takes training time, adds switching effort and spreads skill thinner across the team. The invoice is the smallest part of the cost. A business that counts its tools by role, trains by task and retires what nobody uses well will usually find that people become faster and less anxious, and that new starters become productive sooner.
Sources and further reading
- Minimize Cognitive Load to Maximize Usability (last verified 10 October 2026)
- What is application management? - Microsoft Entra ID (last verified 10 October 2026)
- Overview - Microsoft Defender for Cloud Apps (last verified 10 October 2026)
Related Mellorca reading
- The Automation Only One Person Understands: The Hidden Cost of Dependency
- Four Tools, One Job: The Real Cost of Departments Buying Their Own Software
- Answering the Same Question Again: The Payroll Cost of Undocumented Know-How