When Efficiency Takes More Than It Gives

When Efficiency Takes More Than It Gives

Why improving a process should not mean asking more of the people who work in it

Improvement is supposed to make things better.

We eliminate unnecessary movements, reduce waiting, simplify tasks, prevent errors, and remove activities that add no value.

The process becomes more efficient.

And then someone notices the time we have saved.

“Great! Now that we have more capacity, what else can we do?”

It’s a reasonable question.

But depending on how we answer it, we may end up undoing much of what we just accomplished.

What Are We Actually Trying to Improve?

Imagine a situation I could easily have encountered during my years working with TPS.

We needed to deliver 50 units per hour.

But the production charts told a different story. Over the previous several periods, we had consistently delivered around 40.

The gap was obvious.

We needed 25% more output.

Someone suggested increasing the pace.

It sounded reasonable. After all, if we needed more units, we had to produce them faster.

But I would have wanted to ask a different question.

What was preventing us from producing 50 units in the first place?

So, imagine we went to the Gemba.

We watched the process.

Operators walked back and forth to retrieve materials. Some tools were not where they were needed. Occasionally, work stopped while someone corrected a defect from an earlier operation.

Nobody appeared to be wasting time deliberately.

In fact, everyone seemed busy.

But being busy and creating value are not necessarily the same thing.

Suppose we rearranged the materials, improved tool accessibility, and addressed the conditions producing those defects.

Gradually, interruptions decreased.

The work became easier.

And the process began delivering 50 units per hour.

Not because people walked faster, concentrated harder, or skipped breaks.

But because we removed obstacles that made their work unnecessarily difficult.

The numerical result was exactly what we needed.

But the way we achieved it mattered just as much.

We didn’t make people work faster. We made it easier for them to work at the pace the customer required.

The Customer Sets the Pace

Now imagine someone looking at the improved results and asking:

“Great. If we can produce 50, do you think we could push for 60?”

Before answering, we should ask something else.

Does the customer need 60?

If demand remains at 50 units per hour, producing 60 may simply create inventory, additional handling, occupied space, and the risk of producing something the customer does not need.

In TPS, customer demand establishes the required production pace.

Our responsibility is to develop a process capable of meeting that pace consistently, with quality and without unnecessary strain.

A process that runs faster than necessary is not automatically a better process.

And one that meets demand only through extraordinary human effort is not necessarily stable.

Improvement creates capacity. Customer demand determines the pace we need to meet.

Of course, demand may change. A process capable of producing 60 units could provide valuable flexibility if demand increases.

But having that capability is different from using it simply because it exists.

What Happens to the Time We Save?

Let’s return to our hypothetical process.

We can now deliver the required 50 units more consistently, with fewer interruptions and less unnecessary effort.

What should we do with the capacity we’ve released?

Perhaps we can introduce additional activities.

There is nothing inherently wrong with that.

People can develop new skills, take on meaningful responsibilities, support other processes, or perform work that previously could not be accommodated.

But first, we need to make sure the original work can maintain its rhythm.

The time we’ve released should help establish conditions in which tasks can be performed correctly and consistently, with fewer errors and less rework.

If we immediately fill every available minute, we risk recreating the conditions we worked to eliminate.

People begin rushing.

Abnormalities go unnoticed.

Errors increase.

Rework returns.

And the time we supposedly saved disappears into correcting problems that should never have occurred.

Any additional activities need their own appropriate rhythm, standards, and conditions for successful execution.

They must also fit within the available capacity without compromising the stability of existing work.

This is why available capacity should not automatically be interpreted as wasted capacity.

Some of it allows us to respond to variation, recognize abnormalities, solve problems, and maintain quality.

A system operating at full theoretical utilization is not necessarily operating at its best.

Sometimes, the margin we are tempted to eliminate is precisely what keeps the system stable.

Making Work Easier Is Not the Same as Asking People to Work Faster

There is a subtle difference between reducing the time required to perform a task and pressuring someone to perform that same task faster.

It may appear to be the same thing.

It isn’t.

If an operator must walk ten meters to retrieve a tool, we can ask that person to walk faster.

Or we can move the tool closer.

If an employee spends several minutes checking information across different systems, we can demand greater concentration.

Or we can simplify how that information is presented.

If a process frequently produces defects, we can remind people to be more careful.

Or we can investigate why the process allows those defects to occur.

In each case, the first response depends primarily on additional individual effort.

The second changes the conditions under which the work is performed.

This doesn’t mean capability, discipline, or attention are unimportant.

They matter enormously.

But they should not become permanent substitutes for a poorly designed process.

Real improvement doesn’t ask people to compensate for the limitations of the system. It changes the system so they no longer have to.

Of course, not every demand can be met through process improvements alone.

Sometimes additional equipment, staffing, investment, or a different commitment to the customer is necessary.

Recognizing those limitations is not failure.

Expecting people to compensate for them indefinitely is.

Efficiency Has a Human Dimension

There is another consequence of improvement that deserves our attention.

The people performing the work have lives beyond it.

Families. Friends. Interests. Responsibilities. Dreams.

They need time to rest and recover.

Not merely because recovery supports sustainable performance, although it does.

But because their lives matter beyond the workplace.

We work to live.

We don’t live to work.

A system that consistently meets its targets by exhausting the people who operate it may appear successful on a performance dashboard.

But something important is missing from that picture.

We pay considerable attention to equipment reliability, preventive maintenance, and operating conditions.

We understand that machines cannot run indefinitely without care.

Yet we sometimes treat human recovery as an obstacle to productivity rather than a necessary part of sustainable work.

And unlike machines, people should not need to justify their time outside work by demonstrating how it benefits the company.

Respect for people should be visible in how we design their work, establish expectations, and respond when the process cannot meet demand.

Not only in what we say about them.

What Did Our Improvement Really Give Us?

When a Kaizen releases time, I believe we should resist the temptation to immediately fill it.

First, we should understand what that time represents.

Have we eliminated unnecessary effort?

Have we reduced the likelihood of defects?

Can the process now meet customer demand consistently?

Have we created enough stability to sustain the improvement?

And if we introduce new responsibilities, can they be performed without compromising what we’ve achieved?

These are not arguments against growth or productivity.

They are questions about how to achieve both without making the system more fragile.

A genuine improvement should do more than produce a better number.

It should make the work easier to perform correctly, the process more reliable, and the results more sustainable.

And it should make us question whether the people doing the work are benefiting from those improvements, too.

If our systems keep getting better, shouldn’t life get a little better for the people working in them, too?

Perhaps that’s one of the most important ways to recognize whether our efficiency improvements are giving us more than they take away.