Where Should Continuous Improvement Sit If Its Responsibility Is the Whole System?
Continuous Improvement is often expected to improve the whole organization while being structurally confined to only one part of it. This article explores how reporting lines can limit independence, influence, and the ability to address problems that cross functional boundaries.
THINKING DIFFERENTLY
Where Should Continuous Improvement Sit If Its Responsibility Is the Whole System?
There was a joke I heard often in Operations:
“Our job is to turn Sales promises into reality.”
Most of the time, it was said with a smile.
Sometimes, however, promises was a polite substitute for something closer to wishful thinking.
A delivery date had already been committed. A special configuration had been offered. An expectation had been created with the customer. And somewhere downstream, Operations had to figure out how to make it happen.
The joke was funny because everybody recognized some truth in it.
But it also revealed something deeper about how organizations are designed.
Where a problem appears is not necessarily where it originates
Many operational problems become visible on the shop floor, in a warehouse, in customer service, or in delivery performance.
But they may have originated somewhere else.
A production problem may begin with a commercial commitment.
An inventory problem may begin with a financial policy.
A quality problem may begin in Engineering.
A scheduling problem may begin in the way priorities are established.
A service problem may begin with information that never flowed properly across functions.
By the time the consequence reaches Operations, it is very real.
But improving Operations alone may do very little about the mechanism that created it.
The problem may appear in Operations without originating in Operations.
That distinction matters when we decide where Continuous Improvement, TPS, Lean, Six Sigma, Operational Excellence, or similar functions belong in the organization.
The place in the organization shapes the scope of the work
In many companies, Continuous Improvement sits somewhere under Operations or Manufacturing.
There are understandable reasons for this.
Factories make waste visible.
Processes are tangible.
Lead time, defects, inventory, productivity, downtime, and flow can be measured.
And historically, many improvement approaches entered organizations through manufacturing.
But the location of the improvement function can quietly define what the organization believes improvement is for.
Put it inside Manufacturing, and it may gradually become a Manufacturing improvement function.
Put it inside Operations, and it may become responsible primarily for operational performance.
The tools may be capable of much more.
The people may be capable of much more.
But the organizational structure is already establishing boundaries around their influence.
Being part of the system you are expected to challenge
I experienced another side of this personally.
My Continuous Improvement responsibility sat under Operations.
I was never asked to hide a result, manipulate information, or make performance look better than it actually was.
That distinction is important.
There was no explicit pressure to distort reality.
But organizational pressure does not always need to be explicit.
When the same leadership structure that evaluates you, supports you, funds your initiatives, and defines your priorities is also part of the system you may need to challenge, a subtle tension exists.
You become, in some situations, both observer and participant.
Judge and party.
You know that your responsibility is to make problems visible.
But you also know where you sit on the organization chart.
Nobody needs to tell you what not to say for the structure to influence what feels comfortable to challenge.
A system can distort what gets challenged without ever asking anyone to distort the truth.
This is not necessarily a problem of ethics.
It is a problem of design.
Responsibility without reach
There is another limitation.
Suppose the improvement function identifies that an operational problem is being generated by decisions outside Operations.
What happens next?
Perhaps Sales is creating commitments without enough visibility into capacity.
Perhaps Engineering is creating complexity that Manufacturing absorbs later.
Perhaps Finance is optimizing working capital in a way that increases another form of operational instability.
Perhaps IT priorities are creating workarounds that people have normalized.
Perhaps Purchasing is optimizing unit price while increasing total system cost.
The improvement team may be able to see the connection.
But does it have the organizational reach to influence it?
That can be surprisingly difficult.
A person from Operations questioning a commercial process may be perceived as Operations interfering with Sales.
Someone from Manufacturing challenging an Engineering practice may trigger a functional boundary.
A CI manager raising questions about financial policies may simply not have the hierarchical standing to make the conversation happen.
This creates an uncomfortable situation:
Continuous Improvement may be given responsibility for problems whose causes lie beyond its authority.
And when that happens, organizations often improve the consequence instead of addressing the mechanism.
“Customer first” does not mean “Sales first”
Sales is often one of the functions closest to the customer.
That makes its voice extremely important.
But proximity to the customer does not mean ownership of the whole customer experience.
The customer eventually experiences the result of the entire system:
the promise,
the product,
the delivery,
the quality,
the service,
the support,
and the organization’s ability to perform consistently over time.
So customer first should not mean Sales first.
It should mean aligning the organization around customer value.
That requires Sales, Operations, Engineering, Finance, Supply Chain, IT, HR, and every other function to work as parts of the same system.
The issue is not which function serves which.
The issue is how the functions work together to serve the customer.
And that is exactly the kind of relationship a mature improvement function should help the organization see.
Improvement lives between the boxes
Organization charts show boxes.
Reality happens between them.
Many of the most important problems in a company are not purely Manufacturing problems, Sales problems, Engineering problems, or Finance problems.
They are interface problems.
They happen when information crosses boundaries.
When objectives conflict.
When one function optimizes its KPI at the expense of another.
When a perfectly rational local decision creates an irrational system outcome.
When nobody is doing anything obviously wrong, yet the organization still struggles.
This is precisely where a mature improvement function can create enormous value.
Not by telling every department how to do its work.
Not by becoming the Lean police.
Not by owning every improvement initiative.
But by helping the organization see relationships that functional structures naturally tend to hide.
So where should Continuous Improvement sit?
I do not think there is one universal box on the organization chart that solves the problem.
Moving Continuous Improvement directly under the CEO does not magically create systemic thinking.
Creating a Corporate Excellence department can just as easily create bureaucracy.
And a centralized improvement organization disconnected from daily work can become another staff function producing presentations and standards that nobody owns.
The answer is probably not simply higher.
It is more transversal.
An improvement function needs enough independence to question the system honestly.
Enough access to leadership to raise uncomfortable systemic issues.
Enough proximity to the work to understand reality.
And enough legitimacy across functions to facilitate improvement without being perceived as representing only one department’s interests.
Most importantly, its purpose must be clear.
If its mission is to improve Manufacturing, then placing it inside Manufacturing may be entirely reasonable.
If its mission is to improve Operations, the same applies.
But if its responsibility is to help the organization learn and improve as a system, then its design should reflect that responsibility.
Because improvement is not simply another function.
At its best, it develops the organization’s ability to see itself.
To recognize connections.
To challenge assumptions.
To learn from gaps between expectation and reality.
And to improve across the boundaries that the organization chart inevitably creates.
Perhaps that is the real question we should ask before deciding where Continuous Improvement belongs:
Are we creating a department that improves processes — or a capability that helps the whole organization learn?