There is a familiar moment in a growing business.
Everyone is stretched.
Service levels are under pressure.
Managers are overloaded.
Projects are slipping.
Overtime is increasing.
People say they cannot take on anything else.
The conclusion seems obvious.
We need more people.
Sometimes they are right.
Sometimes the business genuinely has a capacity problem.
But sometimes adding headcount is the worst thing you can do.
Because the organisation does not have a capacity problem.
It has a design problem.
And adding people to a poorly designed operating model can increase the cost of the problem without removing it.
Headcount can hide bad architecture
Labour is extraordinarily adaptable.
People compensate for broken systems.
They fill gaps between functions.
They create spreadsheets.
They remember exceptions.
They chase approvals.
They reconcile conflicting data.
They coordinate work manually.
They develop relationships that allow them to bypass formal processes.
They know who really needs to be called when something gets stuck.
This adaptability is one of the reasons businesses survive imperfect operating models.
It is also why those operating models can remain imperfect for years.
Whenever the system fails, somebody intervenes.
Whenever volume increases, another person is added.
Whenever complexity increases, another coordinator appears.
Whenever an executive becomes overloaded, another layer is created underneath them.
The organisation absorbs its structural problems through labour.
Eventually that labour looks like capacity.
It is not always the same thing.
The question is not whether people are busy
When management says a team needs more resources, the evidence is often that everybody is busy.
That is useful information.
But it is not a diagnosis.
People can be busy because demand exceeds genuine capacity.
They can also be busy because the business requires an unnecessary amount of work to produce an outcome.
Those conditions look similar from a distance.
They require completely different responses.
One requires additional capacity.
The other requires redesign.
If you confuse them, you can spend a significant amount of money scaling inefficiency.
Low productivity is not always a people problem
Poor productivity is often discussed as though it sits primarily with the workforce.
Are people working hard enough?
Are managers managing effectively?
Are performance standards high enough?
Do we have the right skills?
Those questions can matter.
But productivity is also determined by the environment in which people work.
Give a capable employee:
unclear priorities,
three disconnected systems,
four approval points,
poor-quality data,
a process full of exceptions,
duplicated reporting,
and a manager who needs to escalate most decisions,
and you should not be surprised when productivity is low.
The person may not be the constraint.
The operating model may be.
This is an important distinction because individual performance interventions will not solve structural productivity problems.
You can coach people harder.
Set tighter targets.
Change incentives.
Add dashboards.
Introduce daily meetings.
If the underlying workflow still requires unnecessary effort, the productivity ceiling remains.
Coordination has a cost
Adding headcount does not just add labour capacity.
It also creates coordination.
More people create more handoffs.
More handoffs create more information transfer.
More information transfer creates more potential for error, delay and ambiguity.
More managers create more management interfaces.
More functions create more interdependencies.
This does not mean scale is bad.
It means scale has an architectural requirement.
A process that works brilliantly with ten people can break with fifty.
An executive who can coordinate five managers informally may become the bottleneck at fifteen.
A spreadsheet that works at $20 million revenue may become operationally dangerous at $200 million.
A weekly conversation can substitute for formal decision rights in a small team.
It cannot necessarily do so across multiple sites, functions and geographies.
The operating model has to evolve before complexity overwhelms it.
There is a difference between scale and accumulation
Businesses often describe themselves as scaling when they are really accumulating.
More people.
More systems.
More customers.
More products.
More sites.
More processes.
More reports.
More managers.
Scale should create some form of operating leverage.
Accumulation simply makes the organisation larger.
That distinction becomes visible in the relationship between revenue and organisational effort.
If revenue rises by 50 per cent and the labour, management and coordination required to support it also rises by 50 per cent, the business has grown.
Whether it has scaled is a different question.
This is particularly important in businesses where historical growth has been absorbed through headcount.
At some point the model reaches a limit.
Management feels stretched.
Margins stop improving.
Complexity rises.
Every new dollar of revenue seems to require more organisational effort than the last.
That is often described as a capacity limit.
Sometimes it is actually an operating-model limit.
Managers often become capacity buffers
One of the patterns I look for is where management time goes.
In a well-designed organisation, managers should spend meaningful time on leadership, performance, capability, decision-making and improvement.
In a poorly designed one, they become buffers.
They chase work.
Resolve handoffs.
Correct data.
Interpret priorities.
Mediate between functions.
Approve routine decisions.
Escalate exceptions.
Attend coordination meetings.
Build reports.
Work around system limitations.
They are effectively absorbing variation that the operating model cannot handle.
Because managers are capable, the business continues functioning.
That creates a dangerous illusion.
Management intervention starts to look like management work.
It isn't always.
Sometimes it is simply expensive manual integration.
Before adding ten people, ask what work should disappear
There is a question I think more businesses should ask before approving additional headcount:
If this operation were designed properly today, would this work still exist?
Not:
Can we automate it?
Not:
Can we offshore it?
Not:
Can somebody cheaper do it?
First:
Should it exist?
This changes the discussion.
A manual reconciliation may not need automation.
It may need the source-data problem fixed.
A reporting role may not need additional capacity.
The report may no longer need to exist.
Another operations coordinator may not solve the handoff problem.
Ownership between the two functions may need redesign.
Another manager may not solve excessive escalation.
Decision rights may need to move down.
A larger customer-service team may not solve demand.
The upstream process may be creating avoidable customer contacts.
When you start with the work rather than the role, different opportunities appear.
Genuine capacity constraints do exist
There is a risk of taking the argument too far.
Not every headcount request is evidence of poor design.
Businesses need people.
Growth creates genuine demand.
New capabilities require investment.
Under-resourced operations can damage service, burn out employees and constrain growth.
The objective is not to create an organisation permanently starved of capacity.
It is to distinguish productive capacity from compensating capacity.
Productive capacity directly increases the organisation's ability to create value.
Compensating capacity exists primarily because something elsewhere does not work properly.
The two can sit beside each other on the same organisation chart.
The accounting system will not distinguish them.
Management needs to.
A better capacity conversation
When a team requests additional resources, I would want to understand five things.
What has changed in demand?
Has transaction volume increased?
Customer complexity?
Operating hours?
Product mix?
Service requirement?
Regulatory obligation?
If demand has genuinely increased, quantify it.
Where is the work going?
Follow the workflow.
How much time creates value?
How much is administration?
How much is rework?
How much is waiting?
How much is checking?
How much is escalation?
What has changed in productivity?
Has output per person changed?
If so, why?
Do not stop at the metric.
Understand the mechanism.
What work could be removed before capacity is added?
This is the question most capacity reviews miss.
If we add people, does the operating model become more scalable—or merely larger?
That final question matters enormously.
Technology does not automatically solve the problem
Another common response to low productivity is technology.
Sometimes this is exactly right.
But digitising a poor process can simply make a poor process happen electronically.
Businesses implement systems around historical workflows without first challenging the workflow itself.
The result can be expensive digital wallpaper.
New interface.
Same approvals.
Same duplication.
Same exceptions.
Same decision bottlenecks.
Sometimes more data entry.
Technology creates leverage when the process and decision architecture around it are also redesigned.
Otherwise, the business can end up with both the old complexity and the new system cost.
Productivity is an operating-model outcome
The productivity discussion becomes much more useful when it moves beyond individual effort.
Ask whether the organisation makes productive behaviour easy.
Can people access reliable information?
Can decisions be made at the right level?
Are roles and accountabilities clear?
Are processes designed around the outcome?
Do systems support the workflow?
Are performance measures aligned across functions?
Are recurring exceptions being eliminated?
Does management spend its time managing—or compensating?
These are operating-model questions.
And they are often where meaningful operational performance improvement begins.
The Headcount Trap
There is nothing inherently wrong with adding people.
The trap is assuming people are the answer before understanding the problem.
Because once labour enters the operating model, the business adapts around it.
Tasks are divided.
Responsibilities change.
Reporting lines appear.
New controls develop.
The cost becomes structural.
Then, years later, somebody looking at the organisation asks why it takes so many people to perform the work.
The answer is usually historical.
“We've always done it this way.”
“We need them because the process requires it.”
“That's how the system works.”
“That team has always owned that.”
History has become architecture.
Scale the business, not the problem
The goal of operational improvement is not to make everybody work harder.
Nor is it to run permanently lean.
It is to create an organisation where capacity is applied to work that matters.
That requires a more disciplined response when a business feels stretched.
Sometimes the answer will genuinely be more people.
But before approving them, understand what they are being asked to compensate for.
Poor systems?
Poor decisions?
Poor process?
Poor accountability?
Unnecessary complexity?
Duplicated work?
Or genuine customer demand?
Because if the underlying architecture is wrong, additional headcount does something dangerous.
It makes the problem easier to live with.
And harder to see.
Before you scale the workforce, make sure you are not simply scaling the workarounds.