Systems Thinking: Why Improving the Parts Doesn't Necessarily Improve the Whole

One of the most intuitive approaches to problem-solving is also one of the easiest to get wrong:

If you improve the parts, the whole system should improve.

It sounds obvious.

If a business wants to become more profitable, improve sales. If you want to become healthier, improve your diet. If you want to become more productive, improve your time management. If a factory wants to produce more, make each workstation faster.

Sometimes that works.

But systems thinking reveals an important complication:

An improvement to one part of a system does not necessarily improve the system as a whole.

In some circumstances, improving one component can even make the overall system perform worse.

The important lesson, however, is not that you should stop improving individual parts. Systems thinking is more useful than that. It teaches you to ask whether the part you are improving actually matters to the performance of the whole—and what consequences your improvement may create elsewhere.

The Whole Is More Than a Collection of Parts

A system consists of parts, but systems thinking is concerned with more than identifying those parts. It is concerned with how the parts interact.

Consider a car.

A car contains an engine, transmission, wheels, brakes, steering system, electrical system, suspension, and many other components. You could improve the engine by making it substantially more powerful.

But that does not automatically make the car better.

If the transmission cannot handle the additional power, reliability may decline. If the brakes are inadequate for the increased performance, safety may decline. If fuel consumption becomes excessive, operating costs may increase. If the suspension cannot handle the new performance characteristics, handling may suffer.

The engine itself may have been improved.

The system may not have been.

This distinction appears everywhere: in businesses, factories, organizations, families, personal finances, health, and daily routines.

Local Optimization vs. System Optimization

A useful way to understand this problem is to distinguish between local optimization and system optimization.

Local optimization means improving the performance of one component, department, process, or activity.

System optimization means improving the performance of the system considered as a whole.

These goals can conflict.

This idea is strongly associated with the management philosophy of W. Edwards Deming, who emphasized that organizations should be managed as systems rather than by independently optimizing their component parts.

Imagine a company divided into sales, production, shipping, and customer service.

The sales department is told to increase sales by 20 percent. The salespeople succeed.

That sounds like good news.

But suppose production was already operating near capacity. The additional orders create a backlog. Shipping becomes rushed. Customer service receives more complaints. Employees work longer hours. Errors increase. Customers become dissatisfied.

Sales improved.

The company's overall performance may have deteriorated.

The problem was not necessarily the sales department. The problem was optimizing one part without considering the constraints and interactions of the larger system.

Feedback Loops Can Change the Outcome

The interaction between parts becomes even more important when changes create feedback loops.

A feedback loop occurs when a change in one part of a system eventually affects another part, which then feeds back and influences the original condition.

Consider personal productivity.

Suppose you decide that the best way to accomplish more is to work longer hours.

At first, the strategy appears successful. You complete more work. Perhaps your income increases as well.

But working longer can reduce sleep. Less sleep can reduce concentration and energy. Reduced concentration can make work take longer. More unfinished work can increase stress. Increased stress can interfere with sleep.

Now the system contains a feedback loop:

More work → less recovery → lower performance → more unfinished work → more pressure to work

The original intervention—working more—may have produced an immediate benefit while simultaneously creating conditions that undermine the benefit later.

This is one reason systems can fool us. The first result you see is not necessarily the final result.

Delays Can Hide Problems

Feedback becomes particularly difficult to recognize when there is a delay between cause and effect.

Suppose someone works substantially more hours for several months. During the first few weeks, the consequences may look positive: more income, more completed projects, or faster progress toward a goal.

The negative consequences may take much longer to appear.

Fatigue accumulates gradually. Relationships receive less attention. Exercise becomes less consistent. Stress increases. Eventually performance may decline.

If you evaluate the decision too early, you might conclude that it worked perfectly.

A systems thinker therefore asks not only, "What happened immediately?" but also:

"What is likely to happen after the effects have had time to propagate through the system?"

This does not mean working more hours is always a bad decision. Sometimes it is exactly the right decision. The point is that the value of the intervention depends partly on what it does to the rest of the system over time.

The Bottleneck Changes the Meaning of Improvement

Another reason improving a part may not improve the whole is that the system may contain a bottleneck—a constraint that limits overall performance.

Eliyahu M. Goldratt developed the Theory of Constraints, which emphasizes identifying the constraint that limits a system's overall performance. His 1984 book The Goal popularized this approach in management.

Consider a simple sequential production process in which several stages can each process 100 units per hour, but one stage can process only 50.

Increasing another stage from 100 units per hour to 150 does not necessarily increase the output of the entire system.

It may simply create a larger pile of unfinished work before the bottleneck.

But imagine improving the bottleneck from 50 units per hour to 80.

That local improvement can genuinely improve the whole system.

This is an important distinction:

Systems thinking does not tell you to stop optimizing parts. It tells you to identify which parts are worth optimizing.

Suppose you want to write more articles. You become extremely efficient at researching topics. You collect hundreds of ideas and save dozens of sources.

But your bottleneck is not research.

Your bottleneck is actually writing.

Improving research efficiency may therefore produce an impressive collection of research—and very little additional finished writing.

You improved a part.

You just did not improve the constraint that determines the system's output.

Sometimes Local Optimization Is Exactly the Right Strategy

It is easy to overlearn the lesson and conclude that local optimization is bad.

That would be another mistake.

If a component is genuinely limiting the system, improving that component may be precisely what you should do.

Likewise, some improvements have little negative interaction with other parts of a system. If you can make a process faster without creating additional work, reducing quality, consuming a scarce resource, or creating another constraint, there may be no reason not to make the improvement.

The systems-thinking question is therefore not:

"Should I optimize this part?"

It is:

"How does improving this part affect the performance of the whole system?"

That question leaves room for both possibilities: sometimes the part should be improved, and sometimes your effort belongs somewhere else.

Why We Naturally Make This Mistake

There is a psychological reason this happens.

Individual components are easier to see than relationships.

It is easy to see that a salesperson made more calls, that a worker processed more units, that you completed more tasks, or that a department reduced its expenses.

It is harder to see what those changes did to everything else.

Human beings also tend to prefer simple cause-and-effect explanations:

"This is the problem, so let's improve this."

Systems thinking requires a more uncomfortable question:

"What else will change if I improve this?"

That question forces you to consider dependencies, feedback loops, constraints, delays, and unintended consequences.

The Parts Can Work Against Each Other

Different parts of a system can also have competing objectives.

Consider a business again.

The accounting department may be rewarded for reducing costs. Sales may be rewarded for increasing revenue. Customer service may be rewarded for resolving issues quickly. Operations may be rewarded for efficiency.

Each department can become better at its assigned objective while the organization as a whole becomes less effective.

For example, accounting might cut a software subscription to save money. That saves the company $20,000.

But if the software allowed employees to work substantially faster, the company might lose more than $20,000 in productivity.

From the accounting department's perspective, the decision looks successful.

From the perspective of the whole system, it may be a poor decision.

This is a central systems-thinking lesson: the best decision for a component is not necessarily the best decision for the system containing that component.

Don't Confuse a Better Metric With a Better System

Metrics are useful, but they can also mislead us.

British economist Charles Goodhart became associated with what is now known as Goodhart's Law. Its familiar modern formulation is: "When a measure becomes a target, it ceases to be a good measure." Goodhart's original formulation, from the 1970s, concerned statistical relationships used for policy control; the broader formulation became widely used in discussions of performance measurement.

Consider a customer-service department evaluated according to how quickly employees close tickets.

Management wants the number to fall, so employees become very efficient at closing tickets.

The metric improves.

But perhaps employees are now closing complicated cases prematurely, causing customers to call back repeatedly.

The department's reported performance has improved.

The customer's experience may have become worse.

The deeper systems lesson is that a measurement is not the same thing as the purpose of the system.

The same thing can happen personally.

If you measure productivity only by the number of tasks completed, you may optimize for easy tasks rather than important ones. If you measure fitness only by weight, you may overlook other dimensions of health. If you measure financial success only by income, you may overlook debt, savings, risk, and quality of life.

The number is a representation of the system.

It is not the system itself.

Sometimes Removing Something Is Better Than Improving It

Systems thinking can produce another counterintuitive conclusion:

The best way to improve a system may sometimes be to eliminate something rather than improve it.

People often respond to problems by adding.

Add another meeting. Add another software tool. Add another report. Add another productivity technique. Add another rule.

But every addition can create another component that the system must coordinate.

Sometimes the better question is:

"What can I remove?"

Eliminating an unnecessary meeting may improve productivity more than making meetings more efficient. Eliminating an unnecessary approval step may improve a workflow more than training employees to process approvals faster. Eliminating a recurring distraction may be more effective than learning another concentration technique.

But removal is not automatically beneficial. Redundancy, extra inventory, safety checks, and backup procedures can sometimes protect a system from failure.

The systems-thinking principle is therefore not simply "remove things." It is:

Question whether each component contributes enough value to justify the complexity it creates.

The Whole Can Place Limits on the Parts

Sometimes the larger system determines what an individual component can accomplish.

A highly skilled employee cannot necessarily overcome a badly designed workflow. A talented salesperson cannot overcome a product that customers do not want. A motivated student cannot completely compensate for inadequate learning materials. A disciplined person cannot always overcome an environment that creates enormous friction.

This does not mean individuals have no agency.

It means performance is partly a property of the system in which the component operates.

Put the same person into a different system and you may get a different result.

This is one reason systems thinking can change how we think about blame. Instead of asking only, "Why did this person fail?" we can also ask, "What conditions made this outcome more likely?"

Look at What the System Actually Produces

A useful systems-thinking question is:

"What outcome does this system's actual structure, incentives, information, and constraints tend to produce?"

This can reveal contradictions between what people say they want and what the system is designed to produce.

A business may say it wants to satisfy customers, while its incentive system rewards employees primarily for minimizing call times.

A person may say the goal of a career is to create a good life, while their behavior systematically sacrifices health, relationships, and personal time for income.

A school may say it wants students to learn, while its incentives push teachers and students toward maximizing test scores.

When stated goals and system structure conflict, behavior often follows the structure.

That is why changing incentives, information flows, rules, or constraints can sometimes accomplish more than simply telling the people inside the system to work harder.

A Practical Test: Did the Whole Actually Improve?

When you make an improvement, step back afterward.

Do not immediately assume success because the thing you targeted got better.

Ask:

• Did the overall outcome improve?
• Did another part of the system deteriorate?
• Did a bottleneck move somewhere else?
• Did the improvement create new demands elsewhere?
• Did the system respond in an unexpected way?
• Did the improvement last?
• Could delayed consequences appear later?

These questions are especially useful when the system contains significant delays.

A decision can look successful today and produce a very different result six months from now.

Think Globally, Then Act Locally

There is a useful balance between systems thinking and practical action.

You do not need to understand every variable in your life before making a decision.

You simply need to avoid confusing a local improvement with a system-wide improvement.

A good approach is:

1. Understand the larger system. Identify the important components, relationships, constraints, and goals.
2. Look for the constraint. Ask whether a bottleneck is limiting the result.
3. Consider feedback and delays. Ask what effects may appear elsewhere or later.
4. Make a focused change. Do not change everything simultaneously.
5. Watch the rest of the system. Look for unintended consequences and new constraints.
6. Evaluate the whole outcome. Did the system actually move in the desired direction?
7. Update your mental model. If reality surprised you, learn from the surprise.

This combines the strengths of analytical thinking and systems thinking.

You still improve individual parts.

You simply do so with an understanding of the larger structure.

The Deeper Lesson

One of the most important lessons of systems thinking is that the quality of a system cannot always be inferred from the quality of its individual parts.

A company can have talented employees and still perform poorly.

A person can have excellent habits in several areas and still have a dysfunctional routine.

A machine can contain high-quality components and still be poorly designed.

A team can contain brilliant individuals and still make terrible decisions.

Why?

Because interaction matters.

Structure matters. Constraints matter. Incentives matter. Feedback matters. Timing matters. Relationships matter.

And sometimes the most important feature of a system is not any individual component at all. It is the way the components are arranged and connected.

The Question to Remember

The next time you identify something that needs improvement, do not immediately ask:

"How can I make this better?"

Ask a slightly larger question first:

"If I make this part better, what will happen to the whole system?"

That question can prevent you from solving the wrong problem, strengthening the wrong component, ignoring a bottleneck, optimizing the wrong metric, or producing an unintended consequence.

But it can also lead to a more positive discovery: sometimes the part you improve really is the part that matters most, and the whole system gets better as a result.

That is the deeper lesson.

Systems thinking is not about choosing the whole instead of the parts. It is about understanding the parts in relation to the whole.

You stop asking only how to make individual pieces better.

You start asking which improvements will make the system work better.