A map is a great example of simplification because it removes information while sharpening usefulness. It reduces an almost infinite amount of data into what the user needs to accomplish a specific task, i.e., getting around town.
A phone tree is an annoying simplification because it reduces an almost infinite number of options into the five you don’t care about.
Why is one useful and the other almost always horrific?
Because the map has one purpose. Even though there are an infinite number of potential paths, the map provides the data you need to choose the right path. Part of the genius of a map is that it allows you to see the entire path (and range of paths) at once, and it doesn’t get cluttered with extraneous information
The phone tree makes you choose a path without knowing the context or the destination.
Imagine if we were to convert a map into a phone tree.
“Press 1 to take I95 North. Press 2 to take I95 South. Press 3 to take Cherry Lane.”
That wouldn’t make any sense because you can’t decide which road to take without knowing how it relates to the final destination.
A phone tree is supposed to simplify the role of a human receptionist, but it fails because the human manages ambiguity. A phone tree is frustrating because it forces ambiguous options into an unambiguous set of choices, and no decision tree can manage all the options.
Press 1 for the butcher, 2 for the bakery, 3 for produce works for a narrow range of questions. It doesn’t work if you’re curious about employment opportunities.
The Phone Tree Problem is an illustration of a larger issue, which is the need to understand the scope of a problem before you solve it. The simplifier often gets to work too early – before they know the requirements. Or, they assume one set of requirements without realizing the system has to serve multiple use cases.
Another simplifying fail is self-checkout. It solves for one set of problems – shorter lines, less staff expense – but by doing so it has allowed more theft, and has ruined the human touch. This is the classic problem with simplification. It doesn’t take account of all the hidden, invisible benefits of the current system. After all, some people go to a store because they like the check-out clerk.
Three fallacies help to illustrate some of the common problems with simplification.
Chesterton’s Fence.
The original concept is “don’t tear down a fence until you know why it was put there.”
The simplifying mindset can get arrogant. It believes it knows what’s really necessary. In reality, it’s expert in the new system, and a complete novice in the old. Without knowing why the old system worked the way it did, any effort to simplify it will create new problems.
Tip: Before removing anything, find the person who will be most upset about it and ask them why it exists.
Goodhart’s Law.
“When a measure becomes a target, it ceases to be a good measure.”
Metrics are good things – at first. They have a tendency to go awry over time because people work towards the metric rather than the thing the metric was supposed to illustrate.
If you reward a call center for resolving calls quickly, you might meet that goal but lower customer satisfaction. If you measure policemen by arrests made, they might pick the easy arrests that have little to do with controlling crime. A decade ago, a misguided Wells Fargo metric incentivized employees to open millions of unauthorized accounts to keep their jobs.
Tip: Explore what “gaming the metric” would look like, and why people might do it, before you deploy it.
The McNamara fallacy.
Named after the manager of the Vietnam War, this fallacy involves reducing reality to what’s easy to measure. It typically has three phases.
- Measure what can be measured.
- Disregard what can’t be measured.
- Assume that what you’re measuring represents the whole picture.
Tip: Explicitly list what your measurement system can’t capture. Assign someone to monitor those blind spots qualitatively.
Incompleteness
The simplifier’s grasp of the problem is always incomplete, but his confidence doesn’t show it.
The problem is incompleteness.
Chesterton’s fence is about incomplete historical knowledge.
Goodhart’s law is about incomplete behavioral knowledge.
McNamara’s fallacy is about incomplete ontology – not knowing what you don’t know.
Requirements and Context
The prerequisite for good simplification is to understand the entire context, which leads to one last thing. Too often, simplifiers fail to explore the requirements deeply enough. That’s not always laziness, over-confidence, or bad intent. It’s often the consequence of a failure in effective cross-departmental communication.
Optimizing the ad management system for the ad team might be a catastrophe for accounting, but nobody checked with the accounting manager because she’s a grouch, and we know what she needs anyway.
Simplifiers often discover too late that the “inefficiencies” they removed were actually meeting key business needs.
If your organization is wrestling with a major process or technology simplification, feel free to reach out. We can think through it together.
