Observable condition
Ask anyone on the team how things are going and the answer is the same: flat out. Diaries are full, inboxes are overflowing, people work through lunch and the office is noisy with calls. Yet when the owner looks at what the business actually delivered this quarter, the number of completed jobs, closed orders or onboarded clients is roughly what it was a year ago. Sometimes it is lower. The effort has gone up. The output has not.
When managers try to find out where the time goes, the explanations are all reasonable. A customer needed a callback. A delivery had to be rearranged. An invoice was queried. A colleague needed help finding a file. A job was started, paused for information, restarted and paused again. None of it is laziness, and very little of it is the work the business exists to do.
Realisation
Busyness measures activity. Output measures finished work. The two are easy to confuse because activity is visible and continuous, while output arrives in lumps at the end. A team can be fully occupied while finishing very little, if its time is consumed by work that does not move anything to completion.
The realisation is that much of that activity is generated by the process itself: rework, chasing, answering questions that should not have arisen, and restarting tasks that were set aside. This work is real and has to be done, but it exists because something earlier went wrong or was left unfinished. Adding effort to a system like that tends to produce more activity, not more output.
Realisation prompt: for one week, ask the team to tag each piece of work as either moving a job forward for the first time or dealing with something that should already have been done. The split is often more revealing than any timesheet.
Identification
This is a throughput problem disguised as a workload problem: capacity is being consumed by self-generated demand and by too much work in progress, so effort rises without a matching rise in completed work.
Two well-established ideas help name it. Vanguard's description of failure demand distinguishes value demand, the requests a service exists to meet, from demand caused by a failure to do something, or do something right, for the customer. Vanguard reports that failure demand routinely runs at a large share of total demand in conventional service organisations. The second idea is flow. Kanban University's article on flow efficiency divides active work time by total lead time and reminds readers that work in progress is not always actually in progress.
Diagnosis
The visible symptom is a busy team with flat output. The common assumption is that the team needs more people or better time management. The structural causes are more specific:
- Failure demand. Callbacks, queries, corrections and complaints that arise because an earlier step was unclear, late or wrong. Each one is handled as if it were new work.
- Too many things started. When everyone has many jobs open at once, each one progresses slowly and attention is split between them. Finishing slows down even as starting speeds up. How this turns into queues is examined in when work sits waiting more than it moves.
- Waiting disguised as working. Jobs pause for information, approval or parts. People switch to something else and later spend time picking up the thread.
- Rework. Work done to the wrong specification, with incomplete information or on outdated data has to be done again, consuming capacity twice.
- Coordination overhead. Meetings, messages and updates needed to keep many open jobs aligned grow with the number of jobs open, not the number completed.
- Measures that reward activity. Calls answered, emails sent and hours logged look good even when nothing finishes.
The underlying waste is what lean practice calls muda: activity that consumes resources without creating value for the customer.
Commercial impact
The commercial value at stake is productivity, capacity, margin and customer experience.
- Productivity. Payroll grows or stays fixed while finished work stays flat, so cost per completed job rises.
- Capacity. Self-generated demand crowds out new business. The team is too busy to take on work it could otherwise win.
- Customer experience. Failure demand is, by definition, something the customer had to chase or correct.
- Morale. People who work hard without seeing results become tired and cynical, and staff turnover adds more rework.
- Misdirected investment. The business may hire or buy software to meet demand it is creating itself.
The scale should be measured from the business's own data, starting with a sample of incoming demand classified as value or failure.
Common misidentification
The natural conclusion is that the team is under-resourced, so the business hires. A new person absorbs some of the activity, but the same failures keep generating it, and output rises less than expected. Another common response is a productivity drive that asks people to do more, which usually means starting more jobs and raising the amount of work in progress. A third is to blame individuals. The diagnostic distinction is explored further in how to tell whether you have a people problem or a systems problem.
Possibility
In a stronger state, the business measures what it finishes, not just what it does. Incoming demand is understood, and the most common sources of failure demand are removed at their origin: clearer quotes, proactive status updates, correct information captured once. Teams limit how many jobs they have open, so each one moves steadily to completion. Jobs do not start until the information they need is available. The same team, with the same hours, finishes more, and the office feels calmer rather than busier.
Intervention
- Measure output, not activity. Count completed jobs, orders or cases per week alongside hours worked.
- Classify incoming demand. Sample calls, emails and tickets and sort them into value demand and failure demand. Identify the top causes of failure demand.
- Fix the top causes at source. If customers call to ask where their order is, give them status before they ask. The pattern is examined in why proactive communication can remove entire support workloads.
- Limit work in progress. Agree a maximum number of open jobs per person or team and finish before starting.
- Check readiness before starting. Do not begin a job until its information, approvals and materials are in place.
- Track rework. Record when work has to be redone and why, and treat recurring reasons as process faults.
An illustrative example
The following is illustrative, not a client case. A Cape Town kitchen-fitting company with a busy office team sorts a fortnight of incoming calls and emails. A large share turn out to be customers asking for installation dates, installers asking for measurements that were not on the job card, and corrections to quotes. The company adds a required-fields check to its job card, sends automatic messages when installation dates are set, and introduces a quote checklist. The office stays busy, but completed installations per month rise without an extra hire.
Practical diagnostic questions
- Has completed output grown in line with hours worked over the past year?
- What share of incoming demand exists because something earlier went wrong?
- How many jobs does each person have open at once?
- How often is work started before its information is complete?
- Which of your measures reward activity rather than completion?
Bottom line
A team that is busy without producing more is usually absorbing demand its own processes create, while juggling too many open jobs. Measuring finished work, removing the main sources of failure demand and limiting work in progress converts effort back into output, without asking people to work any harder.
Sources and further reading
- Failure Demand (last verified 10 October 2026)
- Flow Efficiency: A great metric you probably aren’t using - Kanban University (last verified 10 October 2026)
- Muda, Mura, Muri - Get a Quick Introduction - Lean Enterprise Institute (last verified 10 October 2026)
Related Mellorca reading
- The Daily Routine Nobody Remembers the Reason For
- Why Recurring Tasks Should Trigger a Process Review
- The Business Process That Only Works Because Someone Remembers