The Measurement Trap

1. The Paradox at the Heart of Modern Management

Most organizations believe that more measurement leads to better performance. In reality, the opposite is often true.

The more you measure, the worse your system becomes.

You have seen it happen. You may even be managing it right now.

A KPI is introduced. People hit the target. Yet somehow, the business does not improve. Sometimes it gets worse. Customers complain more. Employees burn out. Decisions get dumber.

This is not a mystery. It is a system. And once you see it, you cannot unsee it.

2. A Strange Thing Happened at a Software Company

A mid-sized B2B software company in Ho Chi Minh City, Vietnam was proud of its sales team. Every day, each salesperson made at least 20 new calls. The logic seemed unassailable: more calls → more meetings → more deals. Management tracked this KPI religiously. They rewarded the top callers.

After six months, the numbers looked great. Call volume was up 40%. Quotes sent to clients were up 25%. But revenue? Flat. Worse, the conversion rate from quote to closed deal had dropped by 15%.

What happened? The sales team did exactly what they were asked. They made the calls. But they made them fast — often under a minute. They called numbers that had already rejected them three times. They even called during office hours when decision-makers were least available.

This is not a story about lazy or dishonest employees. This is a story about a system that designed the wrong behavior. And it happens every day. In every industry. In every country.

3. The Birth of The Distortion Framework

Over time, I began to see the same pattern everywhere. Different industries. Different countries. The same failure. I call this pattern The Distortion Framework.

The framework argues that organizational failure is not primarily caused by bad people, bad luck, or bad markets. It is caused by three interconnected distortions that feed on each other in a self-reinforcing loop:

These three do not operate in isolation. They form a loop. Measurement distortion creates behavioral distortion. Behavioral distortion hardens into structural distortion. Structural distortion then generates even more misleading signals, reinforcing the original measurement distortion.

4. Why This Framework Is Different

Most management books assume that the problem is execution. That if people just tried harder, followed the process, or used better tools, performance would improve.

This book takes a different view. The problem is not execution. The problem is design.

The book is structured in three parts:

• Part I – The Problem: Why measurement fails in complex systems (Measurement Distortion, Behavioral Distortion, Structural Distortion)
• Part II – Seeing the System: Tools to understand your organization as a flow (Value Stream Mapping, House of Quality, Root Cause Analysis)
• Part III – Redesigning Management: How to design KPIs, incentives, and learning loops that actually work

5. Where This Book Stands

The management literature is not short of books about measurement and performance. So it is worth being specific about what this book does — and does not — attempt to do.

Throughout this book, we will follow a real case: the collapse of Iceland's national cremation system. A 1948-era facility. A PM₂.₅ breach on 52 days per year. Families waiting 18 days. A governance system that knew what was wrong — and kept doing it anyway. It is, in miniature, every organization's story.

Case source: Nguyen, N.S. (2025). Case Study Workbook: Reykjavík Crematorium Reform. University of Otago DBA Program. Used with permission.

Most of those books assume measurement is neutral — that the challenge is choosing the right metrics and executing them well. This book challenges that assumption at its root. Measurement is not neutral. The act of measuring changes what is being measured, the people doing the measuring, and the system around them. That is the trap.

6. Who This Book Is For

This book is for anyone who has ever felt trapped by their own dashboard. If you are a CEO, a senior manager, a consultant, or a team leader — and you have ever asked yourself, "Why do my numbers look good while my business feels bad?" — this book is for you.

1. The Fallacy That Destroys Performance

Here is a belief embedded in almost every organization: if every department does its job well, the whole company will succeed. It sounds reasonable. Even obvious. But it is wrong.

This belief is one of the most damaging assumptions in modern management. In fact, optimizing each part separately is one of the fastest ways to destroy the performance of the whole. This is not a paradox. It is how complex systems work.

2. Three Trucks and a Bridge

Imagine a small delivery company with three trucks. Each truck can carry 10 tons. Each can make eight trips per day. On paper, the maximum daily capacity is 240 tons (3 trucks × 10 tons × 8 trips). But there is a problem. All three trucks share a single bridge. The bridge allows only one truck to cross at a time.

If each truck driver optimizes their own performance — leaving the depot at 8 AM fully loaded — they will all queue at the bridge. Instead of 24 trips per day, they might manage 15. The system is worse than the sum of its parts.

Now imagine a different approach. The drivers stagger their departures. One leaves at 8 AM, another at 10 AM, another at noon. The bridge stays busy, but no one waits. Total trips increase — even though each individual driver does "worse" by waiting longer to start.

This is local optimization. And it is everywhere in modern organizations.

3. Local Optimization in Real Organizations

"A bad system will beat a good person every time."

— W. Edwards Deming

4. Why Local Optimization Is So Tempting

If local optimization is so destructive, why do almost all organizations reward it? There are at least three reasons:

• It is easy to measure. You can set a target for each department. You cannot easily set a target for "how well three departments collaborate."
• It creates the illusion of accountability. You can say "The sales manager owns revenue." But when something goes wrong, no one takes responsibility for the gap between departments.
• It makes leaders feel in control. When you look at a dashboard full of green indicators, you feel good. Only later — when customers leave or profits drop — do you see the cost.

1. The Most Expensive Mistake in Management

Organizations measure what is easy, not what matters. They reward motion, not progress. They confuse being busy with creating value. And the more you reward it, the worse it becomes.

2. Two Stories, One Pattern

Story one: A software company in Ho Chi Minh City, Vietnam. The sales team had a KPI: 20 new calls per day. After six months, call volume was up 40%. Quotes sent were up 25%. But revenue was flat. The conversion rate from quote to deal had dropped by 15%. They optimized the activity. Not the outcome.

Story two: A manufacturing plant in Binh Duong, Vietnam — an industrial province approximately 30 km north of Ho Chi Minh City. The production team had a KPI: machine utilization above 90%. After six months, utilization was up from 72% to 91%. But finished goods inventory had doubled. Storage costs were up 35%. When the market shifted, half the inventory became obsolete. They optimized the activity. Not the outcome.

Two different industries. Two different countries. The same failure.

3. The Activity–Outcome Stack

To understand this failure, you need a simple but powerful framework — The Activity–Outcome Stack^¹. It distinguishes four layers of performance:

Most organizations measure inputs and activities. Some measure outputs. Very few measure outcomes. And here is the problem: activities and outcomes are not the same thing. Sometimes they are not even related.

4. Why Organizations Confuse Activity with Outcome

• Activity is easy to measure. Outcome is hard. You can count calls. You cannot easily measure "quality of customer relationship."
• Activity can be controlled immediately. Outcome is delayed. You can tell someone to make 20 calls today. You cannot tell them to close a deal today.
• Activity creates the feeling of progress. Over time, activity replaces outcome as the definition of performance.

1. The Most Important Question No One Asks

Pick any process in your organization. A customer order. A product return. A hiring request. A budget approval. Now answer three questions:

1. How long does it take from start to finish — not the ideal time, but the actual time you can measure?
2. How much of that time is spent creating value versus waiting?
3. Who in your organization can draw the exact path this process takes — not the theory, but what actually happens every day?

If you cannot answer these questions, you are not alone. Most organizations cannot. And yet, they manage these processes every day.

2. The Birth of Value Stream Thinking

In the 1980s, researchers studying Toyota's production system^¹ discovered something surprising. Toyota did not just optimize machines or workers. They mapped the entire flow of a product — from raw material to customer — and asked a single question at every step: Does this step create value, or is it waste?

The insight was radical. Most organizations manage by departments. Each department optimizes its own piece. But value does not flow vertically through departments. It flows horizontally — across functions, across buildings, across systems. The gaps between departments — where no one is responsible — are where most value is lost.

3. A Simple Example: The Consulting Firm

Imagine a small consulting firm. A client requests a quote. Here is what actually happens:

Total time: 10 days. Actual processing time: about 2 days. Eight days were waiting^². Every department met its KPIs. But the system took ten days. No one was responsible for the eight days in between.

4. What Becomes Visible When You Map the Flow

When you actually map the flow for the first time, three things become visible:

• You see the steps. Every handoff. Every approval. Every wait. Most people are surprised by how many steps exist — and how many add no value.
• You see the gap between processing time and waiting time. Actual work usually takes minutes or hours. Waiting takes days or weeks. The ratio is often 1:10 or worse.
• You see the information flow. Who signals whom? Where do delays enter the system?

1. The Most Expensive Question You Never Ask

Here is a question I rarely hear in boardrooms: "Are we building the right thing?" Instead, I hear: "Are we building it right?"

Efficiency. Speed. Cost reduction. These matter. But they are useless if you are building the wrong thing. You can have a perfectly smooth, efficient flow — and still create something customers do not want. You can hit every internal KPI — and still lose market share.

2. Two Stories of Misalignment

Story one: A software company launched a new feature. They worked hard. Met the deadline. Stayed under budget. The code was clean. Customers did not use it. When asked, they said: "It is fine. But it is not what we need."

Story two: A logistics company reduced delivery time by 30%. Costs dropped by 15%. Customer satisfaction did not move. When they investigated, they discovered customers had never complained about speed. They complained about accuracy — wrong items, wrong addresses, missing pieces. The organization optimized the wrong thing. Not because they were lazy. Because they never asked the right question.

3. A Tool That Translates

In the late 1960s, Japanese quality experts Yoji Akao and Shigeru Mizuno developed a tool to solve exactly this problem. They called it Quality Function Deployment. Its centerpiece became known as the House of Quality.

The insight was simple but powerful: Do not design anything until you know which customer needs matter most — and which technical specifications actually affect those needs.

4. A Real Example: Reykjavík, Iceland — Crematorium Reform

The following House of Quality comes from an actual policy design case involving Iceland's national cremation infrastructure. Iceland (population approximately 370,000) has a single national crematorium located in Reykjavík, the capital. This facility — a 1948-era installation — was breaching PM₂.₅ air quality limits on 52 days per year while also failing to meet service capacity for a growing population. The question was: which engineering interventions would create the most value for stakeholders?

What makes this example powerful is that it is not a commercial product. It is a governance problem — and the House of Quality applies with equal force. Stakeholder needs include clean air, short waiting times, affordable pricing, multi-faith flexibility, low noise impact, and transparent emissions data. Engineering capabilities range from stack height and emission filters to digital booking systems and modular plant layout.

What the matrix reveals: Redundant retort capacity (20.1%) and electric throughput (14.8%) have by far the highest leverage — they address multiple high-priority stakeholder needs simultaneously, including the critical backup capacity requirement (importance 5) and short wait times. Stack height ranks third at 7.6%, primarily driven by clean air and low noise.

But here is the insight that pure engineering analysis misses: the two highest-leverage interventions are also the most capital-intensive. Capital cost and energy use score low on importance — meaning stakeholders want high performance at low cost. This is not a technical trade-off. It is a governance trade-off. The technically optimal solution may be politically undeliverable.

This is precisely why the House of Quality matters. It does not just tell you what to build. It tells you where the real constraints are — and forces you to design for them.

1. The Story of the Broken Machine

Most problems do not start where they appear.

A factory had a problem. An important machine kept stopping. Each time, the fuse was blown. Each time, maintenance replaced it. The machine ran again. Then it stopped again. One engineer did something different — he asked why.

The fuse was not the problem. It was a symptom. The root cause was a missing job description. This is the difference between fixing symptoms — and solving problems. Most organizations do the first. Almost none do the second consistently.

2. The 5 Why — The Most Underused Question in Management

When something goes wrong, ask "why?" Then ask it again. And again. Until you reach something you can change. This is called 5 Why.

The rule is simple: do not stop until you find a process, a design, or a responsibility — not a person. If your answer blames an individual, you have not gone deep enough.

— The Distortion Framework Operating Principle

3. When Causes Have Many Branches — The Ishikawa Diagram

Some problems have not one cause but many. For these, you need the Ishikawa (fishbone) diagram. You write the problem at the "head" of the fish (on the right). Then you draw "bones" for each category of potential causes:

• People (skills, training, fatigue)
• Machines (calibration, age, maintenance)
• Materials (quality, consistency, storage)
• Methods (procedures, standards, documentation)
• Measurement (accuracy, frequency, feedback)
• Environment (temperature, lighting, noise)

Most organizations blame people. The fishbone diagram forces them to blame the system.

4. Two Learning Loops: PDSA vs DMAIC

In a healthy organization, PDSA runs every week. DMAIC runs a few times a year. They are not alternatives — they are complements.

5. The Hidden Prerequisite: Gemba

None of these tools work if you stay in the boardroom. Gemba is a Japanese word meaning "the real place" — where value is created. On the factory floor. At the customer service desk. In the warehouse. You cannot find root causes from a dashboard. You cannot see waste from a spreadsheet. You have to go and see. There is no shortcut.

1. The Dashboard That Lied

Most KPI systems fail quietly — until they fail completely.

Imagine you are flying a plane. Your cockpit has one instrument: a fuel gauge. It reads full. You take off. Halfway through the flight, the engine sputters. You look at the gauge. Still full. You ignore the sputter. The engine stops. You crash. The gauge was not broken. It was measuring the wrong thing. This is how most organizations manage.

2. The Difference Between Reporting and Controlling

3. Three Layers Most Managers Miss

• Layer 1: Measure — raw data. 1,247 calls. 42 minutes. 15 defects. Alone, it means nothing.
• Layer 2: Metric — data with a time frame. 124.7 calls per day. Still means nothing without context.
• Layer 3: Indicator — a metric with a target, a threshold, and a strategic purpose. "Customer satisfaction ≥ 85%" is an indicator. It tells you whether you are winning or losing.

4. Leading vs. Lagging: The Two Eyes of the System

Lagging indicators measure outcomes. Revenue. Profit. Customer retention. They are accurate. But by the time you see them, it is too late to change.

Leading indicators measure drivers. Sales calls. Training hours. Production rate. They let you act early. But they are not guarantees of results.

You need both. Rule of thumb: every lagging indicator needs at least one leading indicator.

5. The Counter-Metric: Protection Against Gaming

Here is a law of management physics: Any metric that is rewarded will be gamed. The solution is not to stop measuring. It is to add counter-metrics.

Never have a single metric. Always have a pair. Because every metric creates a blind spot.

— Distortion Framework Principle, Chapter 7

1. The Cobra That Ate the Solution

In colonial India, the British government was worried about cobras. They offered a reward for every dead cobra. It worked — at first. Dead cobras poured in. Then something strange happened. The cobra population did not fall. It rose. People started farming cobras. When the government cancelled the reward, the farmers released their now-worthless snakes. The result? More cobras than before.

This is called the Cobra Effect. A solution makes the problem worse. And it happens in organizations every single day. You just call it performance management.

2. Three Real Examples

3. Goodhart and Campbell: The Laws of Distortion

"When a measure becomes a target, it ceases to be a good measure."

— Goodhart's Law

"The more you attach consequences to a metric, the more it will be gamed."

— Campbell's Law

4. Five Principles for Incentive Design

1. Never have a single metric. Always pair a primary metric with a counter-metric. Revenue with customer retention. Speed with quality. Cost with defect rate.
2. Reward outcomes, not activities — but be careful. Use a blend. Outcomes are what you want but they are delayed and noisy. Activities are immediate but easily gamed.
3. Test on a small scale first. Run a PDSA cycle with one team. Watch for gaming. Adjust before you scale.
4. Build a feedback loop from the people being measured. They will spot the loopholes before you do. Give them a safe way to report them.
5. Assume the incentive will be gamed. Design for it. Ask before launch: "How would a smart, slightly selfish person game this?"

1. Two Organizations, Two Responses

Failure is inevitable. Learning is not.

Organization A calls an emergency meeting. They find someone to blame. They change the process — or pretend to. Next time, no one proposes new ideas. Silence spreads.

Organization B calls a normal meeting. They do not look for someone to blame. They ask: What in our system caused this? What can we learn? Next time, people still propose ideas. They are not afraid.

These two organizations are not different in skill. They are different in how they learn. One has a blame culture. The other has a learning culture. And the difference determines everything.

2. The Fifth Discipline — Peter Senge's Learning Organization

3. PDSA: The Engine of Learning

4. The Three Conditions for Experimentation

• Psychological safety. People must feel safe to speak up, ask questions, and admit mistakes. Without this, PDSA dies. No one will report what actually happened.
• Small scale. Experiments must be contained. A failed two-week test with five people is a lesson. A failed company-wide rollout is a disaster.
• Mandatory learning. After every experiment — success or failure — there is a mandatory After-Action Review: What did we plan? What happened? Why was there a difference? What will we do differently next time?

5. What Leaders Actually Do

In a learning organization, leaders act like question-askers, not answer-givers. Three specific actions:

• Ask questions, do not give answers. When a problem occurs, say: "What have we learned? What hypotheses can we test next week?"
• Model vulnerability. Share a recent failure of your own. Analyze it publicly — to show that failure is data, not shame.
• Protect the experimenters. When a well-designed experiment fails, defend the team. Ask "What did we learn?" — not "Who caused this?"

1. Two Models of Management

After nine chapters, we return to the question that started this book. Why do smart, well-intentioned managers keep getting the same results — no matter how hard they try?

The answer is not that you are not working hard enough. The answer is that you have been operating under the wrong model of management.

Model A: The Driver. The Driver sits in the boardroom. They look at dashboards. They set targets. They measure gaps. They give orders. They believe that tighter control leads to better results. When something goes wrong, they ask: "Who made the mistake?" Model A treats the organization as a machine. The manager is the operator.

Model B: The System Architect. The System Architect walks to the Gemba. They observe flow. They design conditions. They ask questions. They believe that behavior emerges from structure. When something goes wrong, they ask: "What in the design caused this?" Model B treats the organization as a living system. The manager is the gardener — creating conditions, not pulling levers.

2. Five Shifts You Must Make

3. The Five Daily Tasks of a System Architect

1. Design and adjust indicators. Not just KPIs — indicators with targets, thresholds, counter-metrics, and leading-lagging pairs. Review quarterly. Retire those that no longer serve.
2. Design and stress-test incentives. Before launching any incentive, ask: "How would a smart, slightly selfish person game this?"
3. Create and protect PDSA cycles. Every team should run at least one PDSA cycle per month. When they fail, defend them. When they learn, celebrate them.
4. Build psychological safety. Model vulnerability. Share your own failures. Never ask "Who caused this?" Ask "What in the system allowed this to happen?"
5. Walk the Gemba. Regularly. At least two hours per week. Not to check on people. To see the flow. To bring what you see back to the boardroom.

4. When This Framework Does Not Work

Every framework has limits. This one is no exception. There are at least three conditions under which The Distortion Framework provides less value — and you should know them before you apply it.

• When the organization is very young. In a startup with five people and no formal measurement system, the distortions described in this book have not yet crystallized. The risk is not too much measurement — it is too little. In that context, adding basic KPIs may help more than redesigning them.
• When the problem is genuinely a people problem. Not every failure is a systems failure. Sometimes a leader has fundamentally misaligned values, or a team has a capability gap that no redesign can fix. The framework helps you avoid over-attributing problems to systems when a direct human intervention is needed.
• When your organization does not have the psychological safety to experiment. PDSA cycles require people to run experiments, report honestly when things fail, and learn publicly. In organizations where failure is punished at the individual level, the tools in this book will be adopted in name only. The prerequisite is cultural, not technical.

Knowing the limits of a framework is not a weakness. It is a sign that the framework is honest.

5. A Final Word

Most managers will go back to what they have always done. They will measure more. Push harder. Control tighter. And they will get the same results. Just faster.

You have the tools. You have the framework. You have the choice.

The system you have is the system you designed. The system you will have is the system you choose to design next.

The only question left is: will you start today?

Now go redesign.

A1. Quick Diagnostic — Is Your System Distorted?

Check ✅ for each statement that is true for your organization:

A2. Value Stream Map — How To

A3. House of Quality — How To

A4. 5 Why — Root Cause Analysis Template

A5. PDSA Experiment Plan

A6. After-Action Review (AAR)

A7. KPI Design Checklist — 8 Questions

A8. Incentive Design Checklist — 6 Questions

A9. Role Shift Matrix — Driver to System Architect

If You Only Do One Thing From This Book