Growth creates complexity. But complexity becomes a problem when the way the organization operates never catches up.
There’s a point in almost every growing company when things start to feel… weird.
Meetings multiply.
Decisions take longer.
Everyone is “aligned,” but somehow three teams are doing three different things.
A process that used to take one person and a Slack message now requires six people, two approvals and a spreadsheet no one fully trusts.
The CEO is still making decisions that made perfect sense when there were 40 employees.
There are now 240.
And somewhere, someone says:
“We’re just going through growing pains.”
Maybe.
Or maybe the company is trying to operate at a new scale using an operating model designed for an old one.
That’s different.
And it matters.
Growth doesn’t just make the company bigger
It changes the company.
More customers create more exceptions.
More employees create more handoffs.
More leaders create more decision points.
More geographies create more coordination.
More products create more tradeoffs.
More systems create more ways for information to disagree with itself.
The organization doesn’t simply become a larger version of what it was.
It becomes a different system.
And systems that worked beautifully at one stage can become liabilities at the next.
The old operating model usually worked for a reason
This is important.
The problem is not necessarily that management designed the organization badly.
Often, the exact opposite is true.
At 30 employees, having the founder approve every meaningful customer decision may be incredibly effective.
At 75 employees, one weekly leadership meeting may be enough to keep the entire organization synchronized.
At 100 employees, finance may still be able to answer most business questions through spreadsheets and institutional knowledge.
At that size, speed often comes from keeping things informal.
Fewer layers.
Fewer rules.
Fewer meetings.
More direct communication.
It works.
Until it doesn’t.
The mistake is assuming that because something worked well, it should continue working indefinitely.
Complexity shows up before the org chart admits it
Organizations are remarkably good at postponing structural change.
You’ll hear:
“We don’t want to become bureaucratic.”
Reasonable.
Nobody has ever enthusiastically announced:
We should really add some bureaucracy around here.
But avoiding bureaucracy and avoiding structure are not the same thing.
When the organization outgrows its operating model, structure appears anyway.
It just appears informally.
People create side meetings because the main meeting doesn’t work.
Managers build shadow spreadsheets because the system doesn’t answer their questions.
Employees ask the same three leaders for approval because nobody knows who actually owns the decision.
Teams invent their own workflows because the enterprise process is too slow.
Congratulations.
You have bureaucracy.
It’s just undocumented.
The symptoms often look like people problems
This is where organizations get into trouble.
Execution slows down.
Leadership concludes:
“People need to be more accountable.”
Maybe.
But accountability is hard when ownership is unclear.
A team misses a deadline.
Management concludes:
“They need better project management.”
Maybe.
But project management will not fix a process with eight unnecessary handoffs.
A leader seems indecisive.
Management concludes:
“They need to make decisions faster.”
Maybe.
But if three other leaders can veto the decision after it’s made, speed is not really the issue.
A good operating model creates the conditions for good performance.
A bad one makes competent people look dysfunctional.
Decision rights are where scale often breaks first
Small companies survive on shared context.
Everyone knows what’s happening.
Everyone knows who should make the call.
If there’s confusion, someone asks the founder.
That works surprisingly well.
Until the founder becomes the answer to 47 questions a day.
As organizations scale, decision-making has to move from:
“Who knows the most?”
to:
“Who owns this decision?”
Those are not always the same person.
Good decision rights clarify:
- who makes the decision;
- who provides input;
- who must be informed;
- what thresholds require escalation;
- and when a decision is actually final.
Without that clarity, decisions drift upward.
Everything feels important.
Senior leaders become bottlenecks.
Middle managers stop taking ownership because they learn that decisions will eventually be revisited above them anyway.
Then leadership wonders why nobody feels empowered.
Meetings are part of the operating system
A company’s calendar tells you a surprising amount about how it operates.
You can usually spot a struggling operating model by the meeting structure.
There are too many meetings, because no single meeting reliably produces decisions.
Or there are too few, so every issue gets handled through ad hoc escalation.
The same topic appears in three forums.
Nobody knows whether a meeting is for information, discussion or decision.
Updates consume 50 minutes.
The actual decision gets seven.
And every meeting includes at least one person whose principal contribution is wondering quietly why they are there.
Meetings aren’t the problem.
Badly designed management cadence is.
A useful operating cadence answers:
What needs to be reviewed?
How often?
By whom?
For what purpose?
And what should happen as a result?
That is an operating model question, not a calendar question.
Every process has an expiration date
Processes tend to accumulate.
They rarely volunteer to leave.
A control is added after a mistake.
An approval is added after a customer complaint.
A report is added after a board question.
A meeting is added after an initiative slips.
Three years later, nobody remembers why half of them exist.
But everyone is still doing them.
This is how organizations slowly turn reasonable decisions into unreasonable processes.
One of the most useful questions in an operational review is:
“If we were designing this process today, would we build it this way?”
Sometimes the answer is yes.
Often, there is an awkward silence.
That silence is useful.
Systems don’t fix operating models
Technology is often brought in precisely when complexity starts becoming painful.
Sometimes that’s exactly right.
But software is extraordinarily good at making a bad process happen faster and more consistently.
If nobody agrees on the workflow, a new system will not create agreement.
If ownership is unclear, a dashboard will not create ownership.
If teams use different definitions of the same metric, business intelligence will simply present the disagreement more attractively.
Before automating a process, understand it.
Before building a dashboard, agree on what matters.
Before implementing a workflow, decide who owns it.
Technology should reinforce the operating model.
It should not be asked to invent one.
Structure should follow the work
Org charts often evolve around people.
Someone is good at something, so responsibility gets added.
A leader leaves, so their work gets distributed among whoever is still standing.
A new executive is hired, so functions move.
Over time, the organization chart can become a remarkably accurate history of everything that has happened to the company.
That does not necessarily make it a good design for what needs to happen next.
A better question is:
What work must the organization perform exceptionally well at this stage?
Then:
What capabilities does that require?
Where should those capabilities live?
How should they connect?
And who should be accountable?
People matter enormously.
But structure should begin with the work.
Scale requires more clarity, not more control
There is a temptation, when performance becomes inconsistent, to respond with more approvals.
More oversight.
More reporting.
More checkpoints.
Sometimes that is appropriate.
Often it is compensating for something else.
The goal of a scalable operating model is not to centralize every decision.
It is to create enough clarity that more decisions can safely happen without senior leadership.
That requires clear priorities.
Clear roles.
Clear thresholds.
Clear metrics.
Clear escalation paths.
Clear expectations.
Clarity creates autonomy.
Ambiguity creates control.
Your management system should expose problems early
Healthy operating models make problems visible.
Not eventually.
Early.
If capacity is tightening, leadership should see it before service deteriorates.
If implementation timelines are slipping, the pattern should emerge before the customer escalates.
If a strategic initiative is stuck, management should know what decision is blocking it.
If margins are deteriorating, finance and operations should be talking about the same drivers.
The operating model should create a regular path from:
If problems only become visible when someone raises their voice, sends an escalation email or misses a board commitment, the management system is learning too late.
“Growing pains” should have a diagnosis
Some pain is normal.
Growth stretches people.
Roles change.
New layers take time to settle.
Processes need refinement.
Not every inconvenience requires an organizational redesign.
But “growing pains” can also become a convenient explanation for problems nobody has diagnosed.
The better questions are:
What specifically is breaking?
At what scale did it start breaking?
Is this a capacity problem, a process problem, a decision problem, a structure problem or a leadership problem?
What would need to change for it to work at twice the current scale?
Those questions lead somewhere.
“Growing pains” mostly leads to Advil.
Design for the company you are becoming
The goal is not to build an organization with enough process for every future scenario.
That creates the bureaucracy everyone was trying to avoid in the first place.
The goal is to build an operating model that works for the next stage.
Enough structure to create clarity.
Enough cadence to create accountability.
Enough data to make good decisions.
Enough delegation to prevent leadership bottlenecks.
Enough discipline that execution becomes repeatable.
And enough flexibility that you can redesign it again when the company changes.
Because it will.
The operating model is never finished
Organizations sometimes approach operating model design as a reorganization.
Boxes move.
Titles change.
A new structure is announced.
Done.
But an operating model is much broader than an org chart.
It is how the organization actually works:
Who decides.
Who owns.
How information moves.
How performance is reviewed.
How priorities are translated into work.
How teams coordinate.
How problems escalate.
How decisions turn into action.
Those things need to evolve as the business evolves.
The company you run today is not the company you built three years ago.
Your operating model shouldn’t be either.
A useful place to start
When execution begins feeling harder than it should, look beyond the org chart.
Ask:
Where are decisions getting stuck?
Where does accountability become unclear?
Which meetings no longer create value?
Which processes were designed for a smaller organization?
Where is leadership repeatedly being pulled into work that should happen elsewhere?
What breaks if the company grows another 50%?
You don’t need more process everywhere.
You need better structure where complexity has outgrown the way the company works.
Operational Strategy & Execution
Operating model design, process improvement, operating cadence, accountability and technology-enabled workflows—built around how the organization actually needs to work at its next stage.