Change for the Sake of Change Is Not a Business Model

Throughout my career, I've been responsible for changing how businesses operate.

I've led turnarounds, redesigned production systems, introduced new technologies, and challenged practices that had been accepted for decades.

I believe strongly in continuous improvement.

But I have also witnessed firsthand how poorly conceived change can waste resources, undermine an operation, and threaten the financial health of a business.

Two experiences in particular shaped how I approach operational improvement today.

One taught me what happens when we incentivize change for its own sake.

The other demonstrated what happens when we change a process without understanding why it works.

When change becomes the objective

During my time at General Electric, salaried employees in my organization were required to complete two Six Sigma improvement projects and four smaller initiatives, known as NIKE projects, each calendar year.

Six improvement projects per employee, every year.

The intention was understandable. Establish continuous improvement as part of everyone's responsibilities. Encourage employees to question established practices and actively look for opportunities to improve performance.

But there was a fundamental flaw in the approach.

Project completion became a performance expectation, regardless of whether six meaningful improvement opportunities actually existed.

And when you make change a requirement for someone's annual performance review, you create an incentive to find something, anything, to change.

I witnessed processes modified through one improvement project, only to be changed back through another.

Both projects could satisfy someone's annual performance requirements.

Consider the economics of that situation.

Time was spent identifying, documenting, implementing, and validating a change. Additional resources were then spent reversing it. Employees had to adapt to both approaches, and the business absorbed the disruption.

In the end, the operation was right back where it started.

But the project metrics showed activity.

We had created a system in which changing something could be more valuable to an individual's performance evaluation than determining whether it needed to be changed at all.

The problem wasn't Six Sigma.

The problem was how we defined and rewarded success.

When change destroys the value you already have

Years later, at PPC Broadband, I encountered a different and potentially more damaging example.

I inherited a machining operation that was struggling financially.

An earlier continuous improvement initiative had replaced an established production sequencing wheel and economic run quantities with a make-to-order approach.

On the surface, the change seemed consistent with accepted Lean manufacturing principles. Reduce inventory, produce to demand, and eliminate unnecessary production.

But there was a problem.

The people implementing the change had not adequately understood the process they were replacing or the economics that made it work.

The original production model wasn't simply an outdated habit. It accounted for the relationship between changeover time, production quantities, equipment capacity, and manufacturing cost.

When that model was abandoned, those underlying constraints didn't disappear.

Changeovers still consumed capacity. Small production runs still carried setup costs. Labor and overhead still needed to be absorbed by productive output.

The new system had changed how production was scheduled without adequately accounting for the financial consequences.

The result was a machining department operating in the red.

The irony was difficult to ignore. A process improvement initiative had damaged the financial performance of the very operation it was intended to improve.

When I examined the historical SAP data, the problem became evident.

The previous production model had been built around economic realities that the replacement approach failed to adequately consider.

We restored economic run quantity discipline and the established sequencing approach.

The results were virtually immediate. The department moved from operating at a loss to achieving full cost absorption.

We hadn't discovered a revolutionary new methodology.

We had recognized why the previous system worked.

And sometimes, that understanding is more valuable than any proposed improvement.

Before changing a process, understand why it exists

There is an important distinction between questioning an established process and assuming that process is wrong.

In manufacturing, many practices develop over years of trial, error, adaptation, and accumulated experience.

Some survive because nobody has challenged them.

Others survive because they solve problems that aren't immediately apparent to someone unfamiliar with the operation.

A production sequence may exist to minimize changeovers. A particular batch size may reflect economic constraints. An unconventional material flow may accommodate equipment limitations or quality requirements.

Without understanding those relationships, even a well-intentioned improvement can create consequences far beyond the specific process being modified.

Reducing inventory may increase conversion costs. Increasing equipment utilization may create excess work in process. Reducing purchasing costs may increase total supply chain expense.

An improvement in one metric can become a deterioration in overall business performance.

That doesn't mean existing processes should be protected from scrutiny.

Quite the opposite.

It means we have an obligation to understand them before deciding what should change.

Continuous improvement is not continuous change

As a Lean Six Sigma Black Belt, I've spent decades applying structured problem-solving and process improvement methodologies.

I believe in their value.

But methodologies are tools. They are not substitutes for understanding the business.

Nor should they become performance exercises where completing the prescribed number of initiatives matters more than the value those initiatives deliver.

I believe every proposed change should answer a few fundamental questions.

What problem are we solving?

Why does the current process operate as it does?

What relationships and constraints does it accommodate?

What evidence suggests the proposed change will produce a better outcome?

And how will we verify that the improvement is real, sustainable, and beneficial to the business as a whole?

If we cannot answer those questions, perhaps we aren't ready to implement the change.

Sometimes the correct decision is to redesign the process.

Sometimes it is to restore something that worked better before.

And sometimes, the most valuable decision a leader can make is to leave a functioning process alone.

The responsibility of leadership

The experiences at GE and PPC taught me two complementary lessons.

At GE, I saw how measuring improvement activity instead of improvement outcomes could encourage unnecessary change.

At PPC, I saw how failing to understand an existing process before replacing it could fundamentally damage an operation's economics.

Both originated from the pursuit of improvement.

Neither delivered the intended outcome.

Leadership isn't demonstrated by how many processes we redesign, how many initiatives we launch, or how much change we introduce.

It's demonstrated by whether the organization performs better because of our decisions.

We should challenge complacency relentlessly.

But we should challenge unnecessary change with equal conviction.

Change for the sake of change is not a business model.

And change without understanding can destroy the very value you're trying to create.

The objective was never to make things different.

It was to make them better.