Growth, Scaling & Capacity

When Headcount Becomes the Default Fix for Process Problems

Pressure in a team leads to another hire before anyone asks why the work arrives the way it does. Here is how to tell capacity problems from process problems, and what to check before recruiting.

Mellorca Patterns2026-10-09

Observable condition

Order queries are piling up at a Pietermaritzburg furniture distributor. Deliveries are late, invoices are wrong and customers phone more often. At the management meeting, the response is immediate and unanimous: the customer service team is overloaded, so the business should hire two more people. The requisition is approved within a week. Three months later the new staff are trained, the queries have not fallen, and the team lead says she now needs a supervisor to manage the larger team.

This is a familiar sequence. A problem shows up as work piling up, a manager sees people stretched, and the quickest visible answer is another pair of hands. Headcount is easy to explain, easy to budget and easy to recruit for. Nobody has to redraw a process, change a system or have an awkward conversation about why the work arrives the way it does.

An illustrative example: a Sandton professional-services firm adds three administrators in two years to handle client paperwork. Each addition is justified at the time. Eventually, a review finds that the same details are captured on four forms, two approvals are routinely rubber-stamped, and about a third of the admin volume consists of chasing documents that were never complete when first submitted.

Realisation

The realisation is that headcount answers a question about capacity, while the problem may be about how work is designed. If a process produces rework, waiting and unnecessary handoffs, more people simply run the same flawed process in parallel. The output rises slightly, the cost rises permanently, and the defects that created the load remain.

Fred Brooks observed a related effect in software projects: adding people to a late project tends to make it later, because communication and training costs grow faster than useful output. The finding, commonly called Brooks's law, was about one setting, but it points to a general truth about coordination overhead that most operations managers will recognise in their own teams.

Realisation prompt: for the last role you added to relieve pressure, what share of its time goes on work that would disappear if the process were fixed?

Identification

This is a pattern of capacity used as a substitute for process design. The visible symptom is a growing team whose workload never seems to ease. The common assumption is that the business is simply growing and needs more people to keep up. The structural cause is that the work itself contains avoidable steps, such as re-keying, approvals, status checks and corrections, and nobody has examined which ones are necessary before deciding how many people are needed.

The published Patterns why more headcount does not always create more capacity and why revenue growth requires more admin staff cover the effect on capacity and administration. The Impact page on scaling by adding headcount covers the cost side. This Pattern looks at the decision habit: why hiring becomes the first reply to every operational strain.

Diagnosis

  • Hiring is the visible lever. A manager can approve a role in a meeting. Redesigning a process needs analysis, cooperation from several teams and tolerance for a period of disruption.
  • Workload is measured as volume, not as value. Counting tickets, calls or invoices processed says nothing about how many were caused by an earlier error. Lean thinking separates work that adds value from waste, such as waiting, rework and over-processing, and treats the latter as a target for removal rather than as a staffing need.
  • Effort is read as proof of need. Busy people look like understaffed people. Parkinson's observation that work expands to fill the time available is a reminder that visible busyness is not the same as necessary work.
  • Ownership is fragmented. Each department sees its own queue. The person who could remove the cause, in another team, does not feel the load, so the team that feels it asks for people.
  • Budget and process sit in different hands. Headcount is a line in a departmental budget. The cost of redesign has no natural owner, and the saving shows up somewhere else.
  • The labour market feels like the solution. In South Africa, with plentiful applicants for administrative roles, hiring can seem cheap compared with systems work, even though the real cost includes training, supervision, equipment and the compounding salary bill.

Commercial impact

The commercial value at stake is cost structure, margin, scalability and management attention.

The financial effect is straightforward. A junior administrator on R18,000 a month costs closer to R300,000 a year once leave, bonuses, equipment, training and supervision are counted. If the role exists mainly to absorb rework, the business has capitalised the defect: it now pays every month for something a one-off fix could have removed. When revenue dips, the cost remains. When revenue grows, the same logic prompts the next hire, and costs rise in step with sales instead of falling as a share of them.

There are management costs too. Larger teams need more supervision, more coordination and more meetings. Brooks's law shows how communication paths multiply with team size. New staff also inherit a flawed process and learn its workarounds, which makes it harder to change later because more people are used to it. The Insight how to find rework inside a business process describes how to locate this hidden load.

Finally, scalability suffers. A business that grows by adding people at the same ratio never builds the capacity to grow without them. The Impact page on five-person processes in a growing business shows how this limits growth.

Common misidentification

Sometimes more people are indeed the right answer, and the pattern should not be read as a case against hiring. A genuine increase in volume of necessary, well-designed work requires capacity. The error is in assuming that is always the explanation. The test is whether the extra workload comes from more customers, or from more effort per customer.

The reverse mistake is to jump to automation before the process is understood. Automating a flawed process makes the flaw faster, which the Insight why automating a broken process makes the problem worse explores. Neither hiring nor software is the first step. Understanding the work is.

Possibility

In a better state, a request for headcount is accompanied by a short analysis of where the time goes. The team can say how much of its workload is necessary, how much is repeated, how much is waiting and how much is correction. Fixes for the avoidable categories are tried first, and a hire is made when the remaining necessary work genuinely exceeds what the team can carry. The people who are hired do work that needs judgement, and the business can add customers without adding administration at the same rate.

Intervention

  1. Pause and sample. Before approving the next role, ask the team to record for two weeks what each task is and why it arose. Categories like new work, rework, chasing and exceptions are enough.
  2. Trace the top three causes of load. For each, find where in the process the issue begins, often in a form, a handoff or a missing piece of information upstream.
  3. Fix the cause before adding the capacity. Remove duplicate capture, tighten the information needed at the start, and simplify approvals with low risk.
  4. Re-measure. After a month, see how the workload has shifted. Decide on the hire using the changed number, not the old one.
  5. If you hire, define the role by outcome. Write down which work it replaces or enables, and review after six months whether that happened.
  6. Make process cost visible. Report a simple measure, such as cost of administration per order, alongside headcount, so growth in staff is judged against the volume it serves.

Diagnostic questions

  • What share of your team's work is caused by errors or missing information earlier in the process?
  • When you last added a role, did the queue shrink, or did it refill?
  • Is headcount growing faster than orders, customers or revenue?
  • Who owns the process that creates the workload, as distinct from the team that handles it?
  • Could you explain what each recent hire does that would otherwise not be done?

Bottom line

When headcount becomes the default answer to every process problem, the business pays permanently for symptoms. Looking first at where the work comes from, removing avoidable steps and hiring only for the necessary remainder keeps costs in proportion to growth and leaves people free to do the work that needs them.

Sources and further reading

Related Mellorca reading

Article summaryPressure in a team leads to another hire before anyone asks why the work arrives the way it does. Here is how to tell capacity problems from process problems, and what to check before recruiting.